Since the original Agile Manifesto was published back in 2001, “Agile” has become an increasingly fashionable buzzword, championed by young, trendy development teams in start-ups, emerging technology companies and small autonomous teams within bigger businesses. So what is it?
What does Agile provide?
For those of you who are unfamiliar with it (or as a reference for those who already are), the Agile Manifesto promotes four key values:
“Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan”
Source: http://www.agilemanifesto.org/
That’s fine in the abstract, but what is “Agile” in a more concrete and tangible form – how might a team or business change in its ways of working in order to become (more) Agile? Essentially we have two fundamental areas to sample and build from; Agile process methodologies and associated Agile practices.
Agile Practices
Starting with practices in mind, there are dozens out there (and more emerging all the time). Just by lifting a selection of some of the more self-descriptive examples from the list on Wikipedia (purely for brevity) we have:
- Backlogs (Product and Sprint)
- Behavior-driven development (BDD)
- Continuous integration (CI)
- Information radiators (Scrum and Kanban boards, Burndown charts)
- Pair programming
- Refactoring
- Scrum meetings (daily stand-ups, iteration / Sprint planning, reviews and retrospectives)
- Test-driven development (TDD)
- Use cases
- User stories
- Throughput / velocity tracking
Source: http://en.wikipedia.org/wiki/Agile_software_development
I won’t go into the details or respective merits of the practices that I’ve called out here, as that would distract from the focus of this post and after all, they are all topics easily explained by making good use of your preferred search engine. The important thing is that all these practices scale organically, regardless of the size of your project or team(s)* because they’re either distinct activities (like pair programming, refactoring or CI), the automation of otherwise manual techniques or are purely informational. None of them necessitate change to your wider processes. Think of them as plug-ins you can insert that compliment your chosen process methodology, rather than anything mutually exclusive to it.
* Admittedly, pair programming is somewhat challenging if you only have one solitary developer in your team, but other than that please just trust me. After all “I’m an expert!”. Source: https://www.youtube.com/watch?v=BKorP55Aqvg
Agile Processes
Whilst adopting related practices may be synonymous with Agile development, you aren’t truly Agile unless you’re practising (at least an evolution of) an authentically Agile process methodology. So, let’s see some of the more popular Agile methodologies:
- Scrum
- Kanban
- Extreme Programming (XP)
- Lean software development
To limit the scope and length of this document, we’ll initially consider how a Scrum based process might scale. You’ll often find that organisations proclaiming to be practicing Agile actually mean they’re incorporating aspects of the Agile Scrum methodology (in a similar way to how “Linux” is misused to refer to a GNU/Linux based distribution). In Scrum’s purest form, requirements move from a “product backlog” (a prioritised list of requirements) to a “sprint backlog” (after a planning meeting) which becomes the list of work due to be completed in the next “sprint”. A sprint will typically last around two weeks, where each day a short “daily scrum” meeting is held where each team member reports their progress from the previous day, their objective for the day and whether they have any impediments or blockers that may restrict their progress. Obviously the method has more depth and substance, but we only need a high-level understanding of the process at this stage:
Source: https://upload.wikimedia.org/wikipedia/commons/5/58/Scrum_process.svg
Agile Teams
Scrum advocates three roles to facilitate this method. A Product Owner, Scrum Master and Team Members. The Product Owner should be a key stakeholder, with a strong vision of the product hope to deliver. They get to prioritise the work in the product backlog, but don’t get to dictate how much goes into each sprint. The Scrum Master’s responsibility is essentially to run interference – removing any impediments in a servant-leader role that facilitates rather than dictates (other than ensuring that the agreed process and the rules of Scrum are adhered to). That leaves us with the team members who deliver our product:
“In Scrum, an ideal team would include seven members, plus or minus two. Usually, teams are comprised of cross-functional members, including software engineers, architects, programmers, analysts, QA experts, testers, UI designers, etc. It is recommended all team members be located in the same room, called the team room.”
Source: http://scrummethodology.com/the-scrum-team-role/
If we imagine seven team members including an architect, analyst, two testers and one UI designer (like the examples provided in the above excerpt) in addition to the Scrum Master and Product Owner we’re left with two development roles – four if progressing to the recommended maximum. We’re also free to shape the team for the size and complexity of the product we’re going to deliver. This could mean we remove the UI designer and one of the testers from the team and add another developer and a DBA. The makeup of the team can easily evolve as you discover the balance of work. This is ideal for many small teams and businesses, when everyone fits into the proposed Scrum organisational model and as we have a singular Agile squad, work iterates quickly in a serial manner. But does it scale…
Setchu - Agile at Scale 