12 Key Agile Thinking Tools

Well, turns out that today is toast too.  We are still iced-in with no real hope of things melting until the weekend. At this point I am hoping for a mid-week heat wave.  Probably not going to happen.  This is a totally odd feeling… being trapped in the house, unable to get out… unable to go visit my clients. My kids are out of school and loving it… and it is nice to know I can get some writing done, but seriously… it’s time to get warm. Okay enough griping, let’s get down to business.

This post I want to talk about the thinking tools you’ll need to craft a safe and pragmatic Agile adoption program. We’ll take into consideration our key success criteria, the underlying assumptions Agile makes about our organization, and the stuff we know is going to try and stand in our way as we go and begin to formulate a strategy for introducing change. In the absence of a pre-defined formula… in the absence of one-true-way to make this happen…we need a framework and some decision criteria, principles maybe… some thinking tools if you will, that help guide us down our decision making process.

Here’s my starting place, let me know what you think…

1. Top-down intent, bottom-up implementation

The verdict is in… team-based agile methods work. If we decide the start an Agile pilot, it’s mainly intended to see if it will work in our organization. It’s intended to gather some lessons learned so we can try to replicate its success throughout the organization. Our challenge is that randomly picking a product (or project) to pilot can initially disrupt the organization’s ability to create value.  The pilot risks creating a local optimization within the larger organization, often at the expense of the rest of the company.  Our goal is to have some knowledge of where we are headed before we get started. Armed with that knowledge, we can choose a pilot that will better position us for success long term. Building bottom up is okay, even desirable, as long as we know what we’re building towards.

2. Systems thinking

Agile teams live in a larger ecosystem of folks, folks that may or may not have any idea what agile is, and no desire to even consider it as part of their overall delivery process. A successful agile pilot is no indicator that the organization will necessarily achieve greater business agility. To be successful, our pilot, and ultimately our entire transformation program, has to be done with an awareness of the greater whole. We need a plan for how we are going to change, how we are going to manage the flow of value during the transition, and how we are going to deliver as a whole organization when we finally get there.  That means we have to create interfaces with the legacy organization that helps everything work together.

3. Value streams

Agile tends to make the assumption that the entire value stream is encapsulated within the team. This assumption is represented through language like ‘the team is given everything it needs to deliver an increment of value’. If this is indeed the case, basic agile methods tend to work fine. When the value stream is larger than the single team… when it involves other development teams, or a separate quality organization, or even sales, marketing, and support; we need to account for that in our understanding of what it means to deliver value. Taking the entire value stream into consideration is critical to realizing the value of your agile transformation.  Without considering the entire value stream, we are back to our local optimization problem from the Systems Thinking section.

4. Pragmatism

All the techniques you read about in books and blogs, this one included, have been tried by someone, somewhere and found to work. There was some context where that technique was exactly the right thing to do and delivered exactly the desired outcome. That doesn’t necessarily mean the same technique will be the right thing for you to apply in your particular context. Being pragmatic is about understanding how and why things work, applying the methods that have the greatest chance of being succesful, and evaluating the value of the approach based on the business outcomes you are going for. We don’t have any time or patience for dogmatic arguments. Let’s do what works and move on.

5. Teams, Teams, Teams

Teams are the building blocks of agile organizations. This might be my one unbreakable rule of agile. There are tons of things we can do to be successful building software, but if we are going for an agile approach, we are seeking to create an environment where teams of people are accountable for delivery. Our primary disposition designing the agile enterprise has to be toward creating teams of people that stay together over time. The team, not the individual, becomes the fundamental unit of value creation. If we can’t do this, nothing much else is going to hang together very well. The practices fail, the metrics don’t work, and the framework basically falls apart.

6. Limit work in process

Most organizations I work with, start off with no way of reliably predicting when they are going to get done. Work goes into the queue and never seems to come out. The near universal response to this problem seems to be putting more work into the queue. The thinking goes that if we put more in, the pressure will force some of the other things out. The reality is that putting more stuff into the queue causes thrashing that only serves to make the problem worse. We need a system in place that limits the number of things we focus on… at the team level, the program level, and at the portfolio level. Once we have a stable system we can begin to talk about how we might make it go faster.

7. Cooperation with governance

Ignoring governance isn’t a great long term strategy. The controls that we have in place were put there for a reason, to solve some sort of problem. Understanding what the organization is trying to accomplish with it’s existing policies is key. Sometimes if we can figure out the underlying problem, we can devise solutions that get everyone what they need. The thing to know here is that governance is in place, it’s not going away, it’s probably incongruent with your new practices, so you better have a disposition and a plan for dealing with it. Governance can kill an agile transformation initiative unless dealt with proactively.

8. Constraints and feedback

It is impractical to ask your teams to be involved making every decision and estimating every piece of work. Higher levels within the organization establish constraints, be it architecture and vision or budget, while the lower levels of the organization operate within those constraints until they no longer can, and then give feedback up the chain. It’s really about the flow of information within the enterprise. The teams don’t have the autonomy to build anything they want, but the business can’t mandate unrealistic architectures and project deadlines. There has to be cooperation, coordination, and feedback loops designed up and down the entire organization so we can all converge on our business goals.

9. Inclusive toward management

I don’t know about you guys but I get kinda tired of the whole chicken and pigs metaphor. I can’t tell you how many managers I’ve worked with that come out of a 2-day CSM course totally lost… disenfranchised from the organization… and frankly, at great personal risk. How do we get people to buy into a methodology that totally excludes them from the process and devalues everything they have worked for. My belief is that management has a role, one that is more than mreley helping people get into training courses and doing their performance reviews. Managers set the team up for success, get them the tools they need, they can help solve problems, and teach people how to solve problems. A good agile-manager manages the environment around the team and gets the organization ready to receive their output. We’ll figure out exactly what their role is on a case by case basis, but for now… we need to have some idea what we are going to do with these valuable and highly paid folks.

10. Conversation, conversation, conversation

Almost everything we do introducing agile is to increase the level of communication in the organization. Agile doesn’t solve any of your problems, it only serves to show you your problems… it doesn’t let anything hide. When some problem arises, agile creates an opportunity to have a conversation about how to solve it. Don’t know what to build… let’s talk. Can’t get the code working… let’s figure out why. Some guy on the team not pulling his weigh… let’s talk about out what we can do about it. If you are thinking about adopting agile, get ready to surface a ton of issues, and be prepared to have a ton of conversations.

11. Change management

Adopting agile at scale is a pretty big deal. Sure, you can change the org chart overnight, you can send people to training in the course of a week. It’s much harder to change people’s hearts and minds, and to get them to internalize this new way of working. So much of agile is counter-intuitive to how many people are wired, and really, really different from how they are used to working. You’ve got to start slow, incrementally introduce change, allow people to get their heads around this new way of doing things, let them learn new skills in a safe environment, and then build on that incremental success. Sure, we want the benefits fast, but to quote Stephen Covey… with people fast is slow and slow is fast.

12. Organizational Learning

I’m not really thinking about Organizational Learning in the sense of Peter Senge’s Learning Organizations (although we’ll see a little about that in my next post), I’m thinking mostly about the results of our change management approach.  How do we, as an organization, figure out how to do this… how do we figure out what principles and practices are going to work with our people, with our constraints, and with our customers.  Sometimes you’ll hear people talk about managing your transformation just like you manage an agile project.  I agree, but the discussions tend to center around keeping a backlog, doing iterations, and identifying and removing impediments.  The aspects of leading change that I want to capture here aren’t procedural.  As an organization, we are going to learn through doing.  We need to build in the ability to inspect and adapt and change course as we go.  The outcome will be emergent, we need to understand and plan for that emergence.

Next post, I want to talk about the components or knowledge areas I think you need to apply to successfully lead a transformation.  I think that much of the things we do as coaches emerge based on our tacit knowledge of people and systems and methodology.  I want to get explicit for a bit and reference some the bodies of knowledge I think are going to be important to apply as we go.  Stay tuned and don’t blink… remember, it’s a snow day and I’m home writing ;-)