Delivery Counts in Agile

You are successful when you deliver.

One of the most common misconceptions about agile is the belief most of the time and energy of an agile team is spent talking about creating software instead of building it.  Plenty of articles have been written about the subject.  I disagree strongly and this week, I want to talk about it. 

At the scrum gathering of 2014 in New Orleans, one of the Keynote speakers joked about deadlines not being real.  He said flippantly there is always another sprint and work is never finished.  The rest of the room chuckled because each of us had heard this sentiment echoed by a developer or testers.  I have said it myself in jest.  The truth is deadlines matter in agile.  If a team is not delivering software at a steady cadence then it is not a good team.  

The empirical nature of software development with agile demands the delivery of software for customers.  If the team is struggling to deliver a shippable increment at the end of a sprint it is up to the team during a retrospective to figure out how to do better.  Instead of solutions being imposed from above, it is up to the team to come up with answers.  

The team coming up with solutions to problems is called self-organization.  Experienced developers mentor junior developers.  Business people provide meaningful direction about how the software should operate.  In the middle of it, all is the scrum master who helps remove impediments and forcing the team to become better.  It is a process that requires plenty of conversation and experimentation.  The bo-product of these efforts is working software in a production environment.  It is why the agile manifesto says, “Working software of comprehensive documentation.”

Software professionals are not successful unless they are delivering value to stakeholders and customers.  In the consulting world, you are not paid if you do not ship software.  In the enterprise systems world, shipping software affects pay-raises and promotions.  Being flippant about being able to deliver working software is a lousy career move.  

The process of Scrum requires the team to deliver value to customers.  Each iteration the team does show off what the team has delivered and gives them a chance to prepare for the next series of work.  The customer sees each step of the way and they can make corrections if necessary.  

I am touchy about this subject because the accusation that agile does not deliver value has no merit.  An agile team delivers each sprint, and if they cannot they self-organize to find a way in which they can.  We still spend plenty of time talking about software but in the world of agile all of that conversation is focused on the delivery of working software.  

Until next time.