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
Getting Started With Agile… One of Five
Last Updated on Thursday, 15 November 2012 01:03 Written by Mike Cottmeyer Saturday, 27 February 2010 07:12
Yesterday, I did my first live presentation of a new talk I’m calling “Getting Started with Agile”. A better title for the talk might have been “How to Select an Agile Pilot Team in a Large Company, Get Them What They Need to be Successful, and Help Them Build Trust With the Rest of the Organization”, but that just didn’t seem to flow quite as well Now that it has been vetted live, and I’m pretty sure it solves a real problem… I want to spend some time talking through the content with you guys here… and give you a chance to weigh in.
If you are new to this blog, and for some reason haven’t been able to get through my earlier 270 or so posts… you might not be as familiar with my background. I’ve got a degree in Computer Science from the University of Florida but somehow never managed to become a professional programmer. I spent the first ten years of my career as a data center guy working with network and server hardware. The second ten years of my career I’ve been, in some form or fashion, a project manager. Most everything I have ever worked on has been big and uncertain and with teams of people that were figuring out stuff as we went.
We were doing iteration planning, daily stand-ups, story points, and retrospectives back in 2001 before I ever knew there was a movement forming called Agile. These things were the stuff I just figured out to cope managing projects in the face of brutal uncertainty. I have a huge aversion to wasting time and doing stuff that doesn’t make sense, and I sure as hell wasn’t going to spend my time doing Gantt charts that everyone knew were fiction. I opted to lead my projects rather than spend all my time keeping project plans up to date. My approach wasn’t always popular, but we delivered some really kick-ass projects.
Because so much of my career has been spent challenging conventional thinking, I’ve developed a passion for helping folks understand how to use non-traditional ways of managing work. I want to help people to understand context, and apply what they know in ways that make sense. That is the backdrop for most of my writing… let’s take what we know… let’s understand where we are… let’s figure out what we need to deliver… and let’s make good decisions about how to most effectively manage the work. We are not living in a one size fits all world. We can’t take a one size fits all approach to solving problems.
So, that is kinda where this talk started. When VersionOne asked me to kick-off their webinar series, I thought I would use one of my existing talks on scaling agile… maybe something on enterprise value, or the role of the product owner. They actually wanted something that was more introductory… something for people just getting started. There is a ton of stuff out there that explains the basics of Scrum and XP… and I knew I didn’t want to do an intro to Scrum talk. The other thing was, that while most people seem interested in Agile… they have a hard time going back and applying these concepts in more traditional organizations.
This talk was designed from the ground up as less of an ‘intro to agile’ talk… and more of a ‘okay you are sold on agile… now let’s really figure out how to get started’ talk. Getting started doesn’t start with your first release planning meeting… it starts with spinning up your first team. It starts with choosing an agile pilot team and putting them in the best possible position to be successful. It’s about understanding how to get them everything they need to deliver working software. How to get them tied to a real enterprise level problem, something the business really needs to have solved, and help them knock it out of the park? It’s about helping the team be successful… but also making sure the larger organization is successful too.
This talk is broken down into four main sections:
- Understanding what your organization values and spinning up an agile pilot team to unlock that value
- Understanding the anatomy of an agile team and getting them what they need to be successful
- Establishing a delivery cadence and building trust and safety with everyone else in the organization
- Understanding common challenges and facilitation tools for taking the first step toward agility
Over my next few posts, we’ll break these four sections down and talk through each in more detail. Looking forward to your comments.Learn More
How to Get Started With Agile?
Last Updated on Thursday, 15 November 2012 01:03 Written by Mike Cottmeyer Wednesday, 24 February 2010 10:18
I kicked off the 2010 VersionOne webinar series today with a talk called ‘How to Get Started with Agile’. The idea was to do an ‘intro to agile’ talk focused on how to select a good pilot project, how to get the team started on the right foot, and how to bridge the team to the rest of the organization. I think it’s time we start giving teams some tips for surviving and thriving in non-agile organizations. Take a look at the deck and let me know what you think!Learn More