Path To Agility: Adoption Patterns To Overcome Pitfalls – Keep Austin Agile 2016 [Video]

Where are you on the Path to Agility?

In a presentation for Keep Austin Agile 2016, David Hawks explained each phase of the Path to Agility journey including examples of typical challenges encountered along the way. Apologies for the abrupt pause in the middle of the video…a fire drill caused us to evacuate. Thankfully, the drill was just that. Watch the full video or read the transcript below.

So what we’re going to talk about today, are what we have seen in terms of a pattern of adopting Agile. Because what I realized early on is that you can’t go from 0 to 100 miles an hour overnight. Even though when I first started coaching I came into an organization and I assess, like “oh yeah you guys haven’t really doing Agile, here’s where I think you can get” and I tried to get them there immediately.  I realized I caused a lot of tension and friction as I tried to get them to 100 miles an hour.

Alright so, at this point almost every organization I talk to is saying “we’re doing Agile.” Everyone is saying “we’ve adopted Agile,” “We’re doing Agile,” “We’re an Agile company.” Nobody is going around town saying, “We’re waterfall. You should come see what we’re doing- we’ve mastered waterfall.” Right? Everybody is saying “we are trying to get great at Agile.”

So what I want you to do, the first poll, is I want you to rate the questions up there at the top. How good is your organization at Agile? So you’re going to give a 0, that’s like we are not really Agile- maybe its like you call things Agile but you’re still doing waterfall- We call that scrummerfall. So, let’s start revealing what we’re coming up with here. Okay so, this is a little bit interesting, we’ve got 4% awesome. Alright, we’ve got- everybody’s trying it, at least, but we have more in this kind of mediocre range.

That’s not uncommon, I mean at this point what I am seeing is that there is more kind of bad, or mediocre Agile than there is great Agile because it’s hard. And I see most companies are underestimating what’s involved in making this change.They just look at it as oh yeah “let’s just change the process. Just tell us how to work now. Let’s just send everybody–let’s not even do a day of training, let’s just do a lunch and learn. You can tell us how to work, and we can just do that.”

Because the process we are switching from was a prescriptive process, right? It had rules, recipe, follow this recipe. We are switching from a defined process control to empirical process control that doesn’t have a perfect recipe- and that doesn’t compute in our leaderships minds.

But what we now know, is that it is much more of a cultural and mindset change, and that’s hard. So how do we get from where we are- 0, or 20, or 40 miles an hour Agile to 100 miles an hour Agile? I want you to talk with your group there, for just a minute or two. Why do you think there is more bad Agile than good Agile? Ready? Go.

Let’s build on what we’re talking about here. Again, follow along with this sheet. There are two sides: one has the Satir model, one has this worksheet. You’re going to be following along there, we’ll cover those things.

Path to Agility Phase: Align

The first issue that we see is we are not aligned on mission. Why are we doing this? Why are we going to Agile? What problems are we trying to fix? What is the outcome we are trying to achieve? What’s the business goal? How will we know that we were successful? And so If we think about this, what I want to know is in your company, is there a clear goal on why you are doing Agile that everyone understands? So, A is No. Text that. Or maybe one of these, yes we have a clear goal- our goal is to be Agile. It’s been dictated by our CIO – We will be Agile! Or, is it that you want faster productivity predictability. Not what you want, but what has been said from your leadership, the reason why you are implementing Agile. So let’s look at what we’ve got coming up here.

We are just doing it because everybody else is. Or we got 20% who are saying the goal has been to be Agile.

So how is your company going to measure that you are Agile enough? How will you know you’re done? You won’t. There will just be a point where your CIO or your VP of engineering get so tired of “going Agile” that they declare, “We’re Agile! We’re done. Let’s go onto something else.” We at least have, about the other 50%, who are focused on some improvement- productivity, faster, predictable. Those are usually the most common things that we see.

So here’s the thing- when we’re going to make a change, we have something called the Satir model of change. And we start off with a Status Quo, how we have been working in the past, how we’ve always worked. Now when we make a change, do we get better or worse?

We get worse, we enter a phase called chaos and resistance. This is a natural state because we changed the rules. Everybody knew how to play by the rules here, all of a sudden we changed the rules and people freak out. It’s like I knew how to be successful with the rules of the old game, I don’t know how to be successful with the new rules. Some of you are probably at this conference because you are trying to figure out what these new rules are. Everybody has told you that you are going to be Agile, and you’re in chaos and resistance right now. So you’re kind of freaking out, that’s natural.

What we need to do is support our organization as they are going through this phase and help make sure we are providing the support needed to hopefully get to a state of integration and practice. This is where we start getting better at it, start figuring out these new rules, start practicing these rules, and start mastering these new rules. Hopefully, then we get a new status quo which is better than what we were doing before. That’s our goal.

So if we are going to go through this big change, don’t we need to be aligned around a common mission. So we are all saying, “yes this is worth while” going through all this pain is worth it. We need to make sure that in our organizations we have a clear mission, a clear vision of why we are doing this change to Agile. Why we are trying to get better in our processes and our practices because we are trying to achieve something, because anytime we introduce a change, Agile or anything else, we are going to get worse first. So we want to make sure everyone is bought in, aligned and willing to go through this journey that is going to be a pain in the butt.

We also want to make sure you are thinking about this as an organizational transformation. This doesn’t just train people on a process. Here is Kotter’s change model. There are some key things here at the bottom.

Create a sense of urgency- why do we want to make the change, that’s what we were just talking about. Form a powerful coalition, this could be like a leadership team, who is going to drive this change, shape the vision, respond to the organizational impediments with a sense of urgency, and communicate this vision. Then we want to start empowering action and get quick wins. That might start off with, let’s do a pilot with a small team and get success.

The other thing that we do is build a backlog of all the things we need to do. We need to prioritize that because we can’t change everything overnight, just like anything else we do in Agile. We need a leadership team or transition team who is working this backlog. We might even form sub-teams, as we say okay, we got to go figure out devops. Who are the people that are going to figure out devops?

Right, so we might need to form these groups but we need to work things and make everything that we are doing is visible. So when a team escalates an issue, it goes onto a board. The leadership team shows how they are prioritizing and they are responding and reacting to these changes and showing their commitment to the organization by resolving the issues. The worst thing to happen is we say, hey team you need to be Agile, we are going to send you to training because you need to change. And then you start escalating issues that are organizational issues and management doesn’t do anything about it. So do you guys believe that I actually want us to be Agile if I am not going to make any changes myself? If I am not going to practice Agile myself?

******* Fire Drill *******

Picking up where we left off. We just finished talking about the transition team and forming this in Align. This Align stage needs to be done before we introduce the change. What happens in most organizations is they say we need training. They train everybody and then everybody starts in that chaos and resistance and we are not aligned. I was talking to somebody on the way down the stairs and they said, “how do I combat the resistance?” Well, you combat the resistance by making sure everybody bought into the goal.

I heard about a product management group that is resisting the change. Are they bought into the goal? Are they bought into the mission? It doesn’t sound like they are. And it doesn’t sound like they are being held accountable to change the leadership team around this mission. So nobody horizontally is going to be able to convince them to change, if their boss says “yeah, don’t change.” So we have got to get alignment at the top.

A lot of times the symptoms are things like you’ve got a lot of chaos and resistance, you are implementing Agile, or implementing SAFe but you are not actually being Agile. And you don’t have those missions, and the solutions are things that we talked about – sense of urgency, creating a transformation backlog, creating a team. So what I want you to do is on your sheet, under “align” it says “your rating.” What I want you to do is, how do you rate your organization’s level of Align? 1 being low, 5 being we are way aligned. Alright, so this is higher than I would expect. There is some alignment, maybe that means there is some alignment within one part of the organization but not other parts of the organization. Or we have no alignment, so I would expect lots of resistance in these organizations over here. And very few over here that have alignment around this mission.

So these are in a sequence. We are going to work on a lot of this at once, but you have to make sure that you got Align right before you are going to be able to make a lot of progress on the others. So if you have a low rating, then I would encourage your organization to focus on getting better alignment?

Path to Agility Phase: Learn

Pitfall #2 – team and leadership are not equipped with the knowledge. So in Agile, what percentage of your team has been trained? In Agile, Scrum, Kanban, whatever you are implementing, what percentage of your team have done something to get aligned on the knowledge? Book Club, whatever it was. So we’ve got 60 responses in. A few, none, maybe half, most everyone. So this is really good, everyone has gone through some amount of training, that’s good. We definitely want to see that because as we are switching from waterfall to Agile- we talk a lot in Agile about self-organizing teams, which means we are arming the team to solve their problems and to improve their process. If our team isn’t trained with the knowledge, how are they armed to solve their problems?

If we say, we want you guys to own your process, you’re going to be doing retrospectives. You are going to figure out how to improve, figure out how to get good at this stuff, then you all need to be armed with the knowledge and talking the same language. So even if I had a team, I come into this organization – you did Agile at another company, you did Agile at a previous company, etc. Is all Agile the same? No.

Like everyone in this room, you are probably learning a lot today from each other, from the different experiences you have. The reality is, not all your Agile is the same. I’ve had companies who say “Scrum is garbage.” Then you dig into it and what they “implemented” as Scrum is nothing like I would ever call Scrum. But that is what they know. In their head, that is the definition of Scrum because some ScrumMaster went to certification class. Are they an expert? Can they teach it? No.

We want to make sure everybody is armed. The leadership needs to be armed because they’ve got to change how they lead. They can’t just be command and control. I see this with every organization, “yeah you guys be Agile, but I want to know what’s the date and what’s going to be in it.” That’s not going to work.

We want to make sure our leadership is understanding how their role changes and how their way of thinking about these problems changes. How we plan changes, how we prioritize changes. We got to work on those things. Learning also doesn’t just stop in a classroom. We get knowledge in a classroom; we learn by doing; we learn by practice.

One model is the ShuHaRI model that says at first we have got to just do the rules. We just got to follow, do the same things over and over again. We need the repetition. Think about if you have a kid or when you had to learn to ride a bike. You need to figure out that my feet go on the pedals then how to steer, how to balance. I’ve got to figure out all these things. Then I just keep kind of doing them, get the muscle memory, then I can get good at them.

Tuckman’s model of forming, storming, norming and performing says that every team you build goes through these stages, of forming and figuring out how to start working together, get connected with each other. Storming is where there starts getting some tension. We have to get through that, to get to norming. We’ve got to invest in that, that takes time. That’s part of learning, that’s part of forming these teams.

Team maturity–you start off with a group of people who are cooperating with each other. I’ve got a task, you’ve got a task , you do your thing, I’ll do my thing, we’ll achieve the goal. That’s not really what we mean by self-organizing teams. Self-organizing teams are we all have a team goal, we are all pulling for each other, we are all working together, we are all swarming on problems. That’s part of team maturity and that’s something that needs to be learned. During this chaos and resistance is when we are learning these new rules. We are in the Shu stage. We are in the forming and storming, and trying to get to norming. We are in the stage of “well we have formed these set of people but are we truly a self-organizing team?” We’ve got to work through those things.

When we look at stage 2 we see pains are, “we’re not talking the same language as what Agile is.” We need some better knowledge. We need to align on terminology. We need to align that Scrum, or Kanban, or a Mix, or whatever is the right answer for us. If you look on the solutions side, we need not only training and education but we also need to provide slack to learn.

Every time I go into an organization they say, “we need to implement Agile, but we can’t go any slower.” Have you heard of the Satir model? Your team is going to have to go through that – now how long they go through chaos and resistance, how long they go down that’s really the question. How quickly can we get through that? The more support you give your team, the faster they will recover and start producing at a higher rate, but you’ve got to go slow to go fast.

A lot of leaders aren’t ready for that. But that means they are not ready to change because we have got to go through those things in order to learn. So what I want you to do on your sheet is write down your rating of 1,2,3,4,or 5 on learn. And then once this loads up, go ahead and send your answer in. How are you doing on learn? How well is your team educated around the problem? How well have they given time to learn these new practices? It’s organization wide, so team and leadership, it applies across both. We’re balancing out here, so 2’s and 3’s- we’ve got some room for improvement. I

In the bottom section, I want you to follow along, either you are circling a potential solution or writing in something that you could do/implement in order for your organization to improve- get from 3 to 4, get from 2 to 3, get from 1 to 2. Where do you think your organization stuck, and what could they do to move forward?

Path to Agility Phase: Predict

Pitfall number 3- not getting to done. The most important thing for organizations to focus on is what is our goal at the end of a sprint. We are supposed to have something at the end of a sprint, does anybody know what that is? Potentially shippable product. That is really hard to achieve. However, it is the most important thing. If your team only focuses on one thing, focus them on trying to get potentially shippable, getting to done.

What percentage of your sprints get to 100% of the plan done-done. So when they go to sprint planning, they leave sprint planning with a goal, with a plan, we are going to deliver these stories, this functionality. How often to they deliver all of that scope to a potentially shippable product increment by the end of their sprint? Two weeks or whatever that is. We’ve got 6 teams out of 59 who are never – 10% never make their goal. In zero always, that’s kind of scary. The goal to me is that you should be getting 9 out of 10 of your sprints 100% done.

Let’s look at where this part sometimes goes wrong. A lot of times we focus on individual efficiency as opposed to the effectiveness of our team. Let’s say we have a two-week sprint, with four user stories, four developers, two QA. What is the most efficient way for me to assign this work out? Put one developer per story, Dev1, Dev2, Dev3. The developers in the room, I was a developer so don’t take offense. I’m talking about myself here, not you. Developers tend to like to work on their own a lot of times, they don’t really like people. They would love nothing more than just put my headphones on. I don’t have to interrupt, I don’t have to coordinate, I can build it my way. I can write the code my way, and I can just go for 8 days and be focused. And no – don’t interrupt me, I don’t want any meetings. Just for 8 days, I’ll go get my thing done, no interruptions.

However, our goal is not about efficiency. I would argue that learning, from a bigger viewpoint, is more about our product and validation. This is way more important than individual efficiency. So when we do this, and we have QA assigned out this way, what does it look like to you? What kind of plan? A waterfall plan. We should not have Scrum turned into mini-waterfalls.

This is very common. Waterfall has a lot of risks inherent at the end of the cycle. So you, if you are working your sprint like this, have a lot of risk at the end. Which means you have a lot of risk that things will carry over into the next sprint because you’re only going to find the bugs in the last couple of days, and you’re going to run out of time. You’re trying integrate everything at the end, you’re trying to test everything at the end. So how should we work?

We want to do some new skills for our teams. We want to teach them how to break work down, how to break stories down, how to break tasks down. We want to teach them how to swarm, so multiple people are working on something together. We want cross-functional teams so we can get potentially shippable at the end of two weeks. And we want to make sure we’re doing cross training. T-shaped people-people have a depth of skill but also have a breadth of skill, so we have the flexibility of people being able to help out.

We have to invest in these new things, these new skills. Your teams will suck at these skills at first, and they won’t think it’s possible. They will say we can’t break it down. It doesn’t fit in two weeks. It’s bigger than that. I’ve been doing this a long time, I have yet to see the problem that can’t be broken down into two weeks. There’s something you’re going to do differently today, than tomorrow, then the next day, then the next day. And that’s what sprint planning is for, is for us to figure that out. Right? And if we do this, then we have something to review every couple of days. We have a story to deliver, that is potentially shippable, every couple of days. That’s what our goal is. So that by the end of the sprint, we have only two parts of the story that actually will be at risk if we didn’t get it all the way done-done. We want to work in this form,  which means small stories, small tasks, multiple people working on things together which is gonna write higher quality code, better cross-training, more flexibility, lots of other good benefits.

The other issue is that we start sprints without clarity. We start a lot of sprints without understanding what it is that we’re about to do. So at the end of the sprint – I know some of the language has been softened in Scrum, we are creating a goal, or we are creating a sprint commitment. At the end of the sprint, we are creating a plan, of here’s what we think we are going to be able to get done.

But if the team doesn’t really understand the scope of work that they’re committing to, do you really have confidence in that plan? No. That means you’re probably going to miss a lot of your sprints, on your sprint goal. So we need to make sure we are engaging in things like backlog grooming prior to the sprint, with the whole team. So they can spin up and get an understanding by the time they get into sprint planning.

We want to make sure we’re having conversations with the team. You might even look at things like the definition of ready, so everybody is on the same page of what we need to have in place before we actually pull it into sprint planning. It needs to be small, it needs to have acceptance criteria, it needs to be sized, it needs to be that everybody on the team has had a conversation and asked questions about it. We don’t have any outside dependencies that would block us from being able to get it done, we have everybody that we need in order to get it done.

Those could be things in your definition of ready that says we as a group, including product owner, need to get the stories to that state, in order for us to pull it into our sprint. Because if we don’t, then we’ve got a lot of risk in our sprint. We are going to have a lot of surprises in our sprint, we are not going to be potentially shippable very frequently. So predict is all about getting good at getting shippable if you’re implementing Scrum. How many people in the room are implementing Scrum? Alright, so I’ll keep using that example.  

If we’re implementing Scrum, at the end of the two-week sprint, we need to get predictable. We need to know our velocity, we need to be done-done in the majority of our sprints. That’s what our goal is, that’s what our focus is. We need to change everything else in our process to get and accomplish that goal. That’s our number one goal because I believe that you cannot go faster until you get predictable.

If I have a team that’s not predictable and I ask them to go faster, they’re all over the place. How do we know that what they tried in their retrospective actually helped if they’re not predictable? So teams have to get predictable and then as we try things, we will see the improvement. We need to focus on getting predictable before we go faster. Even though most of the time and you guys voted on this, your number one goal of why you wanted to go Agile was to get faster. That’s great, but as you see on your sheet, Predict is before Accelerate. We need to figure out how to get predictable before we can go faster.

So we see pains. You have a lot of carrying over into the next sprint. Maybe dev and QA still throw it over the wall to QA, they throw it back, they’re blaming each other. You don’t know your velocity. If you don’t know your velocity, are you predictable? No, I mean if you’re doing Kanban and you have cycle time and throughput and other measures. There are other ways to measure besides velocity, but if you don’t have the measures, then you don’t have predictability.

In terms of solutions, first you’ve got to make all your work visible; you’ve got to be able to see the problem. You’ve got to be able to see the bottleneck in order to attack it. You’ve got to limit your work in process until you can get to done-done. If I have a team that plans 20 and gets 10 done, then plans 20 and gets 10 done. What’s their velocity? 10. How much should they plan next sprint? 10. And they’re like “but we can do 20” and you’re like “no you can’t.” Do 10, make it, get a win. Then figure out how to do 12, make it, get a win. Then figure out how to do 14, but you can’t do 20.

“But it‘s not efficient.” That’s not our goal. Our goal is not efficiency. Our goal is to actually deliver value and if we are not delivering value, it doesn’t matter how efficient we are. So what I want you to do is rate your organization’s level of Predict. Write that down on your sheet, send that into the poll. Alright so, not so good. We are definitely 50% at the lower end of the spectrum.

This is where we start seeing the challenges. Most organizations agree we all need training, so let’s go do Learn. But then we don’t actually do the things that we need to get good at it. We’re not giving our teams slack. We’re not actually attacking the problems. We are not holding our teams accountable to get done-done. We’re not making the organizational change to create cross-functional teams in order to get done-done. So we start seeing these issues, and that’s why we have a lower level of Predict, or Predictability in our organizations.

Quick discussion at your table: What needs to happen in your organization, or as you’ve seen, to be able to get to 9 out of 10 sprints or 100% done? Talk about that at your table, take 2 minutes for that. Again, follow along. We’re going to be collecting some of these answers at the end. Follow along and write in your sheet, is there something that you, or your table, came up with that would help improve Predict. How to get from 1 to 2? 2 to 3? 3 to 4? How do you move along that path and that journey?

Path to Agility Phase: Accelerate

The next thing I want to know is, think about when an idea comes into your company, for a new feature. How long does it take from the point that an idea is created, somebody looks at it, it goes through ideation, it gets to something that’s prioritized, we decide we are going to plan it so somebody does some requirements definition, it gets into a team’s backlog, the backlog gets prioritized? They finally pull it into their sprint, they finish it in their sprint, they get it into testing, and through regression, and through user acceptance, and to production- it’s actually into the field. How long does it take from idea all the way to it’s in production? A normal, high priority feature.

We’ve got 20% that are longer than a year, we’ve got more than half that are longer than 6 months, we’ve got some mixture in here 1 to 6 months. It takes a really long time. Think about this from a business stakeholder perspective. They just came up with something that they think would be a really good idea to build, that would help them save a lot of money, help you drive a lot of revenue. Whatever that thing is and they have the daunting task of getting it into that process. And who do they think in the organization is the bottleneck? Us.

If those IT people would just- they come in in flip-flops and beards, it takes a year to get anything done.” Let’s talk about this problem. Our team now, in a sprint, can break work down, they’re getting to done-done. That’s just a small part of the problem. What is your organization trying to optimize and who are they telling to go faster? “The developers they just need to code faster, if they just would code faster we could get this…”

No, that’s not the bottleneck anymore. We fixed that bottleneck, and once we start getting established velocity then we can start building trust in the organization. They can start looking at other parts of the organization. But if you don’t focus on Predict first, they’re going to blame you. That’s why we say Predict happens before Accelerate because if you focus on Predict first you can start exposing that the problems are somewhere else. We need to look at the whole value stream, from the point that an idea comes in, to the point that we deploy.

What I really want to know is at what point is [the idea] validated in the market? The reason why I didn’t have that in the first question is that for most of you, that would be infinity. You don’t get market validation, you just ship and then go onto the next release. We don’t actually know, did the features that we did implement make the impact that we thought they would.

When we look at this spectrum, one of the things that we apply to help to go faster are things like Scrum. Scrum just focuses on a small part of this, mostly on implementation with testing of the feature. But if we are doing things right we are focused on prioritization all the way through getting that feature ready to release, potentially shippable. We also have things like test automation and continuous integration. Which people all forgot about for a little while. “Let’s just implement scrum. Test automation, that’s going to take forever.”

You need to invest so you have continuous integration. That’s what’s going to optimize from getting implementation, all the way through it’s ready for deployment. There might have been a couple of talks, there might be a new buzz-worthy kind of word called DevOps, which is focused a little bit further downstream but starts at implementation. It is now saying we need to build upon this test automation and continuous integration, get to continuous delivery and focus on automated deployment to make this part of the process go faster.

I had an organization I was working with who were focused on the teams getting faster. You know how long it took to deploy their product? 12 weeks. Is their problem that they need the team to go faster? It was a one-year requirement prioritization process, a 3-month dev cycle of sprints, and then 12 weeks to deploy. The bottleneck wasn’t development in that process.

Then we look at things like lean product discovery that say how fast can we get from ideation to market validation. Maybe we are going to skip some of these steps in between and run smaller experiments. We are going to do a sliver of some functionality but it’s not going to be the full feature. Things like lean startup, using tools like user story mapping so that we can figure out if we building the right product, as opposed to just focused on building the product faster.

We need to look at optimizing all of this. Is this what the Scrum team is going to be focused on? No. Who needs to get engaged now? Leadership. So if any of you went to the talk, “What’s The Role of a Manager,” here is my slide for what is the role of a manager.

You don’t need to worry about the Scrum team anymore, they got that part. You don’t need to taskmaster anymore; you don’t need to tell people what to do; you don’t need to monitor what their progress is – the team’s got that. ScrumMaster, product owner, the team–they’ll figure that out. You need to be focused on the full value stream, that’s your job as a manager.

Your job as a leader in the organization is to optimize the whole all the way across here. Those are hard problems, those aren’t going to change very easily. But these are the issues that your team is going to start escalating up to leadership. Leadership needs to be ready and armed to go do something about it. So for sake of fire alarm time- think in your head, about what is the main bottleneck in your full value stream. Maybe jot that down, where do you think that is, but we are not going to discuss it right now.

What we are talking about now is Accelerate. So we got through the integration and practice of the Satir model by getting through Predict, by getting good at scrum, by getting good at these practices. Now we are trying to get faster and shortening cycle time. When we look at cycle time we look at the full value steam, not just now long does it takes a development team to get a feature. From the time it got into their ready queue, to the time it left their queue.

In the talk that William is going to be doing next, he is going to be talking about portfolio level kanban and looking at how do we look at things across this full value stream. When we look at accelerate, the pains that you are seeing like long release cycle times. A lot of times that is the number one goal. People say, “we need to go shorten cycle times, our time to market is too long, it takes for a year.” The main thing I want to convey in this talk is that you can’t just start with going faster. You got to focus with “are we aligned around a problem so we can start reducing the resistance, are we investing in the learning and the slack to learn, is it a safe to fail environment/ safe to learn environment, are we focused on getting good at the core practices around and allowing us to predict so that we can now start to go faster. We have to invest in those things first. So what I want you to do is, what’s your (organization’s) level of accelerate? 5 being “we’re great, our cycle time is so awesome, we have optimized our full value stream, there is no room for improvement;” and 1 being, “I don’t even know why I’m at this conference. I mean it takes two years to get an idea done. Actually, I’m at this conference because they won’t miss me.”

As I was expecting, we are kind of in that 2-3 range, we got some 20% down here in the 1’s. We’ve got some teams that are moving fast which I expect. If I go and look at those organizations maybe they’re a fairly newer cloud saas, continuous delivery environment, and they invested in those things from the beginning. My saddest moments around town are when I go meet somebody and they’re at this 1-year-old startup and they haven’t done any test automation, or any continuous integration, or any continuous delivery and they’re building a cloud saas product. And I’m like shame on you. Most of you in the room, I understand you have a legacy product. It’s 10 years old, it wasn’t really cloud when it started and now it is, or it’s like asp something or other. We have a big investment to make, but folks that started out in the cloud saas world in the last 5 years there is no excuse for you not to invest in having the infrastructure that’s going to allow you to go fast because your market is going to demand that.

Path to Agility Phase: Adapt

Pitfall #5, and then we’ll be out of here, is that thinking Agile is just helpful for tech. In the keynote this morning there were multiple people that asked: “can we apply this stuff outside of Agile?” Hell yes, but we’ve got to prove to the organization that we can do it well inside of our own part of the organization before we can start really evangelizing it across the organization.

We know the world has changed. The way that we would manage this factory floor is not how we should manage today. However, many organizations are still being managed in this kind of command-and-control, hierarchy driven way. That’s not just in the technology group, this applies across the organization because we have a different work force. We don’t have a work force in most of the U.S. companies, in most of your companies, that are just semi-skilled work force.

We have a problem. There is a stat that says only 1 out of 5 knowledge workers are fully engaged in their work. That means out of 5 people, only 1 of you have decided to bring your brain to work today. I want to know who that person is because I’d like to direct my attention to them right now. A lot of times it is the manager, and they haven’t empowered their team. They’re not giving the team autonomy and they’re taking all the control. The team is checked out and like, “ they pay me the same and I don’t have to think.” Many of us in this room, if we were in an organization where we weren’t allowed to think, we would say “bye-bye. I’m going to go somewhere else because I want to have the autonomy to do that.”

Some of you have read the book Drive by Dan Pink or at least you have seen the video. If you haven’t seen the RSA animate video, search for “Dan Pink, Drive” watch this video immediately, send it around to your leadership team. And what it says is “money is not a motivator for knowledge workers. Money can be a motivator if we are not paid enough. But once we are paid enough, say that’s $100,000, I’m not going to choose a job between this one that pays me $100,000 and one that pays me $105,000 because I am getting paid enough. What I am going to choose is the job where I have a sense of purpose, mastery, and autonomy.

These are things that we need to focus on. These principals that we see in Agile around self-organizing teams, around focused on improving our craft, on focusing on having a vision, clear priorities, clarity. These aren’t just things that apply to our software organization, these apply to everywhere in your organization that has knowledge workers. What we see is that our leaders are emerging out of Agile organizations, our leaders of our future, not just the leaders of the technology group. So you guys are all being armed to become the next wave of leaders in every organization, in all aspects of those organizations, because you know how to work with a team of knowledge workers and how to get them to be highly effective.

What we see when we get to Adapt, is that we want to focus on taking our champions out of our technology groups and having them spread that across the organization. What happens is we start seeing some organic kind of virus spreading. “That’s really cool what you guys are doing, can we do that over here in marketing?” Yeah, you can make a visual board. You can start getting a visualization of the problem. You can start having a daily huddle so everybody is synced up. You can figure out how to swarm on problems.

When we get to Adapt, we’re saying the teams are doing great but now we can focus on the organization as a whole. We can start working with those organizations to help them truly work with organizational agility. I get this question all the time, “we’re doing Agile, but we’re in a waterfall world.” What that means is you’ve figured out Agile down here, but the organization is still running in waterfall. That’s common, that’s part of the journey. We’ve got to figure out how to be Agile here, now we’ve got to spread it to the other parts of the organization. We’ve got to start finding groups and pockets of folks that are interested in this. This can be applied at the executive level, this can be applied in HR, marketing, in any operations. We have applied this in every part of an organization, so the organization can start responding with agility to market demands and empowering their workforce. The last rating- Adapt. How do you think you guys are doing in Adapt? How well is your organization at being adaptable? How well is your organization responding with agility?

To wrap up, you’ve got this sheet. I want you to think about what is the top thing that you could go and implement that you’ve written down on your sheet. I want you to circle that because can we go change 5 things tomorrow? No, we can go change one thing.

Here is the final poll, a word cloud. I want you to write what is one word that describes your top pain. Injects, alignment, leadership. We’ve got some training, we’ve got resistance over here, ignorance.

Alright, so one last poll then we will be out of here. What is one word that describes the top solution that you discovered today, that you think you could go implement or help your organization? You may not be able to implement it on your own, but what do you think is the top solution your organization should implement. We’ve got alignment, training, education, leadership. We could implement leadership, like “if we just had some damn leaders around here.” Alright so, you’ve got that. If you haven’t stopped by our booth, you only have like 20 minutes left to do that.

I’m David Hawks, thanks a lot.

**Not a transcript word for word. We removed instructions and cleaned up some text.