In the software development world, the mantra since 2005 was leaner teams and RFRO- Release fast Release Often. A significant portion of the software industry, adopted Agile Software Development methods, creating new methodologies such as SCRUM, XP, 25x, etc. The inefficiencies of First Generation Project Management methodologies [such as Waterfall, Cyclical, Spiral and even Prototyping], were overcome using Agile. Agile methodologies helped high-tech firms when Industry velocity was higher than that of a standard product release cycle.
A word of caution to the reader – if you are a strong believer in 25x product development, stop reading further…….
25x – is an extreme Agile methodology wherein the firm hires 1/2 super coders, who single-handedly design,develop and launch world class products, within a short timeframe(normally 1 – 2 months). These companies surely differentiate from the rest of the industry -but the difficulties in retaining these 25x developers and having them toe the firm vision line ever, could tire out any management team.
In the first part of this article – I focus on listing the common myths related to the practise SCRUM. (as seen on Ground Zero)
In second part of this article – I expound upon the myths in detail and try to provide solutions.
In part three of this article – I look at some of the benefits of SCRUM – in terms of enhancing engineering productivity through fostering a culture of innovation, and also argue that if the SCRUM pitfalls(aka myths) prevail over the benefits, it could lead to a downward spiral in team productivity and innovation morale, for the firm and team.
Today’s high-velocity firms – be it web startups or teams within large product organizations, need to innovate at a much more rapid rate than has ever been seen in the history of the modern industry.Innovation in these industries is defined as the ability to release new products or enhancements to existing products, which provide significant value enhancement to customers by improving some aspect of their lives.
The reasons are few, but evident..
a) The Consumer is everywhere – if the products these companies launch have to succeed, the customers have to find it useful, flawless and compelling for reuse.
b) Word spreads pretty fast –faster than for any other good – If the product is good and consumers like it, they would use it right away, and would most probably recommend it.
c) No Second chance – The audience either likes it and moves away after First Use. Acquiring customers through Advertisements, keyword spendings,or by means other than through providing value is bound to drain company finances. The age of page views, unique visits and stickiness is slowly changing..
Compare this with other industries in the high tech space say the hardware (PC, Laptop, Ipad, Iphone) industry, where design times are large and product roll out times are larger, dedicated sales teams build previliged relationships with customers and channels and dedicated customer support staff add on to firm revenues.
The imagination of its smart technical engineers have to be harnessed into a product’s development process, and wonders have to be created out of just the imaginations of smart people.
The benefits of SCRUM:All said and done, SCRUM has been touted as the super-efficient way of work – that solves all problems plaguing traditional software development. For the benefits of SCRUM refer to this beautiful article on wikipedia. –http://en.wikipedia.org/wiki/Scrum_(development). Albiet, SCRUM like any great way of work is not without pitfalls.
Here are the common myths of SCRUM..
First Myth: The myth of a 6 or 5 hour work day.
The Second myth: The individual chooses the work – It is self-managed
The Third Myth: Small teams work better
The Fourth Myth: My team’s productivity improved because of Agile.
The Fifth Myth: myth of engagement of all team members in decision making
The Sixth Myth: short meetings are a lot of fun
Myth 1:
All proponents of Scrum state that 6 hours is more than really what one could code, and recommend an alloted 6 hours for working on the project. This 6 hour structure (or in some cases 5 hour structure) is used in sprint workbooks, or tools to manage each engineer’s task-day. While the ideal is 6 hours, how many people really finish their work within those 6 hours…especially given that it’s software. Tasks being broken down to 12 hour tasks are again based on engineering estimates. There is no solution here – since engineers who pick the task sometimes choose the number of hours needed to do the task – and most of the time they end up shooting themselves in the foot. In several teams the 5 or 6 hours extends to beyond that, for each engineer has got to give his status in the next sprint meeting, or that day’s sprint meeting…..On an average if the estimate is bad not only does the 6 hours extend to 12 hours, but it can cascade into every one else’s 6 or 12 hour window, and make the sprint look very bad.
To be continued….
Reflections on Technology, Project Management 