12 Key Agile Thinking Tools

This content is syndicated from LeadingAgile by Mike Cottmeyer. To view the original post in full, click here.

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 ;-)

Leave a Reply

Your email address will not be published. Required fields are marked *

2 × 2 =

There are 101 ways to do anything.
To find the best way, sometimes you need expert help

What People Say

“Kelly revolutionised the way our digital department operated. A true advocate of agile principles, he quickly improved internal communication within our teams and our internal clients by aligning our business and creating a much enhanced sense of transparency in the decisions the business was making. Kelly also introduced a higher sense of empowerment to the development teams...”


“Kelly’s a leading program director with the ability to take charge from day one and keep strong momentum at both a program and project level driving prioritisation, resourcing and budgeting agendas. Kelly operates with an easy-going style and possesses a strong facilitation skill set. From my 5 months experience working with Kelly, I would recommend Kelly to program manage large scale, complex, cross company change programs both from a business and IT perspective.”


“I worked with Kelly on many projects at IPC and I was always impressed with his approach to all of them, always ensuring the most commercially viable route was taken. He is great at managing relationships and it was always a pleasure working with him.”


“I worked with Kelly whilst at Thoughtworks and found him to be a most inspiring individual, his common-sense approach coupled with a deep understanding of Agile and business makes him an invaluable asset to any organisation. I can't recommend Kelly enough.”


“Kelly is an extremely talented and visionary leader. As such he manages to inspire all around him to achieve their best. He is passionate about agile and has a wealth of experience to bring to bear in this area. If you're 'lucky' he might even tell you all about his agile blog. Above all this, Kelly is great fun to work with. He is always relaxed and never gets stressed - and trust me, he had plenty of opportunity here! If you get the chance to work with Kelly, don't pass it up.”


“Kelly came to the department and has really made a huge impact on how the department communicates, collaborates and generally gets things done. We were already developing in an agile way, but Kelly has brought us even more into alignment with agile and scrum best practices, being eager to share information and willing to work with us to change our processes rather than dictate how things must be done. He is highly knowledgable about agile development (as his active blog proves) but his blog won't show what a friendly and knowledgeable guy he is. I highly recommend Kelly to anyone looking for a CTO or a seminar on agile/scrum practices - you won't be disappointed!”


“Kelly was a brilliant CTO and a great support to me in the time we worked together. I owe Kelly a great deal in terms of direction and how to get things done under sometimes difficult circumstances. Thanks Kelly.”


“Kelly and I worked together on a very large project trying to secure a new Insurer client. Kelly had fantastic commercial awareness as well as his technical expertise. Without him I would never had secured this client so I owe a lot to him. He is also a really great guy!”


“Kelly is an Agile heavy-weight. He came in to assess my multi-million $ Agile development program which wasn’t delivering the right throughput. He interviewed most of the team and made some key recommendations that, when implemented, showed immediate results. I couldn’t ask for more than that except he’s a really nice guy as well.”


“Kelly was a great colleague to work with - highly competent, trustworthy and generally a nice bloke.”


“Kelly was engaged as a Program Director on a complex business and technology transformation program for Suncorp Commercial Insurance. Kelly drew on his key capabilities and depth of experience to bring together disparate parties in a harmonised way, ensuring the initiate and concept phases of the program were understood and well formulated. Excellent outcome in a very short time frame. ”



To explore how we can help you, please get in touch