Agile processes, especially as recognized in software development practice, has been a very successful project management approach. In my 20+ years experience with the general approach (when it was first labeled “extreme programming”), I have experienced more rapid delivery of quality code, more predictability in the software development life cycle, less rework, and a higher resonance with customer and stakeholder needs. I have also observed, though, it causing stress within organizations – when software is developed as rapidly as it is under an Agile approach, the corporate bottlenecks become more apparent elsewhere, causing friction with other teams.
Agile detractors also point to problems within teams themselves, due to the stress of fast-paced Agile development. Sometimes the criticism is not directed at Agile , but to some of the tools used by Agile teams: ticketing systems, kanban boards, sprints. Sometimes the criticism is higher-level, questioning the value of putting customers, “the business”, or their proxies – the product manager – in the driver’s seat of software development. Or, how it’s “all trees, no forest”, it’s short-term focused, it’s not design centric. Or, that the frenetic pace leaves no room for career development or learning.
These are valid concerns. Much of it, though, are symptoms of agile principles misapplied. This is indeed a common problem in corporations. At a company I recently worked at, some departments decided to “go agile”. But, by that, they meant only that “all tasks will will organized into weekly sprints”, and worse, each team was treated in isolation, each with their own sprint queue of “fully-specified requirements”. What happened to self-organizing teams?! Customer collaboration?! All completely neglected. And even more bizarrely, the agile approach was applied to non-project work, such as data analysts whose sole jobs were to produce reports or analyze statistics. All their incoming tasks were organized into sprints as well. I predict that “Agile” will face some backlash within that company.
We can mock Agile misapplied, however, there is a deeper concern I want to address – paying attention to Agile’s balance between the rapid pace of development and its equally valuable ebb of thoughtful design and retrospection. It can’t be all opening and closing of tickets and routine deployment of code, treating all developers as code monkeys. The rapid flow of Agile development is to be applauded, but the very principles of Agile also incorporate rapid flow’s own yang, aspects I’ll call Agile’s “ebb“.
Using the Agile Manifesto as the fount of agile wisdom, here are the elements I identify as Agile’s flow, or yin:
- “early and continuous delivery of valuable software”
- “changing requirements, even late in development”
- “deliver working software frequently”
- “work together daily”
- “face-to-face conversation”
- “Working software is the primary measure of progress”
- “Sustainable development … should be able to maintain a constant pace indefinitely”
That last principle especially – that constant pace, epitomized by backlog lists, ticket assignments, regular prioritization, unit testing, and releases – creates the the welcome rhythm of agile development. What, though, balances this frenetic pace?! I suggest the following manifesto principles are Agile’s yang:
- “Give [motivated individuals] the environment and support they need, and trust them to get the job done”
- “Continuous attention to technical excellence and good design enhances agility”
- “Simplicity … is essential”
- “The best … designs emerge from self-organizing teams”
- “At regular intervals, the team reflects on how to become more effective”
When I go to conference talks about Agile, perhaps the most oft-mentioned yang practice is the latter one, typically called the “retrospective”. The hip kids refer to it as the “Retro Meeting”, or simply, “The Retro”, as in, “let’s discuss this in the next retro”. It’s a very good practice, to be able to honestly and openly discuss what went well with the last sprint, what could be done better, etc. In a fairly-run retrospective meeting, all members have an opportunity to contribute and grow.
How though, are the other principles implemented in Agile organizations? This is something I’m still reflecting upon with my own teams, so I don’t have all the answers yet, but here are some suggestions:
Agile Yang
coming soon