Why Agile – what problem is it trying to fix?
Increasingly common in the workplace Agile Software Development, is becoming simply Agile, and even agile, a metaphor and approach adopted by organisations to make them more efficient, aka business agility. Why wouldn’t you want quicker decision-making, sustainable rapid product development (software or otherwise), and to do more of what your customers want for less moolah? All this is possible with Agile if done well.
I think this post summarises quite well the background; how Agile attempts to solve the software problem and what 17 ‘organisation anarchists’ and ‘lightweight methodologists’ were doing in a ski lodge in Utah in February 2001! (They were producing the Agile Manifesto)
These value statements are underpinned by 12 principles, reproduced here in their entirety, because they are important, and because that’s all there is! In the spirit of light documentation there are no big official guides, workbooks or checklists. For further reading have a look at the non-profit Agile Alliance.
- Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
- Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.
- Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
- Business people and developers must work together daily throughout the project.
- Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
- The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
- Working software is the primary measure of progress.
- Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
- Continuous attention to technical excellence and good design enhances agility.
- Simplicity – the art of maximizing the amount of work not done – is essential.
- The best architectures, requirements, and designs emerge from self-organizing teams.
- At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behaviour accordingly.
The what – some terminology
Now that we have a bit of history and context under our belts, I will try to explain Agile via the medium of a glossary of terms…vis-a-vis the things that Agile is and the things that Agile does.
Note: the following is based on the author’s experience of Scrum and Kanban, two popular Agile methods, which can also be combined into a hybrid ‘Scrumban’
Backlog – a list of things to do; a catalogue or ordered (prioritised) list of problems or issues to resolve, tasks to undertake, or User Stories to be fulfilled.
User Stories – are a simple narrative about a business need as the start point of a conversation between the Product Owner (customer) and the supplier.
User Stories are not a formal statement of requirements.
Stories can be part of a bigger Epic, Feature [set] or Theme, and can be broken-down into detailed delivery tasks to provide a bit of structure. It’s important – you will see later – that any backlog item is small enough to be completed in a fixed period. You can’t fix a bit of a problem or roll-over and finish it later, that’s not the way Agile works.
User Stories are written on actual or virtual Cards which contain 3 key pieces of information:
Who wants it – so we know who to talk to when its turn comes
Why they want it – so we know how valuable it will be, i.e. the explicit benefits, outcomes or justification
What is wanted – with enough detail to actualise it, the minimum will probably be in the form of Acceptance Criteria. We want to know what success looks like, both the ‘happy path’ outcome(s) and any alternate and exception cases.
(Ref. Paul Oldfield – extracted from a LinkedIn conversation, Agile and Lean Software Development group)
However, stories will normally contain additional information so that they are complete and standalone, with enough detail so that they can be understood and built. The INVEST criteria provides some guidance on what a good story contains.
The how – tools and techniques to do Agile
Agile teams use a lot of events (sometimes called ceremonies) and interactive tools and techniques to build effective, collaborative and responsive delivery machines! Agile is about rapid delivery of software using whatever means the team finds valuable, normally some or all the following.
Daily stand-up – a short daily (of course) review of what each member of the team has done, what they plan to do, and any blockers or impediments that are preventing them doing their work to their maximum potential.
Kanban – literally a billboard, used to represent visually the status of tasks on a backlog or board.
Scrum – both the name of a specific Agile approach and the teams themselves. Scrum uses short fixed development and delivery cycles (Sprints). A sprint is a commitment to deliver a number of stories/tasks/fixes, the Sprint backlog.
Burndown chart – one of the popular tools used to record and plot progress, key to understanding how well the team is doing based on current commitment, i.e. the burn down of tasks, story points or resources vs. time. Another useful measure is the capacity of the team, i.e. how much thinks it can do vs. actual performance – called the teams velocity.
Show and tell – The end of a sprint, delivery of completed stories or other significant chunks of work normally involves some review or demo, so that developers can show their work. If the Product Owner and other stakeholders are suitably impressed then they can go away and play with the finished website/software/new feature or maybe launch the product to a wider community* Remember the aim is, ‘…continuous delivery of valuable software.’
(*Ed. Agilists – yes that is a word – talk about MVP Minimum Viable Product and MMP Minimum Marketable Product)
Planning/grooming/refining/look-aheads – what these events are and when they take place depends a lot on the make-up of the team, how big the product backlog is, and the maturity of the Agile process in the organisation. The end goal is a well-oiled efficient production line of needs (stories) flowing through the process, from left to right, with light documentation and minimum friction.
Retrospectives – lastly for this section, Agile teams and the wider organisation should regularly look at themselves critically, to metaphorically kick the tyres. Typically after one or more sprints or some other checkpoint consider what the team has done well, what it could do better, and ways to improve their performance. The constant and regular introspection, adapt and learn cycles, feedback loops, communication and team-bonding are key to making Agile responsive and sustainable.
Putting it all together
There are a few other topics that are beyond the scope of this introduction, but worth thinking about if and probably when you go Agile.
How do you scale up your small Agile team so that you can tackle the whole product portfolio? There are several approaches, the most popular off-the-shelf frameworks are SoS (scum of scums) and SAFe (Scaled Agile Framework).
https://techbeacon.com/5-proven-techniques-scaling-agile-enterprise
Co-location is a tricky one; what happens if you cannot have all members of your Agile team working together, i.e. full time in the same space, to avoid distractions and divided loyalties. Can Agile work effectively if more than one team share a front-end developer, or the testers are located off-shore, or the Product Owner also has operational responsibilities?
Ideally Agile should be fully embedded in your organisation, from the business strategy and pipeline of requirements to continuous integration (of code) and continuous delivery of features.
Now that you have absorbed all the above, you can forget it and return to earlier list of values!
The world of Agile is not meant to be a prescriptive admin- or bureaucracy-heavy commitment. Always question why you are doing something, and what value it is to the team, the Product Owner, but mostly to the end Customer. Agile is best when its adapted and adopted to suit the team and specific organisational context. The team is the thing and they should determine their own culture and mechanisms for maximum throughput and quality of work.
Re-cap – why are we doing Agile?
Because it works, both anecdotally and from my own experience, although Agile is not free money, it takes effort, discipline and persistence. Objective research-based evidence is a bit harder to come by, although this seems a clear enough finding;
“Respondents overwhelmingly indicated that agile teams are producing higher quality, have greater productivity, and enjoy greater stakeholder satisfaction.”
http://www.ambysoft.com/surveys/agileFebruary2008.html
Warning, this is based on a 10-year old Agile Adoption Rate Survey, since when Agile has almost become the de facto way to create software, so it must be ticking a lot of the boxes for organisations. However, waterfall and other so-called traditional methods may be out of favour but they are still in use and useful, possibly as part a hybrid approach. See separate IT element.
(c) Antony Lawrence CBA Ltd. 2015-18
Leave a Reply