How my agile is changing.

Those of us in the agile community spend a lot of time talking about building software and helping our business partners.  What I have discovered over the last six months is that for a large organization like mine agility is a relative concept.  What I am discovering is that the business is struggling to keep pace with the developers.  This week I want to provide a few helpful tips to explain how you can help your pals in the business keep up.

Have a release plan – 

Software projects in my organization have a budget along with a beginning, middle and end according to the executive leadership.  To the suits at corporate, they don’t know or care about sprints, iterations, and burn downs.  So we have been forced to come up with a bridge document between the backlog and what the leadership expects.  This is the release plan.  Since my leadership does not understand the terms epic, theme and story; we substituted the words milestone, feature, and story.  This made it easier for the executives to follow along.  In our backlog we organized everything by milestones then placed features under them and finally had stories under those.  What happened was a revelation.  The business owner knew what was expected to be completed and then wrote stories to accommodate that structure.  Sprints were now planned around delivering features and we were doing better at delivering what the business wanted instead of what the business owner wanted.

Metrics –

Professional athletics is concentrated on metrics.  How fast you can run.  How high you can jump.  How many interceptions you throw during a football game.  The game of metrics has been transformed by the practice of sabermetrics and “Money Ball.”  Development which is done primarily by engineers has been very poor at measuring performance.  This is why I have started to measure the team velocity in story points.  I am also comparing the amount of work scheduled versus the capacity of the team.  This provides the team with positive reinforcement along with upper management a way to gauge how we are doing.  I will also be doing more advanced things like comparing bugs with velocity and understanding if we have good code quality compared to team morale.
 

Developer and Scrum Master training –

I find it interesting that we are working on software which runs the business but the developers and scrum master do not know a lick about the business.  That is changing.  I am spending about 90 minutes a week learning the business with people on the front line.  This training will become a training program for all the developers on the team.  Each of us working on the project should be competent enough to work as an entry level employee using the software.  This is a new experience for me and my developers.  I don’t know why we did not think of it sooner.

Tender loving care for the business owners – 

My organization has had a spotty record with business owners.  They have taken a training course in how to be product owner and then they have been left to fend for themselves with little direction from their business units or help from the scrum teams.  I have made a point of each business owner I work with giving them a copy of Roman Pichler’s fine book “Agile Product Management with Scrum.”  I also spend time with them helping them groom stories so that the developers know what they are doing and can deliver that in one sprint.  I help them tie stories into the release plan.  The product owner has one of the hardest jobs in an agile organization.  Your scrum team will not succeed if the product owner doesn’t.

The most important part of the agile manifesto is to adapt to change over following a plan.  Well we are changing and this is how we are doing it.

Until next time.