Bindings, Platforms, and Innovation
This presentation focuses on the Internet and separating myth from fact, history from the future, and the mundane from the imaginative. Bob Frankston presents a vision of what could and should be.
Tracking change and innovation in the enterprise software development community
Posted by Vikas Hazrati on Sep 30, 2008 07:00 AM
Sustainable pace suggests that teams should work hard but at a pace which is sustainable and can be maintained indefinitely. It suggests that if a team puts in more effort than the sustainable pace then after a few weeks the velocity tends to decrease and a burn out sets in. In a recent coaching session with OpenView Venture Partners, Jeff Sutherland was shown quantitative scores to support this point. In a similar study, Clinton Keith noted the effect of longer hours on team velocity.Jeff was shown a “Maxwell Curve” which depicted that when the team put in more than 40 hours then the velocity of the team went down. According to OpenView Venture Partners, as venture capitalists they always wanted people to work harder than 40 hours a week to double productivity, however now with Scrum the situation is different. According to them,
Now it is different with Scrum. In order to double our productivity we need to work less, certainly no more than 40 hours a week. Scrum is intense and you cannot work extra hours at that pace without losing productivity.
In a similar study, Clinton Keith noted the effect of longer hours on team velocity. According to him if instead of a normal 40 hour week the team was asked to work 60 hours week then the velocity tapered off after the first couple of weeks. Though, in the first couple of weeks under crunch mode the velocity was greater than that of 40 hour weeks, gradually it started to fall and eventually a 60 hour week produced less velocity than the 40 hour week.
Other similar studies show that productivity eventually drops when teams operate at unsustainable pace.
On the flip side, Clinton does caution that people sometimes take a flawed interpretation of sustainable pace. Some teams drop parts of their sprint goals if they are faced with too much to do in a 40 hour week. According to him, sustainable pace should not be an escape route for teams to drop committed sprint goals. Once commitments have been made, teams should strive hard to meet them and constantly look for small improvements during the course of the sprint which would allow them to utilize time more effectively. A 1% improvement per sprint would allow make significant impact in the long run.
According to him working more than the sustainable pace once a while is not harmful, however it should not become practice.
If it's the last Sprint before a major release we'll see teams putting in a couple of weeks of late nights and rarely a weekend. If they find that they are doing this too often, they need to improve how they estimate.
Thus, sustainable pace does allow teams to be more productive given that it is cautiously used, not abused.
Agile Development: A Manager's Roadmap for Success
5 Ways to Ensure Application Performance
Ensuring Code Quality in Multi-threaded Applications
The Agile Business Analyst: Skills and Techniques needed for Agile
I just blogged about this great presentation yesterday. It's also from the game industry and related to sustainable pace and productivity.
Kevin E. Schlabach
Agile Commentary Blog
Perfect! the presentation is bang on with the news item. Thanks.
This presentation focuses on the Internet and separating myth from fact, history from the future, and the mundane from the imaginative. Bob Frankston presents a vision of what could and should be.
This article explores the use of JBoss and jBPM to implement design solutions that effectively address the issue of orchestrating long running activities.
This presentation covers the use of graph databases as an optimal solution for data that is difficult to fit in static tables, rapidly evolving data or data that has a lot of optional attributes.
This session introduces Real Options and shows how it can help in running your project. Real Options is a decision-making process that can be used to manage risk.
This article discusses the use of bindings on services and references (including the instance of non-configured bindings) as the means to implement SCA communications in a Web and SOA environment.
After a short introduction to DSLs, Scott Davis plays with the keyboard showing how to approach the creation of a DSL by typing working snippets of Groovy code that get executed.
IBM Rational and InfoQ present, Scaling Agile with C/ALM, an eBook showing organizations how to become “finely tuned software delivery machines” by enabling team integration and scaling.
Amanda Laucher presents a real life enterprise application written in F#. She shows actual code snippets, explaining design decisions and suggesting how to use some of the F# constructs.
2 comments
Watch Thread Reply