SCRUM…Are you an Agile Poser?

I’ve made some interesting observations recently.  Many “agile” development organizations aren’t quite as agile as they think they are.  SCRUM is undoubtedly the most popular agile project management technique in use today.  My team at my day job does it well.  My partner and I at Kiwiluv do it poorly because we have full time jobs and work on this in evenings and weekends which I consider to be a good excuse.  I was talking to a colleague last week who just started at a major US corporation and was showing her how to use a SCRUM tool (Rally in this case) because it just so happened my company uses the same tool.  In chatting, it was clear that SCRUM was not yet institutionalized in her organization.  Thinking about it, it’s hit or miss at mine too.

At her organization and the less SCRUMesque projects in mine, I noticed some common traits.  I really believe that there are some symptoms that you can use to identify whether you’re an Agile Poser or a real Agile organization.  Here’s some warning signs:

1. You don’t have a daily SCRUM because “you really don’t need to meet that often.” Bull.  SCRUM teams are meant to be self directed and the daily SCRUM is where the team and Scrummaster sense disturbances in the force or identify outright blockers to the teams forward progress.  The sprints are short and the daily SCRUM is the forum where the team holds one another accountable for getting tasks done.  How many weekly meetings have you attended where “action items” linger on for weeks and weeks.  At the daily SCRUM everyone states what they did yesterday, what they did today and if there are blockers…end of story.  That discipline is critical.
2. The manager makes assignments.  Big fail here too.  Again, in SCRUM it’s a self directed team.  The manager’s responsibilty is to create an environment where SCRUM is effective.  Specifically, the team needs to feel empowered to work the sprint backlog as they see fit.  Also, once the sprint starts, it is sacred and you don’t break sprint just because the manager’s higher up had a mood swing and wants to change priorities immediately.  Yep, happens all the time but the team needs to establish a rythm, have confidence that they can execute their sprint as they see fit, and not live in fear of constant managerial direction changes.
3. You have more than one product owner or don’t engage with the one you do have.  My colleague’s situation was that of a traditional organization making a foray into Agile methodologies.  Good for them, but change is painful.  While we were reviewing the backlog, it surfaced that her “SCRUM team” was serving many masters and had to divide their attention between multiple stakeholders.  One team, working on one product, with one major external stakeholder to be the product owner is more effective.
4. You don’t have a release and sprint planning meeting with the team.  If you’re a manager and you sit in meetings listening to requirements from other organizations from your product, then descend from on high with premade commitments for your team, you’re doomed.  If the team doesn’t have skin in the game by being participants when commitments are made, they’ll just whine about unreasonable demands from management being worked under the charade of SCRUM.  However, if they’re sitting there in the planning meeting and commit to the deliveries for the overall release or just the next sprint the level of motivation will be much higher and peer pressure will drive behavior in support of the commitments.
5. You have project managers that don’t get or believe in SCRUM.  There is a wealth of information for Project Management Professionals (PMPs…you know…the guys that refer to people as “resources”) on how to integrate SCRUM into an overall larger project management effort.  They are not incompatible, but SCRUM, despite it’s popularity, is not yet standard fair for the training your PMP’s go through.  Having your team happily doing SCRUM and effectively working with a product owner, but having your project manager living in the word of Microsoft Project will end in tears.  The project isn’t the Gantt chart hanging on the wall…it’s the interaction and work getting done at the SCRUM board and in your team’s cubes or offices.
6. You don’t have a SCRUM board.  This is a corollary to #1.  Most SCRUM tools provide a virtual scrum board, but until the human race evolves for a few more thousand years and we’re all disembodied brains in a jar, personal presence and interaction trumps technology any day.

I’m sure there’s more, but if you see a few of these occurring in your organization, ask yourself if you’re really Agile, or if you’re just using your SCRUM tool as an expensive to-do list.

I’m a “Certified Scrummaster” and am therefore well qualified to comment on this.  Actually, just kidding…the “Certified Scrummaster” bar is very low.  You just have to attend a two-day class and print your certificate.  There’s efforts in play to have an exam and a more traditional certification process which I don’t have much use for.  The reason that the bar is low, is that SCRUM is very simple.  But as simple as it is there’s some rules that you can’t break:

1. The three key ceremonies need to be followed.  The release planning meeting, sprint planning meeting and daily SCRUM…conducted with monotonous repetition are the only way to drive home that yes…you’re a SCRUM team and this is how we do things.  Just pretend you’re a software development martial arts master and these are your Kata.
2. The team needs to be self directed.  If you’re a traditional command and control manager just give it up.  If you don’t empower and trust your team you’re doing something wrong anyway.
3. The product owner needs to be involved.  When you’re team finishes a backlog story, he or she is the one to declare “doneness.”  Every software professional on the planet has experienced development efforts that are “done” but were never quite as done as believed.
4. The sprint is sacred.  Yep, angry customers call and senior management changes priorities often.  Grow a backbone…that’s why the sprints are so short.  When the team resurfaces after the current sprint, that’s the time to discuss changes in direction and replan….that’s the whole point.  SCRUM is about being responsive to changes in direction, not resisting them.  If you stroll in 4 days into the sprint and issue mandates from your higher ups, you’re not doing SCRUM and your team will know it.

Most importantly, if you can’t get your senior management, project managers, product managers, etc. to buy in to SCRUM or any other Agile process…just don’t do it.  Methodologies like SCRUM create fanboys who claim it’s the only good answer, but there’s no silver bullet.  Maybe Agile development is just not for you.  If so, accept it and move on…there’s too much work to be done to divert energy into force-fitting a methodology that’s en vogue even if it doesn’t fit your needs or culture.  Just move on.