Otto Weininger quote

"All genius is a conquering of chaos and mystery." - Otto Weininger

Friday, January 18, 2013

Agile Coaching, Part 1

I had the opportunity to talk to the New York City Scrum User Group last night on this topic (nycscrumusergroup/) and wanted to summarize some of the key points of that talk. The industry press is full of statistics about the increasing rate of agile adoption and there are many teams accomplishing excellent results with agile. But there are also a lot of teams that are struggling.

Agile is deceptively complex. In the classic waterfall project we're all familiar with:

  • Communication is between silos at stage boundaries

  • The process is well defined

  • Delivery is some time in the future, mostly



In contrast, with agile:

  • Communication is constant

  • The process is not well-defined

  • Delivery is in the next few weeks, at most


All of this contributes to make agile more complex, while at the same time it appears deceptively simple. This, in turn, leads teams to employ what's becoming known as the SCRUM-BUTT approach, "enhancing" their agile process with waterfall or other adornments to address the perceived shortcomings within the core agile processes. Now some teams have made useful additions to their process, but in too many cases the problems could have been solved by applying the basic agile framework better.

When I coach teams I start by establishing a basic understanding of why agile works:

Agile works because we don't need to pre-define everything. We don't need to pre-define everything because:

  • the team and the Product Owner have an open dialog to insure the sprint requirements are understood

  • it is easy to change the software

  • we keep entropy from accumulating in the code

  • we have a safety net of automated tests that give us confidence that we haven't broken existing functionality


Agile also works because we deliver production-ready software at the end of each sprint. We do this because:

  • we have that safety net of automated tests

  • we have a clear definition of "Done“

  • we insure that we meet our definition of done on each story


If the team doesn't embrace these core principles and hold themselves and each other accountable for meeting them every day the team will probably struggle. For example, if the automated tests don't do an adequate job of covering the system (and this is very often a problem for teams just starting out, putting them in a hole they then struggle to ever get out of) changes to the code may introduce defects that slip through into QA or even production. The team then ends up constantly interrupted to fix priority defects, which means they then struggle to deliver their committed stories each sprint. This in turn puts pressure to do things faster, which leads to cutting corners, leading to even more technical debt until someone concludes that "Agile doesn't work!". That's the wrong conclusion. The root of the problem is that the team isn't executing the process correctly.

Once the team grasps these core principles we can move onto actually defining and adopting the process. This involves establishing the "Philosophy of Agile", which build closely on the core principles, then moving on to the basic fundamentals of the Scrum process. I'll talk about that in part 2.

The last thing I stress to the team, going back to the SCRUM-BUTT phenemona:


  • We will get better by doing it and delivering value along the way

  • And, if you’re tempted to change the process...


    • STOP!

    • Are you at Ri? (If you're not familiar with the ShuHaRi concept you can read about it here (martinfowler.com ShuHaRi)) And if the team answers yes to this, the follow on question is "Really???" since teams frequently overestimate their progress on this scale

    • If you are not at RI you shouldn't be changing the process, so go back to first principles

    • And if you don't understand how to do this, get help




More on this in the next post. And, by the way, Happy New Year!