How my agile is changing

Those of us in the agile community spend much time discussing 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.  I am discovering 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 – 

According to the executive leadership, software projects in my organization have a budget along with a beginning, middle, and end.  The suits at corporate don’t know or care about sprints, iterations, and burn downs.  So, we have been forced to develop 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 can you jump?  How many interceptions do you throw during a football game?  The metrics game has been transformed by sabermetrics and “Money Ball.”  Development done primarily by engineers has been deplorable in 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 team's capacity.  This gives the team positive reinforcement and 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 –

Interestingly, we are working on software that runs the business, but the developers and scrum masters do not know a lick about the industry.  That is changing.  I spend 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 use the software as an entry-level employee.  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 a 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 given each business owner I work with 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 most demanding 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 by following a plan.  We are changing, and this is how we are doing it.

Until next time.