Bottom-Up Implementation & Top-Down Intent
Last Updated on Monday, 22 July 2013 10:02 Written by Andrew Fuqua Tuesday, 23 July 2013 07:15
A good strategy that I have used for dealing with complex agile transformations in large enterprises has two parts: bottom-up implementation and top-down intent. As Mike puts it, this is “where leadership sets the direction and establishes constraints, but with teams that are empowered to operate within those constraints.”
Bottom up implementation means helping teams be as successful as they can within their constraints. It means getting them mature enough to report out significant performance information like velocity, story ratios, resource shortages, quality and blocking issues on a reliable cadence. It means gaining transparency about the challenges in an actionable way. Due to extreme constraints in many organizations, this isn’t easy. What’s constraining agile in your organization?
Bottom up means helping the teams factually communicate the impact of obstacles on team performance. I use assessments to identify and communicate the “non-agile” behaviors and practices that are reducing the potential performance of the teams. Because we know that Agile/Lean practices work, we know that the teams that assess higher will perform better against their business drivers and performance metrics. Have you identified the obstacles in your company?
This approach of team and organizational assessments and improvement road-mapping tied to team metrics is a very mature way to help sustain the changes and to highlight where my clients aren’t getting the success they want. All this information from the ground credibly expresses the impacts of the organizational and management obstacles that arise from management decisions. In many organizations, you can’t simply create change in the larger environment to make the team stuff easy without first producing the information needed to justify change to management. This brings us to…
Top down intent requires helping management understand how they can be successful with Agile teams. They often are not in a good position to be successful with agile, they are under tremendous duress, and they need to work through a ton of challenges. Sound familiar? But we can still make progress. This requires explaining at the upper management levels and in other parts of the organization why they need stable teams. It requires data to demonstrate the impact of the organizational design in order to support moving toward the recommended org design. Understand the system, how it creates value, and its constraints. Build Scrum teams around the constraints.
As part of top down intent, it’s important to build awareness of the capabilities required in the program office that will be necessary in order to maintain the changes after the external agile coaches leave. They need to hire people to sustain momentum with internal training and coaching. And they should do this early on so these new people can get up to speed, spending time with the external coaches.
So there you have it: one way of approaching complex agile transformations in the enterprise. There is more, so stay tuned.Learn More
Structure 1st: Why You Should Not Start With Practices
Last Updated on Monday, 24 June 2013 11:06 Written by Andrew Fuqua Tuesday, 25 June 2013 08:10
Starting your agile transformation with a focus on practices is not an entirely bad idea, but with the wrong culture and structure, agile practices will be superficial. People will go through the motions. People will do agile things like have standups, demos, and planning meetings. You’ll have stories. It will look agile on the surface. But that’s all it will be — looks. There will be no substantive change, no stable teams, no control over Work-In-Process, no empowerment, and no predictability. You’ll have shallow collaboration, fault-finding and blame, and an unstable velocity. You’ll have no real support for agile or for improvement. You’ll get limited value out of your agile adoption efforts.
This isn’t the 1st time I’ve written negatively about mechanical agile and about how the agile values and culture are more important than the practices. While that is what I know to be true, there is more to the story.
So if starting with practices isn’t the best, where should we start? It’s not wise to start with culture either. Why not? CSM courses talk about practices and agile culture but when people go back to work they hit a structure that doesn’t support it, or they hit a command and control environment that doesn’t allow it. Attempts to change their culture are met with the realities of their organizational structure. Their structure is built around a different set of cultural expectations. The existing structure reinforces the old culture. Changing culture is hard, which is why many organizations start an agile transformation with practices.
Fortunately, deciding between culture and practices as the starting point is a false dichotomy. The place to start is with the structure.
Starting change with structure creates space and safety for practices to be put in place. At this point, we still can’t tackle culture head-on, and the practices will still be superficial at the start, but now there is support for the practices. You’ll have a shot at stable teams, at self-organization within the team, and enough empowerment for making reasonable commitments, leading to predictability. In this way, you can act your way into a new culture. Yes, I’m saying a new culture will emerge, but at this point, some intentional attention to shaping the culture is wise.
When I say structure, I have a few ideas in mind. The first is choosing between feature teams, component teams, services teams, or a mix. There is a great discussion on this topic on the LeadingAgile blog. Feature teams are great when you can have them, but an organization of size and complexity at some scale needs services or component teams added to the mix. Often, large organizations are already structured around component teams. We have to consider whether that is the best structure for their agile implementation.
Another idea I have in mind is just the stability of the team and whether it’s really a team, as opposed to a workgroup or project-group. For agile to work, we must have stable teams. Teams don’t work if management is often moving people around or if people are on multiple “teams”. Teams need to bond, to learn how to work together. Colocation is a huge help. Cross-functional is assumed.
Structure is among the most important concepts to nail for anyone scaling agile. At LeadingAgile we’ve been developing shared understanding on our approach. During this time, I’ve come to appreciate how much you can achieve with structure, along with practices, to create a team-based iterative and incremental delivery setup that is a precursor to agile. Once that is in place and we have some personal safety and delivery capability, some of the other things can begin to emerge, toward an agile culture. At a high level, that is our strategy for how to walk through the structure–practices–culture loop.Learn More
In organizational change, culture comes last
Last Updated on Tuesday, 2 April 2013 07:25 Written by Jesse Fewell Friday, 22 February 2013 12:00
Here at LeadingAgile, we have a specific cycle for achieving organizational transformation. In short, to make real substantive change, you need to attack the following dimensions
- Organizational Structure:
- Processes, Practices, Policies
- Cultural Beliefs
…in exactly that order. That’s right, when you go to change an organization for the better, you need to do the culture part last.
“But wait, Jesse. Isn’t culture the most important ingredient of an organization? What about the phrase ‘Culture eats strategy for breafast’? Why not do the most important thing first?”
I’ve been coaching this to my clients for a while, but in the past few months it has become painfully evident to me that Rule Number Zero for “going agile” is to have stable team rosters. One of my clients has the habit of shuffling people from one project to another, with no notice. When I started talking to them about the mechanics of user stories or other such details, they simply couldn’t care less; they were overwhelmed and tired from getting yanked around. A different client actually KNEW they had to re-organize their teams to be more focused. But while senior management was busy socializing the new org chart for 4 months, the teams were thrashing, fully convinced that management didn’t have the fortitude to effect any kind of real change.
Some of my colleagues think that if you go straight to modifying the cultural mindset of the leadership team, you will get the momentum you need for lasting results. But the problem is you can’t get there from here. There is a known, methodlical process for changing people’s mental models. Specifically, consider that the same process applies for people struggling with personal dysfunction. Think about it. To achieve behavior modification,
- First, get out of the environment that enables the dysfunction, and get into a support structure
- Then, leverage that support structure to work through a 12-step program
- ONLY THEN, can you introspect and self-actualize yourself as the new person
Granted, it is an iterative cycle:
- Change one small environmental thing =>
- to create the space to change one small process =>
- which slightly shifts my confidence based on a known track record =>
- which motivates me to make another environmental tweak…
But the point here, is that the iterative cycle of behavior modification is that you can NOT change a belief system, until you first have some positive behavioral evidence, which only happens after you create a safe and stable operational environment.
What about you? Have you seen the latest mission statement, management fad, or feel good effort yield zero results in your day to day work?
Last Updated on Monday, 26 November 2012 07:49 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.Learn More
Beware of Common Sense
Last Updated on Monday, 19 November 2012 11:15 Written by Dean Stevens Thursday, 20 September 2012 08:00
When working with organizations in Agile transformations, I help them to do what makes sense. I encourage them to challenge me when they think I am suggesting something that does not make sense.
Do what makes Lean-Agile Sense
Here is the rub. When I explain what makes sense, I talk in terms of “principle based” sense. Agile Sense provides a set of values and principles to guide our decisions and actions to achieve an Agile mindset. Lean Sense explains some of the process science of flow embodied in Agile methods. It is surprisingly easy to loose sight of this at key moments. Education and training on the Agile Manifesto and Lean Thinking is critical early on.The rest of the coaching engagement is a pragmatic application of Agile and Lean sense in decision making. This is a great way to help them learn and for me to make sure they understand.
Beware of Common Sense (and Be Aware of Culture)
Organizations and individuals will face challenges in an Agile transformation. They will struggle with decision making to solve these challenges. This struggle is good. But if they are not intentionally doing what makes Lean-Agile sense, they will inspect and adapt away from Agile. Teams tend to revert to solutions based on common sense in the organization. Common sense is the knowledge and experience most people have. It is based on what has “worked” in the past. It is remarkable how fast a group can slide back to what they did before based on common sense.
A Bias for Less
Common sense tells us we need more of the things on the right of the Manifesto. More documentation and following the plan. These are comfortable and safe. Agile sense encourages a bias for less on the right. Encourage a bias for less of the items on the right instead of more.
For example, as teams struggle understanding what to build, some managers want to solve the problem with more documentation. Agile Sense encourages progress towards working software. Start with getting getting better at collaboration to demonstrate software sooner.
Common sense tells us big batches lead to efficiencies of scale. Lean sense explains big batches lead to expensive delayed feedback and wasted effort that out weigh these efficiencies. Without fast feedback, we do not learn as we discover the solution.
Stay engaged in retrospectives and decision making. Look for common sense solutions.
- A bias for more of the things on the right side of the Manifesto
- A bias for bigger batches
- A bias for delay in feedback
Change the conversation with Agile and Lean sense. Promote a bias for less, not more.Learn More