The Big Game

My post yesterday about managers leading agile teams got quite a bit of attention. We had a great discussion over Twitter and many of you guys left fantastic comments on the blog itself.

The one thing that came out of all that discussion... for me personally... was greater clarity around the real nut of the issue. It's not so much having managers or not having managers... or defining what managers are going to do... it's really about positional authority and who is going to be allowed to tell who what to do. I'd like to thank Esther Derby for helping to distill that for me.

Managers in different organizations do management differently. Some managers are like architects or technical leads... and have their hands in day to day technical decisions. Others are non-technical and mainly handle people issues on their teams. I guess the real question is that... regardless of what we ask managers to work on... are managers ever allowed to direct the work of the team?

As long as managers are held responsible for the performance of their teams... this is going to be a somewhat problematic question. Can we trust our managers... who currently HAVE positional authority... and the responsibility that comes along with it... to behave as agile leaders? Can we coach them to set direction but empower, to act as a mentor for their teams, to manage with a light touch, and genuinely help their team members be successful?

Unless we are going to fundamentally change the core structures of our businesses... and tear out all positional authority and management heirarchy... and really hold TEAMS accountable for outcomes... managers are going to be around a while. All I am suggesting is that we really figure out what to do with these folks... explain clearly how we are asking them to change... help them through the transition... and make sure we aren't holding them accountable for outcomes... and incenting them toward behaviors... that directly contradict the goals of our agile change initiative.

That's where the 'let's treat managers like grown-ups' comment came from.

Mike

PS - My family and I are driving to Destin, FL for a few days... in the rain... and I am blogging for the first time from my iPhone. That is why this post doesn't have a picture and might even have some goofy spelling or formatting problems. I'd like to thank my wife for taking over driving duty on this leg of the journey!

Subscribe to Leading Agile

Cutter Executive Report: Rethinking the Agile Enterprise

My good friend Dennis Stevens and I just finished up our Cutter Executive Report titled 'Rethinking the Agile Enterprise'. The paper is now out in print and available for download via the Cutter website.

For regular readers of Leading Agile... you'll notice many of the same 'scaling agile' themes I talk about here quite often. The report explores why small team agile works and how the enterprise can transition from small teams to projects... to portfolios... and ultimately scale agile out across the entire enterprise. Dennis and I talk about specific learning outcomes that have to take place along the way and introduce a model called 'Capability Analysis' that will help organizations think differently about where they focus their investments.

The site will require a promotional code (RETHINKING) and you will have to give the Cutter Consortium your name and address information in order to receive the paper. Download the paper now and let me know what you think!

Subscribe to Leading Agile

Can Managers Lead Agile Teams?

If we are going to start treating managers like grown-ups... and start asking them to behave like agile leaders... and giving them a real role on an agile team... let's begin by exploring why we excluded them in the first place. Maybe if we can take a step back and think about the original problem we can find a more inclusive solution.

Here is my take...

Agile excluded management because people are sick of being yanked around. They are tired of managers telling them what to do... changing their mind... and then deciding that they want everything according to the original schedule. People are tired of being treated like cogs in a machine and being moved from project to project and team to team like interchangeable parts. People are tired of being micromanaged and having to check their brains at the door.

People are tired of building low quality software just to meet unreasonable schedules... to meet unreasonable budgets... imposed by unreasonable Dilbertesque managers. They want to be connected... they want to be treated like whole... thinking... feeling... creative human beings. They want to be treated like people that have something more to contribute than just two hands and a social security number. People want to do meaningful work and be part of something bigger than themselves.

I always imagine those early Scrum teams sitting around going... hey, this is a bunch of crap! These managers can't make up their minds. Just put us devs in a room... leave us alone... and let us write some code. Give us one person... we'll call him a Product Owner... and we'll build whatever he wants. Oh... and by the way... we need someone to go and run interference and fix stuff for us. Hey you... come over here and be our Scrummaster. But none of you people can tell us HOW to do our work... we are going to self-manage and self-organize!

Think for a minute about what is really being said here:

The Product Owner is the personification of a well aligned business. The Product Owner is the team's answer to getting yanked around. They are the product manager, the project manager, the business analyst, the UX designer, the UAT tester, and in some contexts the dev manager. Can't get the business to make up it's mind? Well... we'll make it simple for you... Frank gets to decide. He can go argue with himself... we are going to build some software!

The Scrummaster is there to make sure the team has everything it needs and that any impediments are out of the way. Tired of petty, controlling, micro-managers... tired of being bartered between teams like a head of cattle... let's take away all of Sue's positional authority and call her a Scrummaster. The Scrummaster is everything good about management... explicitly leaving out the stuff we don't like.

But wait... now that we don't have all these project managers and dev managers... who is going to tell us what to do? Well... I guess we will. We will be self-organizing and self-managing. We'll take charge of our own destiny... our own careers... and earn the right to be left alone. We'll plan together... meet every day to talk things out... and review our work with the Product Owner. When we are done.. we'll figure out for ourselves how to get better and improve.

Sounds nice huh?

The problem is that all these managers that used to be in charge didn't go away... they still work for the organization. And guess what... they liked being in charge. They got paid well for it... it was good for their egos. Why do we think these folks are just going to go away without a fight!? Not giving them something to do only encourages managers to resist... and that resistance puts all our agile goodness at risk.

Product Owners fundamentally address the organization's alignment problem. What if we could use our managers to help really get our organizations into alignment? What if the business could really articulate what was important and managers could clearly communicate what it was that their teams needed to build... would the need for a single Product Owner be so important? Somehow I don't think so.

What about Scrummasters? If we could teach our managers to be servants of the team... to be real leaders... to be facilitators first... would we still need a separate role? What if... once we solved the alignment problem... and managers were no longer given unreasonable deadlines... unrealistic budget constraints... and more work than their teams could handle... they started behaving in ways consistent with a Scrummaster but retained their positional authority? Would that be all that bad?

Going into organizations and telling them that each team has to have a Product Owner and a Scrummaster in addition to a traditional manager doesn't fly in most organizations. Telling managers that they no longer have authority over their teams because their teams are now self-managing really isn't going to work either. Personally... I think we need to slot our managers into one of the two roles... priority and business alignment (the PO) or the management and issue resolution (the Scrummaster).

We should allow for and embrace their positional authority and incent them to encourage more empowering... self-organizing behavior in their teams. Many managers will be able to rise to the occasion... many of them are already there. Those that can't need to be coached and developed just like any other employee of the business. Those managers that cannot or will not change then have the option to stay or move on to a more command and control organization.

Subscribe to Leading Agile

Managers are Grown-ups Too

One of the first things I do when I meet a new team is ask them to introduce themselves and tell me a little about what they do. We go around the room and people say things like "hi... I'm Bob and I am the Product Owner" and "hi... I'm Sue and I am the ScrumMaster". Well inevitibly... once we get going... usually by lunch time... I find out that Bob is really the Director of Development and Sue is the really the team's Project Manager.

Here's the deal... we agilists haven't given our managers anything to do. Many of us believe that there is a role for management on agile teams... some don't... but we never really say just what that role is. Remove organizational impediments... boring. Make sure people have development plans... boring. It's not that those things aren't important... but managers are used to being in the thick of things... they are used to running the show. They are problem solvers.

Because we haven't given manager's a role... they have gone into hiding. They call themselves Product Owners and ScrumMasters but in reality they are still Dev Managers and Project Managers. They are still responsible for the performance of their team members and their organizations are still holding them accountable for the outcomes of their team. Here is my question... is this a healthy pattern or an agile anti-pattern... a smell?

It seems to me that we are asking everyone one else on the team to learn, grow, and adapt. We are asking every one else on the team to learn servant leadership and to be collaborative and inclusive and create safe environments. People on teams are going to have managers... that is just a fact. Is it a problem to ask a manager to serve as a Product Owner or a Scrummaster if having that role makes sense? Can we trust a traditional manager to take agile leadership seriously and learn to behave with a servant leader mentality?

The best managers I've ever had... agile or not... were servants of the team. They knew how to lead and empower... to prioritize and faciliate. These leaders allowed me to decide what I wanted to work on and held me accountable for my outcomes. We talk alot about how agile allows us to start treating our team members like grown-ups... I'd like to see us start treating managers like grown-ups too. Agile teams are going to have managers... let's really start giving them something meaningful to do.

Subscribe to Leading Agile

In the absence of done... there is risk.

Agile methods put a high premium on what it means to be done. But if done is so valuable to our projects... just what exactly does done mean? Is there one universally accepted definition of done... or are there varying definitions of done depending on your circumstances? Personally... I have used and coached several definitions of done and am pretty much cool with all of them.

My favorite definition of done was something that I used back in my CheckFree days. We defined done as a feature that was designed, documented, developed, tested, accepted, ran on the UAT server, could be run from the Product Owner's laptop, and that the Product Owner was proud to show to their customer. We did not specify 100% test coverage or that the software was released to production... were we done?

What about the situation where a team is transitioning to agile and trying to iterate through a big up-front design document to ultimately get ready for a big back-end test effort after all the code has been written. That team defined done as working software with 100% test coverage and deployed to the alpha environment. Were they done?

Here is a situation I was talking through today. What if you are developing a feature that has dependencies with several component teams across a large complex enterprise. If one of the component teams delivers an API that is fully designed, documented, developed, tested, meets the specification, and is ready to be integrated with the other components into the larger feature... is the component team done? What about the feature team?

Done can mean lots of things... and the definition of done needs to be defined by the team doing the work and the organization receiving the work. To me... it is a matter of risk. How much risk are we absorbing leaving the code in it's current state?

While not perfect, I felt pretty good about the definition of done on my CheckFree team. The transitioning team I mentioned is actually absorbing quite a bit of risk with that big back-end testing effort... but given their circumstances... I would accept that definition of done and work to mitigate the risk. In the last scenario... the component team is done but the feature team is not until the code is integrated. Does the component team absorb some risk... absolutely.

The definition of done should be driven by the potential impact to the project. We are assessing the risk that we think ourselves done but really aren't. We are assessing the risk that we have to go back and fix something. We are asking how much risk we're absorbing if we allow partially completed work to move forward in the development process. That could be as little undone work as allowing less than total test coverage or as much as allowing a component team to move forward before their work has been integrated into the larger, customer facing feature.

In the absence of done... we have risk. I am okay defining done differently as long as we address the risk and have a solid strategy for mitigating that risk.

Subscribe to Leading Agile

Scrum or Kanban... it's not Black or White

It's been fun the past few months to watch Kanban get some traction out in the community. It seems that my Google Reader is full of agile guys talking about Kanban. If you are David Anderson... this has to bring a little smile to your face. David and a few others have done a great job generating quite a lot of energy around this topic.

One of the things I found really interesting over the weeked was the words some folks were using to describe the value of Kanban. They were using words like 'increased visibility' and 'buidling trust' with the business. While I wouldn't argue with any of that... I was struggling to figure out how the benefits of Kanban were any different from how we would describe the benefits of Scrum?

If both methods 'increase visibility' and 'build trust'... there has to be something more. In my opinion... the key difference between Kanban and Scrum is that Kanban makes explicit what Scrum leaves implicit.

Let me explain...

Scrum takes the approach that the team is a black box. The business puts requirements in... and after some predetermined amount of time... they get working software out. Within that black box... the team gets to self-organize... they get to self-manage. The business gets to decide what... the team gets to decide how. The processes inside the team are abstracted from the business AND from management.

Kanban takes the approach that the team is a white box. The business puts requirements in... but rather than leave it up to the team to figure out how best to deliver the work... management plays a role in defining the work. There are explicit workflows... work in process limits... and visual controls that track the flow of value through the team. Kanban gives managers a role helping to deliver working software.

One of the earliest agile books I ever read was Mary Poppendieck's 'Lean Software Development: An Agile Toolkit". Not long after that I read David Anderson's "Agile Management for Software Engineering". Lean thinking and theory of constraints were just built into the very fabric of how I thought about and managed agile teams. As Kanban started capturing mindshare over the past few months... I found myself wondering what was so new.

We teach Scrum teams not to wait to the end of the iteration to deliver features to the product owner. We want to see linear increase in story completion during the sprint. We talk to each other everyday to identifty and remove impediments. When one team member is struggling to get something delivered... we are encouraged to help them get finished before we start on something new.

Scrum teams should be constantly focused on getting to done. I would argue that there is a bunch of single piece flow thinking up underneath a well run Scrum team. I would suggest that there are some implied work in process limits at play. I would suggest that effective Scrum teams are continuously indentifying and elevating constraints. For some teams... in some environments... it probably makes a ton of sense to make all these implicit controls in Scrum explicit by using a Kanban. Is it necessary in every environment? That's where I am not totally sold.

For now... for me... Kanban becomes another tool to help teams predictably deliver working software in the face of uncertainty.

For another view of this... go check out Dennis Steven's post on 'Uncovering Better Ways of Delivering Software and Helping Others do it'. It is a good look at how Kanban can help teams get better at delivering software without some of bad attitudes toward management that Scrum can sometimes encourage. Dennis might be a little more sold on Kanban that I am ;-)

Subscribe to Leading Agile

But what if I already know everything!?

But hang on a sec! You might be thinking that you have all the information you need... and if I have all the information I need... there is no need to hold off making that decision. Right?

The problem with making a decision early is that you don't always know what you don't know. By buying some extra time... by deferring an option until closer to its expiry... you create an opportunity to learn MORE information... information you probably didn't even know would come available.

You might even end up with some new options... and guess what... those new options have value too! And that is the real rub... it's not just the value of the of the options that you have now... it's also the value of the options that have not yet presented themselves. There are times when it makes sense to decide early... but make sure you know why. Fear of the unknown is not really a good reason to decide early.

If you are deciding early because you think you know everything... you might be closing off options you didn't even know you had.

Subscribe to Leading Agile

I'd Rather Be Wrong!

"If you choose not to decide, you still have made a choice" - Geddy Lee, Rush

Real Option theory tells us that our choices have value. In other words... the choices we make have an economic impact. Real Options also tells us that our options expire. That means we don't have an unlimited amount of time to make a decision. Playing the Real Options game involves figuring out just how long our options will be available... and using that time to gather as much information as possible... so we can make a better decision.

Earlier this year my wife and I were faced with a pretty tough decision. We were trying to figure out where to send our kids to school. The previous few years we had been running a small private school and our kids went there. We decided that our school was too much effort to run and no longer the best educational alternative for our kids... so we had a decision to make.

As we were trying to figure all this out... we identified three primary options that met with our educational goals... and were in alignment with our personal finances:

1. Continue to run our current school and send our kids there
2. Send our kids to a top notch public school that was nearby but out of our district
3. Send our kids to the nearby public school

Back in January we needed a plan but didn't have all the information. The pressure was mounting because if we wanted to pursue option #2, we had to apply and pay a rather hefty deposit. Pay the deposit and the option stays open... don't pay the deposit and the option expires. We decided to pay the deposit... not because we were sure we wanted to pursue option #2... but because it was worth the money to keep the option open a little longer while we figured things out.

What made the discussion interesting... and maybe even relevant our discussion here around barriers to agile adoption... was the difference between how I handle uncertainty and how my wife handles uncertainty. I am definitely the risk taker in our marriage... my wife likes to keep things pretty stable. On most things that is a great balance.... but sometimes when it comes to assessing risks and the best way to manage risk... sometimes we don't see eye to eye.

My wife's initial reaction was to commit to option #2... communicate our decision to disband option #1... and eliminate option #3 from consideration. The problem was that if option #2 didn't work out we would no longer have option #1 available. There was no economic value to locking in our decision early... but my wife's need for certainty would have caused us to commit before we had all the information. By waiting... by purchasing more time... we ended up with more information and that helped us make a more informed decision.

Its that fundamental need for certainty... and it is a need... is what makes the conversation difficult.

As a community... we are trying to get folks to embrace change and to embrace uncertainty. We've got to recognize that we might be asking folks to embrace more uncertainty that they can likely handle. The reality is simply that many folks would rather be wrong than be uncertain. If you are working with folks that are not risk takers... if you are working with people that value operating in highly predictable environments... Real Options can give you language to help them see value in deferring some subset of their decisions.

Making decisions early has an economic impact to our projects. If we can quantify that cost in terms of real dollars and risk probability... we might have a chance to change how people think about change and uncertainty.

Understanding Real Options - Mike Cottmeyer, July 2008

Subscribe to Leading Agile

7 Tips to Get Started Blog Writing

Man... time sure does fly. I was looking over some old posts and realized that I started writing this blog almost two years ago. That got me thinking a little bit about blog writing and how my writing has changed over the past few years. I thought I'd take a moment to explore what I've learned and maybe share a few experiences.

The first six months or so this blog was in existence I was too busy to do much writing... I had a day job... I had a family to raise... there was just no time to sit down for hours on end to write. I wanted to write... I just didn't make it happen. I generated something like 3 posts in those first few months. When I look back on it... if I am really honest with myself... I was really just concerned about looking stupid in public.

It took weeks to write a post because I wanted everything to be perfect... I couldn't let anything go.

The guy I was working for at the time gave me the best advice ever... he told me to get over it. That's easier said that done... but you know what... that is just what I did. I got over it and started writing. It helped that I changed jobs and got out of the daily grind of project management. It also helped that I have the support of VersionOne and a bigger platform to share my ideas. Even with all that... it took some time to get good at generating content without spending hours and hours doing it.

Writing is a skill that can be learned... there are processes you can follow and you can get better. You can get better capturing ideas... you can get better writing quality content... and you can get better getting those ideas on your blog faster. After some 150 posts, several whitepapers, and a couple of longer reports... I feel like I have learned a few things about the process of writing.... at least blog writing. I want to share a few tips with all you would-be bloggers to help you get started.

1. Keep an idea inventory

I am always on the lookout for good blog ideas. Not many areas of my life are really off limits. As you might imagine, most of my ideas come from interactions with clients and other folks out in the agile community. A lot of my posts though are influenced by my family... my involvement in Boy Scouts... and by my friends at church. Whenever you get a good idea... actually, any idea... write it down.

2. Set a fixed amount of time to write

Try to limit your writing to two hours. When you are just getting started, this bit of advice might be hard to follow. The idea is that you want to set limits and create a little pressure to perform. It is easier to sit down and write when you can allocate a set amount of time and know you won't be interrupted. It's also helpful to know that you can't just sit there forever staring at a blank page... you've got to write something!

3. Write down your key point

There is nothing worse that reading a rambling post where the author doesn't know what he wants to say. Start writing your post by jotting down a sentence or two that helps you stay focused on the significant point you want to get across. Also... as you start writing... plan to communicate your key point in the first paragraph or so. Personally, I lose interest if I am not sure where you going. You're writing a blog post... not a suspense novel.

4. Start brainstorming content

Once you know your key point... start writing down ideas that support your key point. At this stage, don't worry about sentence structure, grammar, sequence or flow. You just want to get the ideas out of your head. More often than not it's the formality of the language that is preventing you from getting your ideas down on paper. If you can just get the ideas written down... after a paragraph or two... you'll probably find that the structure of the post will start taking shape in your head.

5. Actually write the post

Now that you know your key idea and have some supporting content... start actually writing your post. The focus at this step is to organize your thoughts and begin getting the ideas into a coherent sequence and paragraph structure. You are telling a story... it should have a beginning, middle, and end. Spend some time cutting and pasting the ideas around to make sure you've got the right story in the right order. Start roughing in your ideas using actual sentences. The post does not need to be perfect... but you should begin to have a pretty good idea of how you are going to make your point and how the post is going to flow.

6. Proof-read and proof-read again

After you have all your ideas in sentence and paragraph structure... go back and reread it to make sure it is all making sense. Sometimes when you are working on the parts of the post, it is easy to lose sight of the whole story. At this step you are fine tuning the order of ideas, sentence structure, paragraph breaks, headings, spelling and punctuation. Focus on flow, clarity, and final presentation.

7. Publish your post

Try to find some sort of interesting graphic that supports the key idea behind the post and makes the article a little more visually appealing. Now just load your post into your publishing tool ... preview the post... make any final formatting changes. Now you are ready to post.

Good luck and let me know how it goes!

Subscribe to Leading Agile

Subscribe to Leading Agile

Are we Overly Compliant?

Post before last... I made the point that companies often have a hard time adopting agile because their management structures are not in alignment with their corporate objectives. We have project managers and resource managers and product managers. We have teams of specialists matrixed into product teams and project teams and component teams.

Each team has its own set of objectives... their own sets of metrics... and each are pulling the company in oftentimes competing directions. To create an agile organization... we need to get our core systems in alignment... we need to move toward common goals and objectives.

Legislation and Policy versus Intent

Paul Boos did a nice reply to my post and brought up a great point. Sometimes all those policies and metrics and such are self-inflicted. Paul works in the government and tells a great story about how legislation transforms from some idea with some worthy intent into a set of misguided policies and metrics at the department and agency levels.

Congress passes a law stating that government IT projects must have an Enterprise Architecture. The Office of Management and Budget then decides that all departments have to use their common architectural framework to be in compliance with the law Congress just passed. When Paul's particular department gets a hold of the legislation... and the guidance from the OMB... they determine that all technical decisions have to be passed through their governance committees. It's a way to make sure the USDA complies with the regulation coming down from on high. Now when Paul's specific agency get's a hold of the policy decision... they determine that the team is only allowed to use specific technologies that are already approved by the USDA and the OMB.

(NOTE: I slightly revised the previous paragraph to more closely reflect Paul's intent, and the way the government actually works... this is an oversimplified example by the way ;-)

The intent of the law was to foster collaboration and reuse between departments but gets implemented as a set of draconian policies that limit creativity and innovation. What would happen if we could rethink some of the policy and metrics and focus more on the desired outcomes?

Corporate Audits

Before I joined VersionOne I worked for CheckFree Corporation here in Atlanta (since acquired by Fiserv). Our PMO had put all these big tollgates in place so that our projects could pass audit. As our team was trying to drive agile into the organization... we would constantly get push back because our agile projects couldn't pass audit given we didn't have the right documentation at the right time to pass the formal tollgates.

Come to find out... the auditors didn't care about our tollgates... they only cared about our paperwork because we told them that was the process we used to create software. They didn't care that we used waterfall or PMI or RUP or whatever... they just cared that we followed the processes we had said we were going to follow. If we told them we were changing our process... they would hold us accountable to the new standard... and as a matter of fact... that is just what we did.

We took a fresh look at the audit process and established a framework that could be configured project to project. The new framework enabled traditional software lifecycles and agile lifecycles to coexist and both were able to pass an audit. By focusing on what we needed to accomplish... rather than how it was being accomplished... we were able to focus on optimizing the outcome rather than optimizing the existing processes we were using to get the outcome.

Monkeys and Bananas

Have you guys ever heard the story of the Monkeys and the Bananas? I sourced the story here... it is relevant to our conversation so here goes...

Start with a cage containing five monkeys.

Inside the cage, hang a banana on a string and place a set of stairs under it. Before long, a monkey will go to the stairs and start to climb towards the banana. As soon as he touches the stairs, spray all of the other monkeys with cold water.

After a while, another monkey makes an attempt with the same result - all the other monkeys are sprayed with cold water. Pretty soon, when another monkey tries to climb the stairs, the other monkeys will try to prevent it.

Now, put away the cold water. Remove one monkey from the cage and replace it with a new one. The new monkey sees the banana and wants to climb the stairs. To his surprise and horror, all of the other monkeys attack him.

After another attempt and attack, he knows that if he tries to climb the stairs, he will be assaulted.

Next, remove another of the original five monkeys and replace it with a new one. The newcomer goes to the stairs and is attacked. The previous newcomer takes part in the punishment with enthusiasm! Likewise, replace a third original monkey with a new one, then a fourth, then the fifth. Every time the newest monkey takes to the stairs, he is attacked.

Most of the monkeys that are beating him have no idea why they were not permitted to climb the stairs or why they are participating in the beating of the newest monkey.

After replacing all the original monkeys, none of the remaining monkeys have ever been sprayed with cold water. Nevertheless, no monkey ever again approaches the stairs to try for the banana. Why not? Because as far as they know that's the way it's always been done round here.

Are we Overly Compliant?

So... how much of what we are doing is because we're a bunch of monkeys that don't know any better? How much of what we are doing is because it's the way things have always been done? How much of what we are doing is based on our interpretation of the law rather than from a firm understanding of the intent behind the law?

Have we taken the time to really assess these constraints and figure out what needs to change to accommodate our agile transformation?

Subscribe to Leading Agile

Subscribe to Leading Agile

Dancing at Starbucks

Sunday morning I took off to do a little hiking at Little Mulberry Park. On my way I stopped at Starbucks for my morning coffee.

Lady: Good morning, welcome to Starbucks, what can I get for you today

Me: Good morning, I'll have a Venti Pike's Place with extra creme

Lady: Great, would you like anything else with that, a blueberry scone maybe?

Me: That sounds delicious but I think I am going to pass.

Lady: Okay then, your total is $2.24 you can pull around to pick up your order.

Me: Thanks very much!

This conversation was almost idenitical to every other conversation I have had in a Starbucks drive through. It was like we were reading a script... she knew what she was going to say... I knew what I was going to say.

It was predictable but created the opportunity for both of us to learn something new. For some reason yesterday... I found our little dance oddly reassuring.

Subscribe to Leading Agile

Subscribe to Leading Agile

Is your Organization out of Alignment?

Today is a good day. We got the kids up early... went out for a big country breakfast at Papa Jack's... and then drove up to South Carolina to pick up a mess of really awesome fireworks. You can't get really good fireworks here in Georgia... and since the South Carolina border is only about 90 miles North of Atlanta... we decided to make a trip. We've got about 20 lbs. of ribs basting in the oven... which should be ready in about an hour... so needless to say... but I'll say it again... it is a good day.

While we were driving this morning I got to thinking about my post from yesterday and why people fail to adopt agile in a meaningful way. We were talking about how often people fail to consider the human side of change. We tend to think in terms of process and practices... we don't think as much about the fears that are holding people back and preventing them from letting go. That said... and this was what was nagging me a bit... it's not fair to imply that fear, uncertainty and doubt are the ONLY reasons we struggle to adopt agile... often there are other factors at play

Our Trip to Disney World and Mike's Back Problem

I want to tell you guys a little story.

Up until last year... we used to take the kids to Disney World every October. Disney is great family fun and I highly recommend it. The only reason we didn't go last year was that the kids were getting older and decided they wanted to try something new. Last year we went on a cruise to Mexico.... but I digress. Back to the point... the last time we went to Disney for vacation... I threw my back out the day before we left. I had never experienced anything like it. I've always been pretty healthy and have never had a back problem. I didn't know what to do and it sucked... sucked bad!

My kids we ready to go to Disney... my wife was ready to go to Disney... so we went to Disney. I spent the first two days walking the park... riding rides... and trying my best to have fun... but in reality I was pretty miserable. It's kind of funny... when I look back at the pictures from those two days... I had a smile on my face... but I can see the pain coming through the smile. Back problems are no fun at all.

The morning of day three I finally had enough. We were at Disney's Animal Kingdom and my wife looked over at me and told me I had to go to a doctor. Not knowing what the heck a doctor was going to do to get me through my vacation... short of prescribing some pain killers which I did not want.. I decided to go to a chiropractor. To that point in my life I had never been to a chiropractor and I wasn't sure what to expect...

Long story short... the chiropractor told me that my spine and pelvis were not where they were supposed to be and it was putting pressure on a nerve in my lower back. He did a minor adjustment and I was functional and relatively pain free the rest of the week. Good news is that I haven't had a problem since... the chiropractor found and fixed the root cause... I was out of alignment.

I had the desire to go to Disney... I had a great attitude... I tried to keep a smile on my face... I wasn't afraid to ride the roller coasters... the problem was it just hurt. My body was not in proper alignment to take advantage of all the fun that Disney had to offer. A bunch of the companies I work with are kind of the same way. They want to do agile... they want the business benefit... they want to change... its just that their organizational structure is not in proper alignment to get the full benefits. It's like being at Disney with a back problem.

How do organizations get out of alignment?

Our organizational hierarchies provide the basic infrastructure in which we operate... in which we run our business... that is our foundation. On that foundation we have many forces that pull that structure in lots of different directions.

We have projects run by project managers with schedules, budget constraints, and performance objectives. We have managers that manage teams of specialists... the managers are incented to optimize individual performance and get maximum productivity from each team member. We have products that have their own set of managers... each responsible for managing their markets and trying to get as many revenue generating features in their products as possible.

We spin up teams to do projects... so we have a project team view. We have to mange the component architecture outside the context of any single project... so we have an archtiectural view. Projects might also be part of a program or a portfolio, team members are matrixed across multiple projects, products, and architectural sub-components... all of which put different pressures on the enterprise. Its amazing to me sometimes that we manage to get anything done.

Steven Covey in his book The 8th Habit talks about how so few people in a company feel they understand the objectives of the organization... that that they are working on the most important stuff... or that they are pulling in the same direction as their co-workers. Covey compares this to a soccer team where:

• 4 of the 11 players on the field would know which goal is theirs
• Only two of the 11 would care
• Only two of the 11 would know what position they play and know exactly what they are supposed to do
• 9 players are competing against their own team

Getting on the Same Page

So... while the people issues are really, really important... it is also important that the organization get in alignment if we are going to make a serious go at widespread agile adoption. That means putting some thought into how we create teams... what we have them work on... how we measure their performance... and how we have them work together. Its a matter of aligning the structures of our organization and then aligning team to support those structures. That is fundamentally what will make an agile organzation work.

Like most things... that kind of change doesn't happen overnight... but realizing this is a problem is more than half the battle.

BTW - Here is a picture of our fireworks stash we picked up today... pretty awesome!

Subscribe to Leading Agile

Subscribe to Leading Agile

Why are you Failing with Agile?

Okay... you're a few months into your agile roll-out. You did all the right stuff before you got started. Got sign-off from the execs... check... got team members trained... check... identified a pilot project... check... hired an agile coach... check. Why then... after all this time, effort, and money... are we still struggling with the fundamentals? Why can't we seem to get over the hump?

It seems that there is always someone... sometimes there are a lot of someones... that just don't seem to get it. They just can't let go of their trusted MRD... they can't seem to get past the idea that agile teams don't do Gantt charts. These folks want to know exactly when their project is going to be done... what it is going to cost... and what they are going to get for their money.

How do we respond to these people? Hey... agile can't be any worse that what we are doing now? Agile is all about trust... you just need to trust that this new way of doing things is better. Just give us a few sprints and we'll prove to you that this new way works. I promise, you'll like it.

Put yourself in that other person's shoes for a moment... your Product Manager was promoted and given big fat raises based on the insight and detailed analysis she put in those MR docs. The VP of Engineering got where he is today by making sure systems were designed fully up front. The Director of the PMO has built his entire career around applying the processes found in the PMBOK...not to mention the bonus he got for becoming a PMP in the first place.

These folks know something is broken... they know that we are making product development too hard...that is whey they let the team give this agile stuff a try in the first place. The problem is that... at the end of day... these folks are on the hook for making sure the organization delivers. When they are under pressure they fall back to what they know. They dance with the girl they came with.

It's important when we introduce something new that we spend some time figuring out what the people around us need to be successful. These folks have families... they have kids in college... they have financial obligations. You are not just asking them to change... you are asking them to put their livelihood at risk. People don't resist change because they are bad people or because they just don't get it. Chances are... at some level... they are afraid.

More than likely... there is some fundamental concern that you have not addressed. Until you understand what your detractors need to be successful... and work to satisfy that need... on their terms... they are going to continue to stand in your way. They will continue to hold you back and resist the changes you are trying to implement. If you had so much to lose... you'd probably do the same thing.

Trust me doesn't cut it until you have earned that trust. Agile will help you get there... but you know what... you might have to let them have their Gantt chart... you might have to let them have their MRD... until you can make it safe for them to let it go.

Subscribe to Leading Agile

Subscribe to Leading Agile