“Agile” is mainstream now. I’m putting it in quotes, though, to signify that agile means different things, depending on who’s using the word. For some, it means little more than the mindset of iteratively moving towards a goal. For others, it means a strict structure of product development processes that foster developer happiness. Others again, use it because they have to, without the mindset or the processes to truly utilize its benefits.
Through my involvement in over 50 projects across all types of organisations, I think I’ve learned a few things about “agile”. The important point is, that depending in which organisation and team you find yourself in, a different approach to agile will work best. Here are three general patterns that I’ve found.
A. Minimal Structure
In this pattern, which I’d describe as the agile ideal, only productive work that directly moves toward a goal is done. That means no strict structures or processes. Instead, a clear vision guides the team.
An extremely experienced team that’s smallish (< 8 people).
An organisation that allows said team the freedom to reach their goals however they please
A clear vision
No unnecessary meetings or documentation, no busywork
Move fast and deliberately
Try to do this with the wrong team or leadership, and you might end up with nothing usable at all
Only works with experienced teams (no juniors), that ideally know each other well
Doesn’t work for projects requiring bigger teams
B. Custom Process
Bigger projects require bigger teams, bigger teams require more structure. This pattern customizes an approach like SCRUM or KanBan, takes what works for the organisation and leaves out what doesn’t.
A manager that has enough experience to design a good customized process, and has an agile mindset (doesn’t insist on strict, complete, up front requirements)
Organisational freedom to use customized instead of standardized processes
Enough experienced team members to give quality feedback and improve the process over time, and also to onboard newbies
More nimble than SCRUM by the book, less time wasted
Adjusting the process to the organsation and the team will yield a process that everyone involved can be happy with
Can sometimes go too far and remove essential elements of agile processes
Can lead to an agile waterfall without any iterations
Can run into problems in bigger organisations, because every team creates their own version, which inhibits cross-team collaboration
C. By The Book
Organisations that are completely new to agile might benefit by introducing a strict, by the book process like SCRUM to shift the mindset via the process.
Time and money, because introducing a process like SCRUM will take both (but beat waterfall-type approaches in the long run, easily)
Leadership buy-in for an agile transformation
Comparatively easy to roll out, since there are trainers one can hire
Standardized and structured, easy to onboard new team members
Structure cannot completely replace mindset, if management and leadership are stuck in old, ineffective paradigms, this will at worst become a waterfall look-alike
If your management enjoys meetings, SCRUM is a great excuse to hold more, longer meetings with many people, wasting inconceivable amounts of time and money
It was a hard lesson for me to learn — that the seemingly inefficient and wasteful structure of a process like SCRUM is sometimes the best option, but now I see that point. Still, I feel a longing for minimal structure whenever facing any development challenge. And I’d still say, that for new prototypes or innovation projects, pattern A. is the optimum — if you have the required team.
In later stages and bigger organisations, however, that small team creating the first prototypes must be followed by a larger structure that supports and extends the project long term, with approach B. or C., depending on your organisation and team.
And when it’s time to reinvent yourself for a new major version, maybe whip out the A. team of experts again, to build something awesome in the most agile manner possible!