Yes, you can forecast software delivery dates with agile

Agile is often mis-used by product development teams to mean, “what ever we end up delivering”. That just isn’t right. It gives Agile a bad name. It’s incorrect and mis-applied by those that don’t understand what Agile is.

At VitalSource, we use Scrum as a way to apply Agile principles to the way we develop, deliver and maintain software product. Scrum gives discipline to the way we do Agile. The artifacts and ceremony around Scrum are important and keep us moving forward. Daily stand-ups, sprint demos, story grooming sessions, retrospectives gives us a cadence that insures we are doing the right thing, delivering value, removing impediments, and communicating with stakeholders and with each other.

Can we make commitments to delivery dates with Scrum? The answer is absolutely yes. We do it successfully all the time. But, before I jump into that, let me first say that because software has no constraints set by the physical world, estimating software complexity is a notoriously difficult thing to do, and you have to understand complexity before you can have accurate estimating. By complexity I mean - how much work will it take to build a software product, which implies, how hard will it be to do? There was a time when there was a lot of work put into figuring out software complexity, but by and large, in commercial software development no one does anymore, but rather the focus has been on better techniques to deliver software product.

To be clear, waterfall models were (and still are) terrible at software completion estimates. Large specs were written, which inevitably couldn’t cover all nuances and use-cases, the specs were handed over to user interface designers, who would design interfaces no one could implement, which was then turned over to developers, who would scramble to write code that matches the specs and user designs, and the dates would slip because the developers had to go back to the spec writers for clarity, and the spec writers would have to re-write the spec, and maybe consult with an end-user, while at the same time the business owners would be harping about the delivery date that could not be missed, developers would have to squeeze in more time, rush to the end, hand it over to QA, who would rush through testing (because you were already late), and developers and testers would fight over bugs, and then everything would be turned over for acceptance testing, which you never really had to time to do, and finally you get the product out the door, most often late, buggy and incomplete, only to find that the delivered product did not end up looking like the spec which was written months before. It was a nightmare, which pitted people against each other.

Scrum takes a radically different approach to software development by putting product managers, QA engineers, and software developers on the same team, working together on a sprint-by-sprint bases to incrementally deliver business value in the product that can be seen and used. Each increment, or sprint, gets you closer to the end game - the product delivery date. The beauty of the model is that after each sprint, the team reassess what is left to do, measures risk, re-prioritizes work, and moves on to the next sprint. Users stories, which represent business value, get completed each sprint and so the product gets incrementally done - and that includes closing bugs so they don’t accumulate until the very end. During the sprint demo everyone gets to see the product evolving. Every sprint represents an opportunity for the team to do a course correction on the path to successful product delivery.

At VitalSource, we deliberately use the term “forecast” when talking about delivery milestones. Because that is what it is, a forecast. The farther out in time it is, the less trustworthy a forecast is, the closer, the more accurate it is. A team can forecast that, “we believe it will take us ten 2-week sprints to have that feature complete”. They base that on their understanding of the their cadence and the complexity of the features (user stories). We have found that our forecasts have been pretty accurate, and have several successes that demonstrate so. We will naturally have time where forecasts will be off, but the beauty of Scrum is that we find out sooner rather than later, because after each sprint we can see if we believe we are on target.

Can we commit to “firm” dates? Yes, we can, and we often do. This is particularly true when we have commitments with external customers or partners. This is essentially “time boxing” the work. In order for a time-boxed effort to work, the team has to develop a prioritized list of work and agree on the minimal needed, and agree that the minimum can comfortably fit into that time-box. If there is time left, they can work down the prioritized backlog of features. Again, we have had success doing this, and I have seen it work may times in my career.

One of the best feelings in the world is to get product out the door. Even better: an awesome product that our customers are excited about and solve their real problems.

Making Product and Engineering work

One of the tenants of the Agile Manifesto is that we value “Individuals and interactions over processes and tools”.   That doesn’t mean we don’t value process and tools, but rather that teams of highly motivated people, working together, and empowered to make decisions in order to get product out the door, can do amazing things.  I have seen it many times in my career.  We get better product, better people, better teams and better retention.

Almost paradoxically, I also really believe Kristof Kloeckner’s insight that:

“Agile without discipline won't scale. Discipline without Agile can't compete.”

Too many software product teams define agile as “whatever we end up delivering”.  That’s doesn’t work and that’s where the discipline part helps.   That’s also why I like Scrum.  Done properly, Scrum adds enough discipline to make agile work.  Sprints, backlog grooming, daily stand-ups, sprint demos, all add structure to the way we do agile.

It’s been my experience, both here at Vital Source and in my previous companies, that the roles of Product Manager and Engineering team in Scrum can have conflict, unless we have some understanding upfront of who owns what.  The way we have chosen to explain ownership is by what questions each role answers:

Product Manager answers: “why” and “what”
Engineer Team answers:  “how” and “when”

Even though we choose to define roles this way, hopefully this doesn’t mean that we don’t listen and get feedback and input when answering these questions.   Here at Vital Source we have Product Managers who have a good understanding of technology, and Engineers who have a good understanding of the Products we deliver, which facilitates discussion and consensus.

To clarify the roles some more, the Product Manager owns the priority of the backlog, and the message of why things are in the backlog and why they are in that order.  PMs spend time talking to sales, account managers, stake holders and customers in order to prune and manage the backlog.  PMs spend a lot time in both outward and inward communications about the products they manage.

The engineering team is responsible for the execution of the backlog.  By using estimating techniques, the engineering teams estimates how many sprints something will take and when coding and testing will be done in order to deliver a solid product.  When considering implementation, the engineering team will make time for technical debt, and make decisions on tools, languages and software architectures.

If would not be appropriate for the engineering team to change the backlog order without sign off from the product manager, neither would it be appropriate for the product manger to commit to a delivery date or technology implementations with out sign off from the engineering team.  When I personally see these things happen, I speak up.  Hopefully others do as well.

That’s not to say we won’t make mistakes along the way.  We are all at different stages of learning the process and coming up to speed on what we do.  I hope we can be tolerant of mistakes and helpful when things go wrong.

If we can truly learn to value "Individuals and Interactions" and worked towards being a jelled team, we can deliver great product and have fun in the process.

Technology teams should own customer-facing products, not technology

In a business that is responsible for delivering a technology product, I think something incredible wrong happens when a group of engineers feel they are responsible for delivering technology and not for delivering a product that gets delivered to market.  The engineering team starts to focus on the wrong thing - building more technology instead of building business value.

This is a core value that drives the decisions I make and the way I approach technology leadership, and drives the product delivery model I implement.  This is one of the reasons I like Scrum teams - properly done, they encourage this style of ownership.

Engineering teams should be aligned with business units that deliver customer value.  They should be strong participants in and contributors of the culture.  They should understand the business.  They should know and interact with the business teams, they should have a tight relationship with the product managers.  You will get better product, you get happier engineering teams, more retention.

I love it when technology teams feel like the "own" a product and are passionate about it, rather than being soulless cogs in a machine processing tasks assigned to them.   As a big added bonus, if you have ownership, process becomes a lot easier.

If you want better technology product, make your engineering teams responsible for the product they deliver, not for the technology they build.  You will get better product AND better technology,