The Scrum approach to agile software development marks a dramatic departure from waterfall management. Scrum and other agile methods were inspired by its shortcomings. Scrum emphasizes collaboration, functioning software, team self management, and the flexibility to adapt to emerging business realities.


Scrum based funding model – 20 percent

Posted by ewok_bbq under Agile and Scrum, Scrum Basics

Sorry for the long pause between blog posts.  I’ve been traveling way too much lately.  This week I was excited to participate in the Scrum Gathering in Las Vegas (you can search through twitter utilizing this hashtag #sglas).

I saw many industry colleagues and re-connected with folks like Lyssa Adkins whom I hadn’t seen in a year or more.  I attended a number of sessions and I had two favorites.  One was on removing impediments with drawings, see: where I will do a write up on that session in a later blog post.
My other favorite will be the focus of this blog post.  It was the keynote session by Jeff Sutherland, PhD and co-Creator of the Scrum framework.  The topic was called Scrum: The Future of Work
The thing that caught my ear about his talk was his concept of moving to a 20% funding model for new product development teams.  That is to say, stop funding projects at the 100% level.  Instead, businesses can quintuple down their business bets by investing 20% of their money across five different projects. The portfolio managers, Uber POs, business stakeholders can stop incrementally at the 20% stage of the budget cycle to re-evaluate and re-organize teams by examining the business delivered between the five separately funded projects.
The POs of each individual project will be re-evaluated based on value delivery and predictability at only a 20% timeline. At the end of each release or budget cycle – the individual POs can re-request additional money based on the value delivered not on how ‘busy or efficient’ we are keeping individual team members – which in turn keeps prod dev teams continuously pushing hard because they only get 20% of their funding.  It also tests the long held 80/20 rule which states that you can deliver 80% of the value in 20% of the time.  Because the teams are developing vertically your sol’n are ready to get pushed into production at the end of the 20% budget cycle for immediate customer feedback.  If you have a predicable team doing the work you will know how much value you will deliver well ahead of the release and as a portfolio mgr you can make adjustments to your five bets based on that metric not on whether Bob or Sally seem busy today.
What are the pre-requisites to make this work? 
  • Stable cross functional teams with known velocities.  You won’t compare velocities of the team (that’s bad form), but you can compare their relative increases against one another as part of your funding decisions.  From there – you can compare relative velocity growth to the costs of your team to get a cost per feature metric which can then be evaluated against your Earned Value or Agile EV Metrics.   If you aren’t doing this – please do consider calling CollabNet so I can help get this set up for you and your teams.
  • A FOSS based software environment that compliments the elasticity of Cloud Deployment strategies.  A non FOSS environments means having enough commercial licensing in place to meet the demands of autonomous teams using elasticity to map to continuous deployment strategies.  This doesn’t work in most regulated industries so be careful if you have external compliance here.
  • Building in vertical slices so that we can push to deployment and leverage (b) above.
  •  Having the ability to measure ‘business value delivery’ vs. saying ‘efficiency of individuals’ – see the EVM stuff in (a) above.
  • Your accounting team / source of financing needs to be able to re-evaluate investments more often than a yearly budgeting cycle
If you don’t have these prerequisites in place work on getting those in place before trying the above.
Happy scrumming.
Tags: ,