Announcing the Scaling Software Agility One-Day Course!

I am happy to announce that I’ll be presenting a one-day overview course based on the book: Scaling Software Agility: Best Practices for Large Enterprises, in London, England on February 27, 2008, and in Boulder, Colorado on March 19, 2008. This course is sponsored and hosted through Agile University.

Who should attend: Software development directors, managers and team leads; software developers, testers, architects, and QA personnel whose objective is to provide a step change in the productivity and quality of the software development process but who are faced with the challenges of developing software on an enterprise scale.

Class size is limited so there will be lots of opportunities for questions and discussions relevant to your enterprise context.

To see the course abstract or to register, click here:

Scaling Software Agility: Best Practices for Large Enterprises – A One-Day Course

If you are interested in an on-site presentation of the course, please contact me directly.

Hope to see you there.

Dean Leffingwell

Top of Form

A Three-Track Strategy for Enterprise Adoption

In my blog entry of a few days ago, (Ideal Training for Enterprise Agility?), I noted that Pete Behrens (www.trailridgeconsulting.com) and I were collaborating on a leveraged enterprise rollout model, that is, a model for education and consulting that could help a larger enterprise (hundreds to thousands of developers) start to achieve the benefits of agility in a year or less without spending themselves blind with teams and teams of consultants in the process.

Since that time, Pete and I have further documented more of our thinking, and Pete took the next stab in his recent blog post: An Ideal Coaching Strategy for Rapid Enterprise-Scale Agility? While the body of this article is devoted primarily to Pete’s description of a leveraged “mentor-trains-the-internal-coaches” strategy, we also noted that we see three distinct and significant tracks necessary for rapid and successful adoption and rollout. These are (portions quoted with permission):

“First, and foremost, the creation of an internal agile enterprise transition team drives the enterprise vision for the agile transition and also facilitates its implementation. Implemented properly, it re-orients the transition from a top-down mandate to a middle-out and bottom-up buy-in of the impending change.

Secondly, shared-learning achieved through outside training is a critical success factor in an enterprise-scale transition. This addresses the basic need for understanding, mastery, consistency, and coordination of the many new techniques across the multiple interdependent teams that are necessary to deliver large-scale business solutions in a substantially agile manner.

Last, but not least, is the need for experienced agile mentoring and guidance. While training is necessary for an enterprise consistency and understanding of agility, it is not sufficient. Training is often separated from the reality of the environment and project issues teams face. Moreover, fully leveraging an ideal training scenario is not always practical and gaps in understanding as well as practice will certainly remain.”

Taken together, the tracks provide “wide and deep” coverage for the many changes inherent in enterprise-scale adoption:

• Wide in that all practitioners and stakeholders receive some amount of agility training (see training post)
• Deep in that all development teams and role-based practitioners on those teams receive both in depth, role-based training (see training post) as well as consulting and mentoring support (see consulting post)
  

For more on this thinking, please read Pete’s deeper discussion on each of these topics in the post: An Ideal Coaching Strategy for Rapid Enterprise-Scale Agility?

Also, if I get a chance in the next couple of days, I hope to elaborate more on some of the leverage coaching ideas that are expressed there too.

Two New Enterprise Case Studies

I’m always on the lookout for documented case studies of agility at enterprise scale which highlight impediments, lessons learned, anecdotal benefits, and wherever possible, hard metrics of improvement in productivity, quality or morale. I’ve (b)logged two such case studies, the transformations at BMC Software and Salesforce.com in this blog under the category “Case Studies”.

Since then, British Telecom, and Siemens each presented an experience report in presentation form at the Scrum Alliance Gathering in November of 2007. While not exactly written case studies with lessons learned, benefits, metrics, etc., and while it’s unclear exactly how many practitioners they transformed, these presentations do provide insights of agile “crossing the chasm” in two extremely large software enterprises.

They can be found on the Scrum Alliance Website at:

Agile at Siemens

Scrum at British Telecom

Ideal Training for Enterprise-Scale Agility?

Pete Behrens (www.trailridgeconsulting.com) and I were formulating a training strategy for a significant enterprise that is contemplating an “all in” (immediate and across the entire company) enterprise scale transformation approach. Based on my experiences at BMC Software and his experiences at Salesforce.com, as well as some of our larger, ongoing clients, we had a chance to reflect on what we would recommend as the “right” amount of training to ensure success. We concluded that for the enterprise, a combination of team-based and role-based training that would touch every practitioner is ideal. The summary of our training recommendations by role is seen in the figure below:

With this model, all team practitioners receive a minimum of two days of agile training, (agile team training for the each team in the enterprise) which we recommend as the minimum requirement, with an additional day or so of training for specialized roles of Product Owner, Project/Release Manager, and Agile/Scrum Master. All other executives and managers are invited to attend an overview course on scaling software agility.

Each of these courses is described in summary form below.

Agile for Teams –Essential, team-based training in a two day workshop setting that introduces the philosophy, principles, and benefits of agility, agile methods, iterative and release framework, roles, agile technical practices, and agile management practices (Scrum). This is an interactive workshop with a specific project context producing a draft release plan and first iteration (sprint) plan. Training should also include those enterprise extensions applicable to the company’s context.

Agile Release and Project Management at Enterprise Scale – For Project Managers, Release Managers, Program and Portfolio Managers who have responsibility for helping deliver the product(s) to the marketplace. Topics include differences between traditional and agile product management, iteration framework, multi-level release planning and tracking, the agile release train, planning and executing the release planning event, and measuring enterprise progress.

Agile Product Owner in the Enterprise – For team-based product owners/candidates who will become responsible for backlog management, story writing, and iteration and release planning, and who will also be involved in the planning and coordination of larger scale software systems of systems built by teams of teams.

The Agile Master In The Enterprise – For potential agile team leads/future Scrum Masters who will be coaching agile teams and who will interact with other teams as well. Topics include: process facilitation, enterprise agility, mastering the iteration, team roles, release planning and tracking, agile leadership, empowerment and conflict management, and integration Scrums.

Agile Product Manager in the Enterprise – For enterprise product managers with product, product line, portfolio and business unit responsibilities. Topics include: what’s so different about agile, backlog and prioritization, relationship to product owners, PM’s role in release planning and management, visioning and the product roadmap.

Scaling Software Agility – Best Practices for Large Enterprises – For executives and key stakeholders in support, distribution, quality, internal IT, HR and all others whose roles will be impacted by the substantive changes that enterprise agile engenders.

• Part I – overview of agility highlighting lessons learned from the most common and effective agile methods
• Part II – seven team best practices of agility that natively scale to the enterprise level
• Part III – seven organizational capabilities that companies can master to achieve the full benefits of enterprise scale agility

I’m curious to hear whether others think this is too much or too little and what other patterns trainers have found to be effective?

How Enterprise Agile Adoption Can Fail

The Top 5 Challenges that I Have Personally Seen

I was in attendance at an enterprise agile rollout risk/mitigation session last week where the topic was brainstorming ways in which the rollout of enterprise agility could conceivably fail. The idea was to identify the potential failures modes, and then put in place a risk mitigation strategy for those that jumped to the top of the pareto chart. Much of the session was relevant only to that companies particular context, but it gave me a chance to reflect on the major risks that I have witnessed – not imagined, but actually experienced – and here they are:

• Dev managers/executives who either don’t believe in agile or hide behind the rationale that it takes a very long time to deliver quality software and that an extensive period of analysis and design is necessary
  before any value delivery, i.e.
  • (“we need 4-6 months of analysis and design now to avoid future rework”)
• Teams can’t execute basic technical practices that are necessary to meet short iterations.
  • Whether due to Lack of training, commitment, ability, infrastructure or whatever, let’s admit it – agile is hard at the engineering level
• HR/organization policies do not support personnel change driven by agile, i.e.
  • (“Our people are our asset, is it incumbent on us to make them successful here, and in their current role”)
• Forced prioritization rejected flatly by Product Managers who simply mandate that they want it all and it is all critical, i.e.,
  • “we must have it ALL and by THEN or we cannot compete in the marketplace”
• Executives having to admit that they cannot predict or guarantee long term deliverables, i.e.
  • “We are a professional company, we can and do make specific, long term commitments to our customers, they, nor I, expect anything less.”

These are some tough challenges for the agile champions, but as with any addiction, recognizing the problem is the first step towards recovery!

Meeting Deadlines – “Tiger Teams” vs. Agile Project Management Practices

Often times when introducing some of the basic agile project management practices to new teams (for example, the daily standup) some of the more experienced (ok, older) team members comment on the fact that these techniques look a lot like the techniques they used in the past when their projects were in deadline trouble. Indeed, most of us have similar experiences with challenged projects and when a project is struggling, and the deadline approaches, we would always fall back on some tried and true disaster recovery techniques. We’d form “tiger teams” that would typically work as follows:

• Quickly form a team of key, dedicated individuals, representing all the necessary disciplines
• Empower the team to cut scope as necessary in order to achieve the deadline
• Meet daily, first thing every morning (meet twice daily as the deadline approaches)
• Bring honesty and complete visibility to actual, objective (not planned) project status
• Commandeer outside resources as necessary
• Continue doing all the above until deadline achieved

We immediately see the parallels to agile project management, reflecting again that agile is not so much new, as a synthesis of some of most effective and highly tactical project management techniques from prior experience.

Parallels are as follows:

Tiger Team Action	Agile Team Principle
Form a team of key, dedicated individuals, representing all the necessary disciplines	Get the right people on the team. All necessary disciplines (define-build-test) must be present. Dedicate the team members for the life of the project (iteration or release).
Meet daily, first thing every morning (meet twice daily as the deadline approaches)	Daily standup. (Plus we have observed many teams doing twice daily stand-ups as iteration or release deadlines approach.)
Empower the team to cut prioritize and cut scope as necessary in order to achieve the deadline	Product Owner who is a team member, empowered to manage priorities and cut scope is systemic in agile
Bring complete visibility to actual, objective (not planned) project status	Empirical, demonstrable frequent outputs in hands of product owner and customer
Manage/commandeer outside resources as necessary	Commit resources, eliminate outside impediments that inhibit success
Continue doing all the above until deadline achieved	Repeat for every iteration throughout the project lifecycle.

In other words, the best way to keep projects out of trouble is to apply the same intensity at the beginning of the project as we used to do at the end. While this may seem intense for the routine day to day existence of the project, the actual result is sustainable and highly productive development process that avoids the enormous deadline pressures we used to see at the end, as the illustration below shows.

Patterns of Agile Adoption

In this months newsletter from the Agile Journal, (www.agilejournal.com) Mike Cohn identifies six core patterns of adoption that have been applied in a number of companies over the last few years. The patterns are:

• Start Small or Go All In
• Technical Practices First or Iterative First
• Stealth Mode or Public Display

This is an excellent article that weighs the advantages and disadvantages of the specific approach on each of the three axis. In addition, it is already generating some comments from practitioners further discussing the nuances and challenges with each pattern. I recommended reading it, especially for companies who are considering agile at scale.

It can be found at:

http://www.agilejournal.com/articles/articles/patterns-of-agile-adoption.html

Responsibilities of Agile Product Owner vs Enterprise Product Manager

Building on my own experiences as well as Jennifer Fawcett’s whitepaper (agileproductowner.com) and the webinar from Catherine Connor and Rally, there are indeed some some substantial changes in the role of Product Manager in a before and after agile enterprise, as the table below shows.

As we understand these differences, we start to see a significant divergence in responsibilities as well as better clarity in the responsibilities of the Enterprise Product Manager (market and customer focused) and the Agile Product Owner as the following table describes.

More on Product Manager vs Product Owner, Webinar from Rally

Speaking of product managers and product owners, Catherine Connor from Rally Software (and a former compatriot of mine at Rational), recently presented a webinar entitled “How Product Management Must Change to Enable the Agile Enterprise”. Here’s the abstract:

As more development teams adopt Agile processes to increase their responsiveness to customer needs, traditional product managers need to change the way they work to keep up with shorter development cycles and feedback loops with their customers. This webinar will propose solutions to the challenges product managers face when moving from traditional development teams to Agile teams.

This is a sensible and practical webinar wherein Catherine also posits that these roles are typically separate in an agile enterprise. The webinar is available on line at:

http://community.featureplan.com/community/2007/11/webinar_november_29_enabling_the_agile_enterprise.php