Working in 2-week iterations in agile scrum teams is surpassing all of my expectations; it's like sudden pain relief revealing the level of pain you've long grown tolerant of -- it's hard to measure while still immersed in it. Software methods come and software methods go, so I was stunned to see agile change everything about what we do, immediately and profoundly.
What has surprised me above all else is the set of disciplines that agile methodology both requires and inherently teaches. The list I sketched out for myself seems more like a Buddhist Eightfold Path teaching than anything very specific to software engineering:
- Right focus: The iterations force us to narrow our attention to stories that can be absolutely completed in our tiny 2-week sprint. This gives us permission to ignore the crushing enormity of the backlog of wishes and to calm anxiety about the epics looming beyond, some of which bear the dead of prior expeditions. Agile lets us focus just on the next quarter mile of an unknowably long journey, our eyes on the snake in the path right now and our collective creativity focused on getting around it.
- Right prioritization: The limitation of the short sprint forces us to negotiate with our product owner about priority and relative benefit. Now that product owners believe that they will definitely receive the things that the team commits to build, they are more willing to make the hard choices and figure out what they really need first. Gone are the monolithic product plans in which every requirement listed holds equal urgency, with no guidance on how to trim it when (not if) the project buckles.
- Right allocation: The agile teams are sacred resources, and members get pulled off of sprint work either by overtly reducing their capacity (which protects the success of the sprint) or by negotiating resource trades with the other entity that benefits. This dedication of individuals to the project they are sprinting on is something I've never seen before: always before, competing organizational urgencies (fire-fighting) trumped all project work, without practical adjustment of the project to keep it on track. We were always doomed before we began, and we knew it.
- Right collaboration: It's not enough to put people onto teams and command them to collaborate: unless all team members are working on the same narrow deliverables at the same time, real collaboration is infrequent and underpowered. Agile sprints force everyone to be on the same page, even if they're not in the same room, and this shared work focus and their mutual dependency fosters collaboration across all disciplines.
- Right accountability: Knowing that we're only days away
from a public demonstration of our work has incomparable clarifying
effect. We all know exactly what each of us has committed to contribute
and achieve, and we all know that failure by any one of us casts
failure across us all (because we cannot demonstrate any story that
falls short of the Definition of Done). The power of this foundation
in integrity cannot be measured: we are known by our work and our word.
No one can hide behind seniority or reputation any more.
- Right stride: Agile teaches us to be honest about our abilities and limitations, and
to work ever harder on practical task estimation, so that we can make
good on our promises. No longer do we paper over poor planning with heroics
and self-sacrifice, which breeds resentment and burnout; rather, agile
teaches us to use velocity data to find our true, sustainable pace, as
individuals and as a team.
- Right speech: Core to Scrum is communication: both daily
standups and day-long real-time conversations. In waterfall, project
communication happens often in Word files, which is the slowest,
heaviest, most inefficient approach. But more than talking, Scrum
teaches the necessity to protest: we learn to speak up when we're not confident about tasks
and stories, when a process isn't working, when we don't understand or
agree. The interdependency of the team supports such honesty: the plane
doesn't fly until we all get on board.
- Right failure: That every sprint failure is met with calm
analysis in the retrospective and immediate course adjustments changes
utterly how we see mistakes. Now failures are subject matter for
intensive learning and jet fuel for creative change. Small failures
early on pay handsomely in disasters averted and new discoveries made.
Lack of failure is suspect: it means teams are aiming way too low,
staying safe and stuck.
One way to summarize these benefits is that agile restores trust: agile teaches and strengthens mutual trust and frees everyone to take risks, safe in the knowledge that the overall sprint series will end in success. Another way to boil it down is to say that agile, by its essential nature, rewards people for doing the right thing. And isn't that the foundation of enlightened animal training everywhere? ;-)
