Management Accountabilty in a Scrum World


Last summer, I was having a conversation with a friend who worked in Microsoft Research.  I knew him from outside of work and we rarely talked shop, but in this specific instance, I was telling him about my projects.  The biggest project on my plate was CodePlex.  After bragging about the featureset, I began describing the way we were building the software using the agile methodologies, from the spike we did at the project inception to the weekly iterations and TDD.  I was telling him about how we were even trying to get a shared workspace to put the entire team in one room (we did get it and, while it’s not as cool as my old team’s workspace, it is the office once inhabited by Bill Gates and then Steve Ballmer—so that’s pretty cool)…


My friend’s response took me a bit by surprise.  He was more impressed with the development approach than the product and he went out of his way to not only praise the team, but also praise me as the manager.  He pointed out few managers had the patience and trust to support agile development at Microsoft as there’s a leap of faith that is required and trust in the team.  He believed managers couldn’t handle the ambiguity of the schedules and deliverables (though I believe that is changing at Microsoft).  After all, with waterfall software development, everything is lined up and the dates are in stone—when you say it is going to be “Code Complete”, it will be complete.  That’s a mirage, of course as software projects rarely hit dates, but managers still manage to get some level of satisfaction from deluding themselves.  Personally, I’ve always felt that you can’t effectively run a business on a twelve-month ship cycles and assume no changes.  Waiting until month eight to determine there’s a slip or key features will get dropped is borderline suicide.  Either the product will come up short of expectations or the date will slip and surprise upper management.  It also guarantees the infamous death march.  The ability to continually course-correct is something that has a sister-theory in business called “Discovery-Driven Planning” and I see it in the NFL every Sunday in the Fall.  But agile is not perfect and isn’t the cure-all for every software project.  What happens when results are less than perfect?


Recently, Doug Seven from my team posted a blog entry entitled “Accountability in a Scrum World”.  In the past several months, Doug has really come to embrace many of the agile principles.  Well, with one of our projects, a team that is very new to agile development had struggled with the first two iterations.  Doug was obviously frustrated with the progress and was trying the get to the root of the problem. In this specific case, I think there were many things working against them that make any sort of assessment unfair.  Plus, to judge after two iterations in any case is WAY premature.  I think it’s easy to fall into an expectation of everything working in textbook fashion from day one.  Guess again—nothing in life works that way.  While I myself am inherently impatient, this is one case where I refuse to be so.  In fact, I gave the team a short-tem goal I felt was very achievable in a fair timeframe.  I wasn't looking to stretch the team on a deliverable.  In fact, my manager and I locked horns about it as he thought I was sandbagging.  In a way, I was. Why?  Because I wanted the team to have enough room to take risks.  If you are under time pressure, you will revert to your old approaches.  When adopting agile development, teams need to be allowed to struggle without fear of reprisal.  Changing the way you do your craft is scary and that’s what we’re asking from the team.  As a manager, I need to be willing to make the short-term investment for the long-term prosperity.  Again, it's a matter of trust.


The unintended consequence of Doug’s post was to scare the team into thinking they were under the gun, which draws them back into the world where they fear failure.  That spins them into a world of the blame game, whether it’s teammates, the process, management, and other things.  And let’s face it—all those are likely guilty of something, right?  I don’t want people on that team thinking about reviews or their bonuses or anything like that and their need to defend that (yes, that is naïve, but I want to at least minimize focus)—I want them focused on the success of the team.  To the sports analogy, the athlete should be thinking about winning a championship first and then trust that if he contributed sufficiently to the cause, he will be rewarded (yes, another sports analogy—I can’t help it).


But, to Doug’s question, what of accountability?  Not in the case of this team, but with all teams, successful and not.  With the infamous Microsoft performance curve no longer in existence, we can now operate in Lake Woebegon, where all the children are above average (well, not quite…).  I believe the only way agile works is when everyone feels accountable for everyone else.  That’s the purpose of the daily stand-up—people sharing their progress and their obstacles, in some cases looking for help.  If one person fails, everyone fails.  Communication is vital, everyone on the team should be looking to assist, not blame, and the accountability must hang with the team. At the end of the project, you can certainly do the retrospective and recognize who stepped up for whom.  I’d rather reward the person that chips in to help a teammate get past a tough issue than someone who writes the random killer feature. I'm not talking about the hero dev thing (which can be a different problem), but rather taking care of the little things and removing obstacles to keep the cadence. In fact, I’ve been on projects where one person failed miserably, but the team was successful because the rest of the team stepped up.  Once the project shipped, the rest of the team was rewarded nicely and the person whose contribution did not measure up was not with the team for long.  That said, we gave him the full v1 release to prove his worth before casting judgment on him.  But when you start playing the individual accountability game from the start, then it’s every man for himself.  Agile will fail in that mindset.  My personal management philosophy is to keep an eye on any unique events that need immediate attention, but I try to reserve judgment on people until the project is out the door.  Trust the team and give them the ability to self-correct.  Once they ship, it is clearer to assess why the project was able to ship and what could’ve been better. 


So will the team that struggled with the first two sprints succeed?  My confidence is very high.  There’s too much talent there for it not to.  In fact, the third iteration has already gone MUCH better by all accounts. But just as I won’t judge the 2006 Orioles baseball season until October (though I will keep an eye on the standings), I won’t judge this team until we’re much further along in the project.  They know what they’re accountable for as a team and that’s all I am keeping an eye on at this point.


{Foo  Fighters – In Your Honor}

Skip to main content