If you’ve already started using Agile methods, surely you’ve seen just how much change and adaptation are involved — already at the single team level!
If you’ve already applied Agile methods across a program, or several unrelated teams, you’d have noticed that their performance is constrained by downstream and upstream functions. Your teams are likely saying, “We need marketing and sales and the business units and operations to also act like us in order to really make an impact.”
And if you’ve been using Agile for more than a couple of years, is performance still great, or is it eroding? Are the Agile mechanisms slowly giving way to “business as usual”?
More than a year ago I was training and consulting with a company that was deciding how to adopt Agile software development methods across all of their teams in the organization after some successful pilots. After a 2-day private Scrum course we decided to use the 3rd day to run a workshop on how to take their organization’s strategic business goals and support that with Agile methods adoption and Lean thinking across their project portfolio. This article will share the facilitation techniques and exercises that I used, which spanned many techniques that could helpful to others supporting strategic decision-making meetings:
Hope this gets folks started in looking at Cynefin and methods around complexity. My one suggestion for anyone getting to know Cynefin is make sure that you don’t look at the “Cynefin Model” and misjudge it to be a basic 4-box model. There are actually 5 domains and a fold at the bottom that have tremendous significance in the model. Not only that, the model is about sense-making rather than categorization. With a focus on these suggestions while learning more about Cynefin I think will help make the experience more beneficial.
As for an experience report from the actual client. A company that I was asked to work with wanted a 2-day Certified ScrumMaster course along with a 3rd day workshop to focus on their specific needs. Of course, during the 2-day class we pulled many specific areas of opportunity and ideas that the group had. The participants were about 1/2 Director and above and the other 1/2 were development team members and project managers. There were about 30 folks in the class and the 2-day class was providing plenty of insights.
One thing that I am focused on in every class is not how can Scrum be implemented but what is the most valuable next steps an individual, team, or organization can make starting the very next day. In the 3rd day workshop we decided to focus on the business goals that implementing more agility would help achieve and a strategy to attain these business goals. Overnight I came up with a loose facilitated session with the following exercises:
1. Impediment Management Exercise using basic facilitation techniques:
Brainwriting: 10 reasons per individual that Scrum and other agility cannot be implemented effectively at company
Affinity grouping: on a wall place all items and affinity group them with names to provide context and insights into to the data
Multi-voting: not a scientific method necessarily, but quick way to get feedback on what is most important on the wall
each table comes up with a strategy for implementing agility to attain business goals and value of agility (20 minutes)
1 person is chosen by table to go to another table and present the strategy for 5 minutes – important that all tables have a chair at the end of it to have the visitor form the other table sit at
folks at the table that are listening to the strategy are not allowed to speak during the presentation
at 5 minutes the person presenting turns their chair around with back to folks at table and takes out a notebook
the folks at the table now ritually tear apart the presented strategy (be sure to tell all of the participants before the exercise that this will be occurring and that their duty is to be as cutting as possible) (3 minutes)
at 3 minutes the person that presented does not turn around and make eye contact or talk with the table of folks and then just goes back to their own table with all of their notes
the table uses those notes to modify their strategy (10 minutes)
the presenter goes to a different table 2-3 more times
you can end with a round where the folks at the table talk about what they liked about the strategy once it has went through 3-4 rounds but we did not do this (this is called “Ritual Assent”)
at the end it was fairly simple to pull strategy from all tables and since they shared with each other we decided what the combined strategic alignment and implementation would be presented to executive management
As an epilogue to this, the company did implement most of the strategic plan and found effective changes in their organization even 2 years later since I was there. Hopefully this article provided some opportunities for those facilitating strategic decision-making sessions and added some other options to learn about, Cynefin and Innovation Games® in particular, to your facilitation tool belt.
An ex-colleague of mine, Santosh Kolhatkar, wrote up the following points about introducing an Agile approach inside a large enterprise with an existing traditional SDLC process. What he points out in his writeup regarding a foundation for introducing an Agile approach when there is a heavy focus put onto SDLC compliance and governance is in alignment with what I’ve found to be useful in supporting such efforts in large enterprises. With Santosh’s permission, I have posted his ideas on the subject and thought that it would be useful for some readers of our blog:
Agile is now making waves in the sea of other methodologies and paradigms. Practitioners at the enterprise level are taking note of the new kid with the new shiny toy on the block. And the sharks are circling the waters.
We ran in to this situation at several of our client’s environments. The SDLC processes were so much entrenched that the Agile approach seem to be very radical to those practitioners, so some of the leaders got together and came up with an approach that seem to be less threatening to those paradigms.
The major steps that were taken:
Involve key members of that community.
Identify ‘must have’ components. These are the areas such as compliance, security etc.
Make a list of differences between processes and get feedback from the key members.
Get an agreement on how the existing SDLC and Agile methods will work together. Handoffs and managing the dependencies is crucial.
Outline of before and after an Agile framework is deployed.
Provides an overview of what to expect for the teams that are thinking of using an Agile approach.
Summarize the differences between the existing SDLC practices and Agile framework.
Bring the existing SDLC and Agile methods under one umbrella.
Offer as a one stop shop for the practitioners so they can choose to go SDLC or take an Agile approach.
Have a combined launch of the latest SDLC version and the Agile framework.
Use existing communication channels to reach out to the enterprise audience. People are used to looking for processes and procedures at one location. Using the same location or method will get better results in communications.
Implement ability to push Agile metrics onto program management dashboards.
Agile metrics should be able stand on their own but provide enough visibility that leadership looks for in their conventional metrics.
The metrics should be more real time and close to the actual state of the projects/ programs.
Have an executive sponsor who can serve as Champion for the new Agile framework.
Provides air cover for the adoption of the new Agile framework.
Provides a stamp of approval that is a must in a enterprise environment.
The above areas are minimum needed to make adoption of Agile feasible in enterprise environments with an existing SDLC process. Some combination or extension of the above steps will have to be made to suit specific enterprise situations.
The Agile Triangle, a concept that was discussed by Jim Highsmith in his book Agile Project Management: Creating Innovative Products, describes how teams and organizations can go beyond the traditional Iron Triangle in defining project success criteria. In the Agile Triangle, the traditional project constraints of schedule, cost, and scope are confined to one point of the triangle. Balancing out the triangle are quality and value. Agile software development practices have provided huge innovations in delivery of working software from an internal and external perspective. Practices such as automated unit testing, Test-Driven Design (TDD), and Continuous Integration (CI) have transformed our industry and enabled new go-to-market strategies for the business of software products.
When looking at the Quality point on the triangle, this is where I see the realm of Managing Software Debt providing a strategy to support greater value generation within the defined project constraints, as shown in the diagram above. Creating a software debt management strategy involves thinking about feedback mechanisms for each type of software debt: technical, quality, configuration management, design, and platform experience. For technical debt, which tends to be focused on code, we can use tools such as Sonar to provide feedback on changes. For quality debt, we can look at defect containment metrics, bugs escaping iterations and into releases, as a feedback mechanism to trend. Configuration management debt could include the ability for an application to use 2 scripts, deploy and rollback, for all environment deployments and promotions along with monitoring branching in source control for potential integration issues (Sonar is integrating this capability, as well). Design debt can be monitored using Sonar and design assertion frameworks such as TisUgly for Java that I created and never marketed well a couple years ago. Finally, we can monitor the effectiveness of our platform experience debt management strategy based on impediment resolution cycle time or other team and management measurements.
This last point about impediment management is incredibly important and doesn’t get enough attention in the Agile community, in my opinion. In fact, as someone who is experienced in supporting enterprise Agile adoptions for defined business objectives, impediment management can be a critical element of sustained Agile software development effectiveness. When organizations hit a wall with impediments, mostly organizational impediments to delivering increased value to customers, they become susceptible to reverting towards past practices to reduce noise and ignore the effects of these impediments. The diagram below shows how impediment management is a wrapper around the Agile Triangle to support increased and sustained value delivery over time.
Impediment management comes down to communication. How are impediments raised? When impediments are not within the team’s realm of control to resolve, how does management support their resolution? At enterprise scale, is there a need to provide visibility to more than 1 or 2 levels higher in the organization? If so, how do these enterprise impediments get handled at strategic levels in the organization? What is your impediment management strategy?
Please let us know your thoughts on the relationship of impediment management and Agile Triangle. Also, tell us in the comments section how you see impediments managed in your organization. What is going well? What could be improved? How are they escalated? We look forward to hearing your thoughts and experiences.
One of the many benefits of Scrum is early identification of roadblocks that could stop a Team from meeting their goals and commitments. At the Daily Scrum meeting, team members typically answer 3 questions:
What have you worked on since we last met?
What will you be working on until we meet again?
What impediments are blocking our progress?
Many teams start with these 3 questions but then have difficulty not making this meeting into a status meeting for managers. The real focus of this meeting is to identify issues that could impede the Team’s current Sprint delivery commitment. We create burndown and other visible charts and tools to help us spot impediments early so we can respond more effectively.
In our Scrum courses, we make sure that Teams, and especially the ScrumMasters, know how to manage impediments for a Team. There are three main categories of impediments, each managed a little differently.
Some impediments can be fixed by the Team themselves. Some of those are good to track for visibility to the whole Team.
Some impediments are not entirely within the Team’s realm of control and therefore must be escalated so that management around the Team can help resolve them. ScrumMasters must find out how to get the correct folks involved and guide these impediments to resolution.
There is a smaller, but crucial set of impediments that are organizational in nature. They are bigger than any one Team and will involve changes in organizational policy, structure, or governance to resolve them.
It is important to adopt a communication plan that addresses how impediments will be managed and escalated in a scaled Scrum environment. In our consulting with organizations that have scaled Scrum teams, we’ve learned just how important effective impediment management at the individual, team, organization, and executive levels can be. When not handled well, the risk of not meeting date and budget commitments increases significantly.
Given the importance of impediment management on dollars and dates associated with a release, we’ve enhanced AgileEVM to manage impediments at the release, project, product, program, and project portfolio levels. There are 6 attributes to an impediment that we have found useful to manage them effectively:
Importance of impediment resolution (Blocker, Critical, Major, Minor)
Action suggested to be taken (optional until impediment is assigned and understood)
Owner (optional until someone is assigned to resolve impediment)
Due date of when it must be resolved (optional)
Release it was identified in (optional)
When impediments are entered into AgileEVM, they are made visible on the “Impediments” tab for every level of the project portfolio.
Remember that using Agile methods such as Scrum do not solve your problems but they do make identifying them early much easier. Only through good communication channels and action do true improvements result from using Agile methods.
How do you manage your impediments at different levels of the organization? We’re always glad to read your comments.
Along with our current training offerings around Certified ScrumMaster (CSM) and Certified Scrum Product Owner (CSPO) courses, we will also be offering training for:
Agile Portfolio and Release Management using AgileEVM
Managing Software Debt Workshop (based on our book)
Online training and micro-consulting
Although we have been training these unofficially for some time now, these are new official offerings, we are looking for companies and individuals who are interested in taking these courses for a discount. Please let us know if you are interested in test-driving any of these offerings.
CSM and CSPO Training
Lets not forget our CSM and CSPO course listings. You can find a full list of our classes on the Scrum Alliance and on our web site. We will be holding CSM and CSPO classes back-to-back in San Francisco on the following dates:
Of course, our CSPO course will include introductory training on the use of Innovation Games® to gather data from your customers and stakeholders. We feel strongly that a healthy relationship with your user community and stakeholders is essential to delivering great products.
In fact, we have been working with our customers over the past 6 months on enhancing and improving our own product, AgileEVM. You can take a tour of AgileEVM on our training video page. Please register for a free account today if you don’t already have one. You can manage up to 2 active releases with your free account so please try it out and let us know what you think at AgileEVM Support.
We are looking forward to a great year in 2011. Please let us know if you are interested in our training or consulting services at Sterling Barton.
I am quite happy about the book that took much of my time over the past couple years has finally come out. Thank you Addison-Wesley for asking me to write a book. Also, I want to thank Jim Highsmith and Alistair Cockburn for accepting the book into their Agile Software Development Series. Finally, I have to thank all of those that have guided, influenced, and supported me over my career and life, with special thanks to my wife and kids who put up with me during the book’s development. My family is truly amazing and I am very lucky to have them!
You can now share your portfolios with as many people as you like at no extra charge. Our unique value-based pricing on active releases helps you promote transparency because you can share information with as many people as desired.
You have the ability to choose Read-Only or Read-and–Write access for each person you share a portfolio with. You can also unshare your portfolio contents at any time. With the ability to integrate and share portfolios you can aggregate many releases into a consolidated view of multiple portfolios.
Enhanced portfolio metrics provide clear financial information and forecasts. EVM metrics are more clearly labeled with both traditional EVM abbreviations and human-friendly labels.
You can still manage up to two releases at no charge. With our release report feature you can also prepare and send out reports to your colleagues for free!
If you don’t already have an account register at http://www.agileevm.com today and help your organization become more value driven than cost managed!
AgileEVM (http://www.agileevm.com) is a powerful way to view performance of your portfolio. The portfolio focuses on releases because this is the only unit of work where cost and benefits can really be compared.
Using outcomes from each iteration, rich information is provided. Take a look!