Tuesday, July 28, 2015

Are you Really an Agile Team?

mymanagementexperiment.com


Easy to Understand but Hard to Apply


Many of us claim to be Agile teams.  Our team made this claim until a colleague (Brian Keirstead) challenged us on how we were ignoring some basic practices of Scrum.  Here are some of the reasons why he pointed out that we weren't a Scrum team:

  • We had a single 15-20 person team
  • We did not have a formal Sprint Planning 
  • Our backlog was scattered across a couple of excel spreadsheets
  • We did not force-rank our backlog
  • We had QA operate as a separate phase (sometimes in the next sprint)

As much as we agreed with him, we argued that we were necessarily different.  We needed to adapt the Scrum framework to suit our needs.  "We need to make the framework work for us!!".

Looking back, I can admit that this approach is flawed. Scrum is a really simple Agile project management framework.  If you are first starting out with an Agile team it's likely you don't know - what you don't know. The easiest way to learn is by doing... until it becomes "muscle-memory". Much like learning any skill you need to first learn the rules before you break them.

The Pain Means Your Growing


Many of us mistake the pain of learning is a signal that we're doing it wrong.  Our pain in adopting Scrum revealed the following:

  • Organizational impediments are sometimes phrased as "the way we do business"
  • Team work does not always come naturally
  • Saying NO is not easy, but important
  • Time-boxing is crucial to empirical analysis 

The Way We Do Business


When we broke the 15-20 group into 2 separate teams there was a lot of resistance. We complained that we weren't able to see the big picture.  We believed that our large complex app required an equally large team.

The reality was that we failed to articulate a clear concise strategy.  Having a big group was our way of hiding this fact.

We also did ad-hoc "Planning" as we were stealing a Kanban style of taking on stories continuously. However we did not put strong WIP (Work-In-Progress) limits in place, or craft stories to be all equal in size.   As a result we...

  • often slammed QA with large number of stories
  • were unable to forecast a release date
  • did not operate as a team on a focused goal

But There's an "I" in Agile!


Developer culture often focuses on the brilliance on an individual, a hero ... a "Rock Star" developer. Having smart, motivated and intelligent people is a good thing.  However, no individual should cast a shadow so large, that it leaves others in the dark.

Standup's started to reveal how poorly coordinated we were. We often spent the whole day not talking to each other. We had a habit of measuring success by completing our individual user stories.

By having a dedicated Scrum Master we were challenged to learn how to work together towards a common Sprint Goal. Once teams began to really gel, we saw a dramatic increase in velocity.  But more importantly, we really started to love working with each other.  To this day, we point to our team mates as one of the best reasons we love our job.


Rebel Scrum Master


There was a period of time that developers were not empowered to voice concerns and make changes. To give teams more autonomy our Scrum Masters were encouraged to say "no" a lot:
  • "No" to having Managers/Leads at Retros
  • "No" to having 20 people interrupting a 15-min standup
  • "No" to ad-hoc requests mid-sprint to aren't aligned with the Sprint Goal
By giving the Scrum Master permission to play the bad cop, teams could properly focus on the Sprint. Once we got the basics we didn't require the largely defensive role of the Scrum Master.

To quote Ken Schwaber "...a dead Scrum Master is a useless Scrum Master".  It's can bean easier pill to swallow making many small changes - over large swooping ones.

Empiricism not Imperialism


Often at the end of a Sprint, we'd let a story roll over until the next day of the sprint. By focusing on "getting credit" for the work on the sprint, we were hiding problems that we needed to be solved.  In this example, we needed a clear "Definition of Done" that included QA verification. The fear of missing a sprint prevented us from learning.

As Star Wars taught us so well, fear is a great source of learning.  Luke Skywalker was taught this fact when he pleaded with Yoda to train him. "I won't fail you! I'm not afraid!"

Yoda - a seasoned Scrum/Jedi Master saw Luke as young and naive.  "Oh! You will be.... you will be." 

Unlike in the movies, it isn't an Evil Empire that is standing in the way of your teams success... it's likely just a very common aversion to pain fear and failure. 

No comments:

Post a Comment