«

»

Jun 10

Go with the flow

I’m curious about something. Our economy isn’t that steady and strong, as we would like. A lot of companies are struggling to keep the money flow going and most of them have to take cutbacks to stay on top. When you look at most companies who are depended on software or any kind of IT development most of them are still running their project in a sort of waterfall way. Not only are they trying to run these projects in different steps just to stay in control (requirements, design, implementation, deployment etc.). Something that most of us know does not work, but most of them are also working with budgets.

I’m not sure if this works the same in other countries as well but in the Netherlands most of the large firms and government-funded projects are working with huge fixed budgets. Every year project, and program, -managers are working their ass of to get enough budgets for the next year. They have to prove that the money is needed for various work and they must somehow predict the future. You also have to understand that when they don’t finish up their given budget for this year, they likely get a lesser budget the year after. So at the end of the working year, the budget has to be depleted. You can imagine the bullshit that is being sold at most companies so that these managers can have their budgets for the next year. Believe me, I have been running projects that just had to be kept running just to empty the pile of money. So you can imagine my embarrassment on this. I’m talking about a lot of government money that could have been spent in a better and more useful way.

So why is it that most companies, either government or commercial, are still working with budgets. One thing is that somehow within the system people only look at what is spend instead of what is gained. I attended budget validation meetings that only focused on how much something would cost to build or deliver. And not about how much it would earn. This is also one of the reasons most companies are working with man-hours and estimating in time. This simply does not work. In agile environment we look at business value. What is there to gain and how can we get there as fast as we can. We don’t want to be bothered with budgets, monthly, weekly or whatever. But how can we do this and keep al the number crunchers happy.

First of all, get rid of the budget thinking. Stop calculating how much something might cost. Start looking at how much something is bringing in. Reverse the money flow in this. Can you imagine that you only have to calculate how much money a scrum team is making every time they deliver software and that you can sell the teams based on this number to the customer. In order to do this you also have to change the budget allocation. Don’t think in big piles of money, start looking at it as a continues flow, like a valve that you open and close depending on the need. If a project is in a state of continues delivery of valuable software, than the flow can be adapted. When they stop, you can close the valve a bit. You don’t shut it because people will have to get their paycheck. This also motivates to start new innovative but most of all valued work. But stop looking at projects as big money pile absorption things. Start bringing in a calculated flow. This also means that at the end you might end up with extra money. Because if you keep the flow going there is know need for re-budgeting all the running budgets. And managers can start focusing on delivering work. Instead of budgeting you do have to start forecasting. How will the flow run and when do you need to start opening or closing the valve.

When projects do not bring in any money, you can close the valve. So you will not end up with software development projects that just keep on running just because they can. They will keep running because they make sense.

Does this sound obvious or do you think it is plain bullshit? I’m not saying that it is easy. And just to be clear about this, I’m not a financial expert. I run projects using some sort of Agile model. But I used to work as a project manager. And I have seen that the budget thinking simply does not work. The larger companies are working with budget systems for so long that trying to change these is a very tough job. And for most of them this is nearly impossible. Or so they think. In most cases it just takes one to change the world. Start thinking outside the box. And in an age where radical cutbacks are on a daily bases, what would be the harm to try a different approach.

Picture: Running Tap by Simon Howden

Permanente koppeling naar dit artikel: http://agilethings.nl/go-with-the-flow/

  • Maarten

    Interesting post. I work for an internet agency and we struggle with budgets vs agile on a daily basis. I like the idea of reversing the money flow but can’t imagine this happening in, for instance, a corporate website. The corporate website is often seen as a marketing activity, not as valuable software. I agree that it could be valuable but as long as the organization structure in large firms won’t changed I think your last conclusion is unfortunately true: it won’t be easy…

    Organisations would benefit if they started thinking in terms of business value for all their (internet) projects and of course this would also make our lives more meaningfull. Do you have any experience in calculating the value a scrum team brings every time they deliver software and use that number to sell to the customer?

    • This is sometimes not that easy, as business value is different for every product or company. Sometimes it is money but it could also be efficiency that in turn will convert into money. There is a way to determine business value delivered. As a team uses Scrum poker with Fibonacci scale, you can also let Productowners determine the value with the same scale. For example a low value story is one. A two is twice the value and a five is five times as high as the one. Obvious. Then you have to let the team do the work. The prioritization with Fibonacci determines the importance of the stories picked and delivered by the team. At the end of the sprint you can also measure the amount of BV delivered. On it’s own this is nothing yet. But you can plot this on a burned graph. And every sprint you can see if the BV delivers is trending up or down. Or states the same. Then calculate the ROI on the project. Over time the graphs should give a clear indication about the fact if a project is delivering value or not. The higher the number the more value. The only thing is to put a price tag on it. Team-number x days of sprint x number of sprints/backlog BV.

      The challenge is to start somewhere and grow. I know this all sounds a bit in the pink clouds and fluffy. But it is also that you must not try to predict to much upfront. Just watch and learn. Adapt where needed and try. But the most important thing is to stop thinking in projects and set delivery time. Sofware is not a thing you can put a wrapping around. It is a more like a financial service. You adapt to the need. And the flow adapts with it.

      • Maarten

        Thank you for the detailed response! I completely agree with your last comment to stop thinking in projects with delivery times.

  • Pingback: Velocity is not your goal | Agile things()