Agile Chronicles

Can Managers Lead Agile Teams?

Oops! This post has moved to the Agile Management Blog. Click here to read it: Can Managers Lead Agile Teams?

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.

Get Something Done.. Be Agile

How many times has the team decided they would start on every item without getting any items done? One comon Agile myth is that it is ok to start on every task just as long as you get them all done by the end of the iteration. We all know what most comonly happens is that the team underestimates the amount of time it actually takes to get work done, and end up not finishing anything they started.

I am starting to become a believer in the Lean WIP concept! It just seems logical to me that with a WIP limit in place, fewer things move to in progress and more work gets done. This means fewer items get left started and not completed. This means happier product owners and project managers.

The picture that came to my mind as I thought of this was Thanksgiving dinner. What if I started cooking everything all at the same time, but did not agree to finish cooking anything. Then as people became more hungry, I agreed to complete various items at various times. I just could not imagine that the guests for dinner would be pleased with such a concept.

Teams need to get used to the concept that they are not at work to punch the timeclock, nor will they receive recognition for How much work they got underway! Our effectiveness is based on the amount of work that gets completed. One of our goals should be to never leave the turkey half baked! We all need to get in the habit of doing as we say and saying what we will do. We need to do a better job of continuous flow of information and maintaining the highest levels of visibility.

Institute best practices, be Lean, be Agile, enjoy Life!

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.

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

Oops! This post has moved to the Agile Management Blog. Click here to read it: Scrum or Kanban... it's not Black or White

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.

The Price of Freedom

How do we measure our freedom? How much does it really cost to make decisions that help us remain free? What steps do we take to endorse continued freedom and what do we sacrifice to make freedom available to everyone?

To some this may sound like pure patriotic banter, rest assured, there is a much deeper message. For some time, I have been advocating empowering Agile teams and allowing them the freedom to make choices that impact the progress on the project they are working on.

I have also at great length discussed the level of accountability that comes with the power to make decisions. After a period of deep retrospection, I have come to realize that for every organization, there is a price to be paid for freedom.

For most, the price is small in the sense that minor adjustments help the team stay focused and on course. For others however, this is not the case. People harness their new found power and create a negative environment where the work takes sidebar to personal and team agendas. This in turn negates the value Agile provides and taints the pool of hope for Agile to succeed.

In order to best take into account the one loose wing nut or rouge team within your organization, it is vital that some organization take place that sets a clear and solid mission with directive that establishes a goal with clear boundaries. Many people may feel like I am discussing Utopia here, I would argue that I am discussing practicality. It is OK to empower the team as long as the outer walls of the room still remain in place. It is more than OK to empower team members to make decisions that allow them to contribute at a higher level. It is not OK for team members to take this power for granted and create a price tag for hijacking Agile. (I wonder if that URL is already taken? http://www.highjackagile.com/?)

At this time of great economic recovery, we need to "let the product lead, make everything visible, and inspect & adapt often". Doing so, will allow for the price of freedom to remain low and afford organizations with Agile Implementations continued success. Now is the right time! Wave your Agile Flag! Consult your product council. Build tangible memories for years to come!

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.

Command & Chaos

Ever had one of those days where you just feel like you are reeling through the planning only to discover that once the plan is in place it is not exactly what you had hoped it would be?

As a result you decide the plan was poorly constructed and decide to plan again, only to find that by the third attempt that you may never get the plan just right. I am of the belief that a poorly designed plan that is executed actually gets the team farther than a perfectly designed plan that is never executed.

At the most recent Agile Roundtable we referred to this phenomenon as Command & Chaos. All too often we try to force the square peg through the round hole or try to perfect the square peg just so it will fit. A better approach would be to initiate contact with the square peg team and build a peg that works. A peg that can still be sanded, stained, and polished to look and work just as well if not better than the peg you started with. I have learned through experiences with my family that most often the poorly planned days turn out to be the most enjoyable. This is not to say that some planning is not important as a day at the pool in mid-January may not be as enjoyable as on a warm summer day.

When all is said and done, we should plan just enough to be responsible and execute as often as possible. Command & Chaos does not work and is certainly not going to solve your problems. Just ask Joe CEO (pictured above), and he will tell you that the Agile plan is in place to let him know sooner whether things are going smoothly or may not turn out as planned. The last thing we want to do is catch this guy by surprise. Be responsible, be accountable, be agile.

Are we Overly Compliant?

Last post 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?