Enterprise Agile Transformation on InfoQ

Written by Mike Cottmeyer Saturday, 29 December 2012 04:41

infoq-logo

Hey everyone… it’s been a while, huh? Lot’s to tell you guys about the goings on the last few months at LeadingAgile, but that is a post for a different day. Back at Agile2012 I recorded an interview with Shane Hastie on large scale enterprise agile transformation. That interview finally got produced and posted on InfoQ back in November. Here I am in late December finally getting a link up on LeadingAgile. Hope you enjoy it!

http://www.infoq.com/interviews/cottmyer-enterprise-agile-transition


Your Team Is New To Scrum

Written by Derek Huether Tuesday, 11 December 2012 11:45

Your team is new to Scrum

If your team is new to Scrum, they don’t have the advantage of looking at their previous velocity before making commitments to the business

A while ago, I published a post titled: Simple Cheat Sheet to Sprint Planning Meeting.  Though I understand every team is different, I thought it would be helpful to those who are new to agile processes.  People are always looking for cheat sheets, templates, and stuff like that.  What is the harm of giving them what they want?

In retrospect, I think the harm is the lack of context.  When people come to a training class, they are provided an ideal situation.  Even the Scrum Guide was written as though you’ve been doing Scrum for a while. It doesn’t talk about things that happen leading up to your team’s first Sprint.  It doesn’t talk about the complexity of scaling to the enterprise.  It’s just vanilla.

I just got back from coaching a new team and I’ll be heading back next week to see how they are doing.  To get them moving forward, I facilitated release planning and sprint planning.  That’s where things can get interesting.  What if your team has never done release planning or sprint planning?

Release and Sprint Planning

The purpose of Release Planning is so the organization can have a roadmap that helps them reach their goals.  Because a lot of what we know emerges over time, most of what we actually know is that we have a lot of unknowns and “unknown” unknowns in our future.  Still, our organizations expect us to predict the future so they can make better decisions.

The purpose of the Sprint Planning is for the entire team to agree to complete a set of ready top-ordered product backlog items. This agreement will define the sprint backlog and is based on the team’s velocity or capacity and the length of the sprint timebox.

If your team is new to Scrum, you don’t have a velocity (rate of delivery in previous sprints) and you are not sure of your capacity (how much work your team can handle at a sustainable pace).  What do you do?

The Backlog

The product backlog can address just about anything, to include new functionality, bugs, and risks. For the purpose of sprint planning, product backlog items must be small enough to be completed (developed, tested, documented) during the sprint and can be verified that they were implemented to the satisfaction of the Product Owner. 

Again, your team is new to Scrum.  How do they know what small enough is?

Right Sizing Backlog Items

Product backlog items determined to be too large to be completed in a sprint, based on historical data of the team, should not be considered as sprint backlog candidates during the sprint planning meeting and should be split into smaller pieces. Remember, each story must be able to stand on its own (a vertical slice).  It should not be incomplete or process based (a horizontal slice).

Again, your team is new to Scrum.  They have no historical data.

Determining Velocity

The velocity of a team is derived by summing the estimates of all completed and accepted work from the previous sprint.  By tracking team velocity over time, teams focus less on utilization and more on throughput.

If you have a new team, not only do you not have a velocity, you won’t have any completed work to compare your estimates to and you won’t know how many deliverables to commit to.  What do you do?

If Your Team is New to Scrum, I Recommend

You and your team need to just go for it!  You keep track of what you are completing and collect historical data.  You get through the sprint and establish some context for future sprints.

The first few sprints are going to be pretty rocky, until the team begins to stabilize. Just ask yourself.  WWDD?  What would Deming Do? Plan a little; Do a little; Check what you did versus what you planned; Act on what you discover.  One challenge I’ve experienced is an organization wanting the team to make delivery commitments during their first few sprints. All of the upfront planning in the world is not going solve that problem.  Once the team starts to deliver and their velocity improves, things settle down. But I’m asking the organization to give up the false predictability until things stabilize. That part is hard but critical.

Join the conversation. There is currently 1 comment.

Agile at the Speed of Trust – Organizational Trust

Written by Peter Callies Tuesday, 4 December 2012 11:04

This post is part of a series focusing on the synergies between Agile and trust.  The book The Speed of Trust forms the definition of trust and the framework for this series.  The Speed of Trust uses a definition of “organization” that is relative to the reader.  If the reader is part of a team, that could be the organization.  If the reader is in charge of a department, that could be the organization.  If the reader is the president or CEO of a company, the entire company could be the organization.

We often talk about needing to focus on three primary areas when adopting Agile: people, processes, and organizational structure.  Organizational structure is the grouping of people and relationships between those groups.  The approach to this is critical because it provides the environment for shared accountability and alignment.  However, establishing the environment clearly isn’t enough.

The “third wave” of trust in The Speed of Trust is organizational trust.  This is the wave that deals with developing and maintaining trust with internal stakeholders of an organization to assure alignment.

As a way of communicating the importance of organizational trust, the book lists the following “taxes” that are paid in a low-trust organization and the “dividends” received in a high-trust organization.

Taxes Dividends
  • Redundancy
  • Bureaucracy
  • Politics
  • Disengagement
  • Turnover
  • Churn
  • Fraud
  •  Increased value
  • Accelerated growth
  • Enhanced innovation
  • Improved collaboration
  • Stronger partnering
  • Better execution
  • Heightened loyalty

Organizational trust builds on the 4 Cores and 13 Behaviors from The Speed of Trust, many of which are described in previous posts of this series.  As the book says, “[The cores and behaviors] are the keys to creating organizational alignment and trust. They empower you to…speak about trust in a way that promotes understanding, dialogue, and problem solving, and to behave in ways that build trust.”

The book asks the reader to question whether the organization’s behavior in relation to the four cores (integrity, intent, capabilities, and results) supports trust.  An Agile organization has a leg up in this area because agile principles and practices reinforce the cores.  Here are some examples.

  • Agile enables organizational integrity because it helps create a culture of making and meeting commitments.  In a Scrum environment, commitments are made and met with every sprint.
  • Agile validates organization intent via cross-functional teams and frequent check points that ensure that the output of the team is what the team intends and what the organization needs.
  • Additionally, it’s really hard to have a trust-destroying hidden agenda (nefarious intent) when results and plans are being inspected at frequent, regular intervals.
  • Agile reinforces the caring, empathetic aspects of intent by emphasizing a sustainable pace of work, helping individuals trust that the organization values them as people, not just as expendable resources.
  • One of the core tenants of Agile is continuous improvement.  By allowing teams time to focus on improving their capabilities (processes, tools, and skills) the organization builds trust.
  • Attention to organizational results is achieved by ensuring everyone is aligned with a shared vision.  Agile achieves this at a low level via cross-functional teams and frequent interaction between the business, often represented by someone playing the role of Product Owner, and the teams.  When Agile is scaled, this is achieved via cross-functional program and portfolio management.

The book then asks the reader to consider how the organization’s culture encourages the 13 individual trust behaviors.  A previous post talked about how Agile impacts these behaviors, but these behaviors can be put to interesting use in terms of a retrospective.  Try using the Satisfaction Histogram technique from Agile Retrospectives with some of the behaviors forming the evaluation criteria to determine where your organization stands and what you might want to focus on to improve trust within your organization.

Join the conversation. There are currently 2 comments.

PMI Puerto Rico Simposio Anual

Written by Derek Huether Tuesday, 13 November 2012 07:27

Imagine barely missing the Nor’easter up in Connecticut, only to land in sunny San Juan, Puerto Rico 24 hours later for the PMI Puerto Rico Simposio Anual. That was me last week. My time in Puerto Rico was short but I met some amazing people and had a great time.  I spent one day offering a seminar on Agile Project Management and one day as a Simposium Speaker.  There was a lot of interest around Agile and what it is (and what it is not).  It was exciting to have the opportunity to interact with a completely different group of people, not focused on U.S. Government related work.  Just to confirm, not everyone is Washington D.C. is, but I would argue a large group I spoke to last month at the Washington DC PM Symposium were.  The people I spoke with this last week were entrepreneurs, company presidents, and managers…  What I found as the common thread was not on keeping a schedule or staying on budget.  It was about satisfying customers, maximizing ROI, and responding to constant change.  Regardless of the language barrier on my side, they could understand what I was talking about, confirmed by the nodding heads and mouthed “sí.”

I want to thank PMI Puerto Rico for being such amazing hosts.  There is something very notable I want to point out about their symposium.  Much like the symposium attendees, the organizers’ primary concern appeared to not be keeping the symposium on a tight schedule.  The focus was ensuring the people attending got as much value as they could provide in the time they had.

Join the conversation. There is currently 1 comment.

Transforming Mountains

Written by Rick Austin Tuesday, 6 November 2012 09:42

In early October my wife and I vacationed at Cape San Blas, FL and I was struck by the beauty of the brilliant white sand on the beaches. They are impossibly white and it made me wonder how that sand came to be. I became fascinated by the time it took and the processes that made it so. I learned that when walking on that sand, I was really walking on ancient material from the Appalachian mountains. Eons ago the Appalachians were taller than the Himalayas but through the ages they have continuously been worn down and transformed. All of that material flowed towards and was deposited into what is now the Gulf of Mexico. The continuous motion of the waves deposited quartz that came from the Appalachians onto the beaches of Cape San Blas and other beaches on the Emerald Coast.

This extraordinary amount of time made me think about the time it takes for any type of change, including transforming an organization to work in an agile manner. Change is difficult, and much like the weathering away of the Appalachians, it takes patience, persistence, and focus on changing the right things at the right time. Successful agile transformations include elements of the following:

  • A clear understanding of the existing organization: The landscape if you will.
    • What is driving the desire to move to agile?
    • What structures need to be changed?
    • How does the organization deliver value?
  • Are there capabilities in place to deliver value: Are the right processes in place to turn mountains into sand?
    • Does the organization have appropriate skills in place?
    • Are practices in place that are required for agile teams to deliver value?
    • Is strategy connected to team’s ability to deliver value?
  • Are the people aligned and wiling to change: Are forces working together and persistent?
    • Are people willing to work in ways that are different than what has made them successful in the past?
    • Is there a commitment across team members to collaborate and work together more frequently?
    • Do people understand the time needed to change and are willing to have the patience to see it through?

When there is organizational support for making structural changes, agile practices are embraced, and individuals are willing to change then conditions are suitable for a successful transformation. Just as suitable conditions were in place eons ago for the Appalachian mountains to be turned into brilliant white sand.

Even with conditions suitable for change, persistence and patience is required. Agile transformations in an enterprise are difficult because of the scale of change. Transforming enterprises, like transforming mountains, is difficult and takes time. Agile transformations don’t take eons, though they may feel like it, but they don’t’ take weeks either.

I often hear that we’ll just send some folks to a class or two and we’ll be agile. Just taking a couple of classes with no other transformation strategy is like banging on a mountain with a hammer, it may be a good way to start but much more is required. Your organization must have a real commitment to change and the patience to see it through if you intend to create your own white sand.

Here’s to improving your organization’s ability to deliver value, to your ability to create your own version of Cape San Blas’s brilliant white sand.

Join the conversation. There is currently 1 comment.

Public Training Locations

Upcoming Training Classes


2-Day Agile Requirements Course
2-Day Agile Requirements Course
April 7-8 Orlando, FL
Advanced Agile Development with Dr. Alistair Cockburn 3 Day Master Class
April 14-16 Alpharetta, GA
3-Day PMI-Agile Certified Practitioner Course
April 14-16 Reston, VA
3-Day PMI-Agile Certified Practitioner Course
April 28-30 Alpharetta, GA
3-Day PMI-Agile Certified Practitioner Course
May 5-7 Denver, CO
2-Day Agile Requirements Course
May 15-16 Alpharetta, GA
2-Day Certified ScrumMaster Training Course
May 19-20 Alpharetta, GA
3-Day PMI-Agile Certified Practitioner Course
June 9-11 Alpharetta, GA
3-Day PMI-Agile Certified Practitioner Course
June 16-18 Reston, VA
2-Day Agile Requirements Course
June 23-24 Orlando, FL
2-Day Agile Requirements Course
July 10-11 Alpharetta, GA
3-Day PMI-Agile Certified Practitioner Course
July 21-23 Westminster, CO
3-Day PMI-Agile Certified Practitioner Course
August 11-13 Alpharetta, GA
3-Day PMI-Agile Certified Practitioner Course
August 18-20 Reston, VA
2-Day Agile Requirements Course
August 25-26 Orlando, FL

Events

Search