Why Scrum isn't enough for agile success

Ok, this may seem like heresy, but Scrum isn't enough for organizations to succeed with agile on software development efforts.  Scrum provides techniques for the incremental definition and management of work and Scrum describes the roles, collaboration, and communication patterns for Scrum teams.  While these address some software development challenges, their are several others that must be considered to achieve the hyper-productivity that's possible with agile.

When I discuss agile with my customer/clients/prospects, I advocate a mashup of Scrum and Extreme Programming (XP) practices and activities.  Scrum provides the management framework and XP the developer and individual contributor best practices.  Additionally, if your practicing agile at any level of scale (more than 3 teams that are collaborating on a release), there are important "program management" and "product planning" activities that both Scrum and XP do not address.

So when I evaluate how agile an organization is, here are the key activities and practices I look for:

1. Cross-functional teams that include the customer (or their proxy), development, test, documentation and any one else required to create "the whole product"
2. Incremental delivery of production quality capabilities at regular intervals
3. Test-driven development that builds quality in from the beginning
4. Automated and unattended build, test and reporting and I maniacal focus on build quality

And for enterprise class agile, we've got to consider program and product management.  There are some in the Scrum community that advocate the "Scrum of Scrums" and "Super Scrum" for these activities respectively.  I've seen these used quite effectively. 

1. The Scrum of Scrums is a program management meeting.  It's run by a Scrum Master, attended by all Scrum Masters and Product Owners,  and typically occurs twice a week.  Its a tactical meeting where Scrum Masters discuss cross-team impediments, team acceleration or deceleration, and other topical issues.
2. The Super Scrum is a product planning meeting.  Its run by the Chief Product Owner, attended by all Product Owners and Scrum Masters, and is held about twice monthly.  The purpose of this meeting is to discuss long term product vision and direction and to continuously evaluate product-level backlogs and priorities.  For this meeting to be effective, it must stay at the vision, theme, and epic level.  Lets leave it to our teams to do the heavy lifting!

A successful agile implementation relies on the existence and interplay of all of these practices and activities.  It is not easy to get there and there are many practical challenges and considerations.  But with team and management support, and a fair amount of intestinal fortitude, the hyper-productivity of agile is within your reach!

Comments

[Mike Cottmeyer]

Just found your blog today... there were a few key points that I really agree with.

The phrase 'production quality capabilities' is insightful... it is not always a end-to-end user feature. I also appreciated your acknowledgement that scrum does not really deal with program and product management. Scrum of Scrums and Super Scrums are a starting place... but some organization require even more complex coordinating teams.

So... thanks for the role you played in creating scrum... it is an awesome way for teams to build products. I am excited to see how Scrum evolves over the next few years to deal with more complex organizations and more complex products.

[Dennis Stevens]

This is an excellent post. It is key for people moving into Enterprise Agile to have the understanding that it is hard work, requires changes in project/program management, engineering, and leadership practices. But you can't jump into scrum or scrums or super scrums on the first day. And you probably shouldn't start with Engineering practices alone.

The introspection, accountability, feedback and learning mechanisms from organizing around small teams are first order practices. You are correct that Scrum is not sufficient, but a small team approach that includes discipline around introspection, accountability, feedback, and learning (e.g., Scrum) should be adopted first.

[Llewellyn Falco]

Automated Tests, and Automated Builds are all about keeping code malleable. To use a system like scrum which embraces change and integration, and NOT use practices to allow for change is CRAZY.

Iterative changes work great for clay, it's a disaster for marble.

[Rod Claar]

Nice post, John. When an organization is changing from a less-agile pattern, I get also get them to concentrate on delivering business value. Many of the old habits and the new agile practices are concentrated on rather than delivering what the business / customer needs. This makes many of the decisions and changes much easier.

[Dennis Stevens]

I agree Llewellyn. But this isn't really a cart and horse discuss. With a new team of experienced developers - you fire these up simultaneously. If you and I go into a client - we fire these up simultaneously. But if you go into an established team that isn't doing agile - you establish the cross functional team and put the introspection, accountability, feedback and learning mechanisms in place first. Then you hire Llewellyn to do the forensic development and get the code base under control including automated testing and builds.

[Chad Albrecht]

Great post! The other important factor outside the Scrum team is accoutability. If you have a sales team, PMO or IT group that is not delivering on promises, you will have trouble with any process.