Category Archives: Scrum

Agile, Agile Leadership, Executive Scrum, Facilitation, Fun, General, Leadership, Open Source, Scrum, Training

Example Facilitation of Agile Adoption Strategy Session

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:

For more information on Innovation Games®, please check out:

For more information on Cynefin, please check out the following articles and videos:

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
  • Debrief actions to take

2. “Give them a hot tub” - an Innovation Games® exercise (http://innovationgames.com/resources/the-games/)

  • Used to identify goals and initiatives that would improve business outcomes focused on software development

3. Ritual Dissent - http://www.cognitive-edge.com/method.php?mid=46

  • set up tables with 6-7 folks per table
  • 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”)
  • Find out more alternatives and ideas on Ritual Dissent at the Cognitive Edge web site

4. Combine Strategy

  • 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.

Acceptance Testing, Agile, Agile Leadership, General, Hi Performance, Leadership, Push-Button Release, Scrum, TDD, XP

Towards a Push-Button Release

This presentation is being delivered as a 45-minute lecture and discussion for a company-wide tech talk today. It contains 2 case studies that revolve around moving to a push-button release that reduced the whole product company’s release cycles from 6 months to every week and the effects of a “No Defect” policy on a team’s productivity.

Towards a Push-Button Release
View more presentations from Chris Sterling

Agile, Agile Leadership, AgileEVM, Executive Scrum, General, Portfolio Management, Scrum, XP

Implementing Agile in the Shark tank

2 Comments

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.

Acceptance Testing, Agile, AgileEVM, Architecture, General, Iterative Design, Java, Open Source, Product Owner, Scrum, Software Architecture, TDD, User Stories, XP

Managing Software Debt in Practice Presentation

Today at the Scrum Gathering in Seattle, I held a session on “Managing Software Debt in Practice” where we got into:

Managing softwaredebtinpractice 2011
View more presentations from Chris Sterling

The presentation had too much for the less than 90 minutes that we had for the session. I did not get into scaling Scrum team patterns and heuristics to manage software debt at scale and also less around testing than I’d hoped. Hopefully it was useful for the participants and they got at least one new idea leaving the session. It is difficult to take a 1-day workshop and create a less than 90 minute talk, as I learn again.

Acceptance Testing, Agile, Agile Leadership, AgileEVM, Architecture, General, Leadership, Product Owner, Scrum, Software Architecture, TDD, User Stories, XP

Interview: Assessing ROI of Addressing Software Debt

This week, an interview from SearchSoftwareQuality.com with me came out on the book Managing Software Debt: Building for Inevitable Change. The interview has 2 parts. The first is a discussion of software debt and the second focuses on addressing software debt. Here are links to the interview:

  • Managing Software Debt Interview with author Chris Sterling Part one
  • Assessing ROI of addressing software debt Interview with author Chris Sterling Part two
Agile, Agile Leadership, AgileEVM, Executive Scrum, General, Hi Performance, Leadership, Portfolio Management, Product Owner, Scrum, TDD, XP

Impediment Management and the Agile Triangle

5 Comments

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.

Agile Triange (Jim Highsmith*) adding Software Debt
Agile Triange (Jim Highsmith*) adding Software Debt

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.

Agile Triange (Jim Highsmith*) adding Impediment Management
Agile Triange (Jim Highsmith*) adding Impediment Management

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.

Agile, Agile Leadership, Facilitation, General, Hi Performance, Leadership, Scrum, Training, XP

Approaching Conflict: Be Honest Then Ask for Help

3 Comments

I talk to people in training classes, in consulting engagements, and when out with colleagues about situations of conflict. There is quite a bit of literature out there about how to manage and resolve conflict. There is one single phrase that I use to provide others guidance on how they can work with others to resolve conflicts:

Be Honest Then Ask for Help

I will give an instance of this from my real world. We were working on a team that I was ScrumMaster on. One of the best developers I know seemed to be having difficulty making it to important meetings and also in meeting commitments with the team. The rest of the team was even starting to notice and voice concern about this person’s contributions. In a one-on-one discussion I first described the situation in an honest way:

“I noticed lately that you are not getting to some of our important meetings and seem to be having troubles keeping up with the work we are working on. In fact, other team members made some comments to me about their own concerns.”

Then I followed this up by asking them what is going on and what we should do about it:

“You have been an excellent team member and this recent behavior concerns me in terms of the team and for you. Do you have any ideas about what is going on and how we should address it?”

Come to find out this person was having heavy family issues over the past 2 months. They were so consumed with these family issues that they were not really aware of how much their behavior was impacting the team. They told me that they would like to talk with the team about their situation before the next day’s Daily Scrum meeting. When they told the team about their situation the entire team was very supportive and said they would help and make up for any impact to planned deliveries if they would just keep the team informed about any adjustments that need to be made to handle important family issues.

Conflict Types

In our Certified ScrumMaster course we provide a list of conflict types:

  • Lack of clarity - we just don’t have detailed enough information to create a common view
  • Position focus - we are discussing a topic from at least two different perspectives
  • Different values - our philosophies or principles are not aligned
  • Past history or personality - our previous experiences or personality trait we are familiar with distracts us from healthy resolution

The first two, “lack of clarity” and “position focus”, make up a significant amount of the conflict that we come in contact with. Fortunately, these are also the easiest to resolve in my experience. When there is a lack of clarity we can analyze more to make visible data that could help us clarify the situation. For a position focus conflict, we can usually find something that all parties can agree on within the larger situation or topic. From this point of agreement we can work through it until we have a sufficient resolution to move forward with.

Now, the last two, “different values” and “past history or personality”, are a bit more difficult. I have been known to be principled in the past and take a stand when I thought that I could be put into a position of being part of something I didn’t believe was good or valuable. The stance I was taking from a value-based position caused the other people involved to get frustrated with me. In these cases, I have found that we can isolate the pieces of the overall situation or topic that make either party take such a strong position and then work on them through negotiation. It can take some time to work through conflicts involving different values. For past history or personality, sometimes we can just try to start anew and take some advice from one our former U.S. presidents:

“Trust, but verify” - Ronald Reagan

Agile, Agile Leadership, AgileEVM, Architecture, General, Iterative Design, Kanban, Leadership, Portfolio Management, Scrum, Software Architecture, XP

InformIT Interview with Chris Sterling

1 Comment

Matt Heusser, on behalf of InformIT, conducted an interview with me regarding the book Managing Software Debt: Building for Inevitable Change. We discuss what software debt is, some ways that it can be managed, maintaining a single list of work, how software debt is measured, and we even got into training and our product AgileEVM.com. You can read the interview at http://www.informit.com/articles/article.aspx?p=1684785.

Agile, Facilitation, General, Scrum

Faster, Better, and Cheaper than Sticky Notes (Post-Its)

7 Comments

For several years now, I have been using less and less sticky notes. This is because I use something much better: Drafting Dots. They work better, last longer, cost less, do not harm any surfaces, and make my life much easier.

Now, I can easily use mail merge or tables to print out stories using four cards per page. I use card stock (120# in US) and often use colored paper to color the product backlog. Any printer, a paper cutter and I am quickly ready with a stack of cards that work like index cards or sticky notes for emergent conversation and valuable collaboration. We can lay things out on tables and then put things on walls which, is something sticky notes cannot do well.

I am always ready with index cards and drafting dots. They are cheaper and easier to use in many flexible ways. I have seen drafting dots hold up cards for a month and then get moved without issue. Try them out, you may find yourself using far fewer sticky notes.