How do you fund these agile projects?

I had the good fortune to finish Benjamin Day's training course about scrum master skills.  I highly recommend you visit Pluralsight and take his course.  One of the more exciting things about his training was the conversation about how to do annual budgeting with Agile and Scrum.  This week, I want to discuss my observations on the subject.

Isaac Socalich wrote a blog post about “Legacy thinking” holding back agile adoption at organizations.  He cites the way projects are funded, saying that accounting practices lead organizations to fund and allocate resources only once around a product, project, or process improvement.  In short, a project has a start, middle, and end.  The project's people, funding, and output are cells in a spreadsheet that manages the project.

This legacy financing model is short-sided, counterproductive, and the antithesis of the agile movement.  The Agile manifesto stresses “Customer collaboration over contract negotiation,” with legacy financing of projects, every activity is reduced to contract negotiation.  The project is conceived with unrealistic expectations.  The deadlines for completion do not reflect the opinions of those doing the work.  Customer considerations are ignored, and the funding is, at best, a guess done by an accountant.  It is no wonder so many software projects fail.  

The most aggravating part of legacy thinking is that it treats consultants and people who do the work as machine tools, which can be replaced when they are no longer helpful.  Teams are created and disbanded based on funding formulas rather than business needs.  This means technical professionals are being treated like mercenaries to build software.  This also creates technical professionals who have no personal investment in the products they are creating.  They are temporary workers billing hours and doing work without genuine concern for quality.  

For example, an off-shore team is working on software and disbanded because of a lack of funding.  The finance department restores funding four months later, and a new team is spun up.  The original developers are gone, along with the two years of experience they had on the project.  The organization must now spend the first six months of the project training the offshore team about the business and navigating the legacy code.  The remaining six months of funding are spent attempting to do a year’s labor.  Quality suffers, deadlines are missed, and the customer is dissatisfied, but the business correctly funded the project.

Software teams should be professionals invested in the business and each other rather than disposable Lego bricks.  Projects should be spun up and spun down being given to these project teams.  These teams should remain constant while the projects come and go rather than vice versa.

It is why I like Benjamin Day’s approach so much.  Instead of setting arbitrary deadlines and features to be done by the development team, which has no investment project's success, the team is permanent with growing business knowledge, technical skills, and projects as they are funded.  The business people also concentrate on setting priorities of what gets done.  The project is not thrown over the wall for IT to figure out or fail.  Finally, the business can cancel the project if it is not working.  The team remains to take on the next challenge.  The company either discovers it has working software for the customer and does not need as much funding, saving money, or has been making a poor investment and can cut its losses.

Over the last fifteen years, the Agile Reformation has greatly improved software development. Still, business leaders and finance teams are not changing their processes to accommodate this new approach. They do so at the risk of their own business.  Survival is not mandatory, and these legacy finance issues will be a cancer in many companies in the future.  It is up to us in the agile movement to try and help those worth saving.  Otherwise, technologists will be condemned to careers of temporary employment, failure, and frustration.

Until next time.