Archive for July, 2009
« Older Entries

The Big Game

Last Updated on Friday, 16 November 2012 12:51 Written by Mike Cottmeyer Tuesday, 28 July 2009 06:11

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!

Learn More
Posted under Uncategorized  |  5 Comments

Cutter Executive Report: Rethinking the Agile Enterprise

Last Updated on Friday, 16 November 2012 12:51 Written by Mike Cottmeyer Monday, 27 July 2009 07:30

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!
Learn More
Posted under Rethinking the Agile Enterprise  |  No Comments

Can Managers Lead Agile Teams?

Last Updated on Friday, 16 November 2012 12:51 Written by Mike Cottmeyer Sunday, 26 July 2009 09:50

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.
Learn More
Posted under agile management  |  11 Comments

Managers are Grown-ups Too

Last Updated on Friday, 16 November 2012 12:51 Written by Mike Cottmeyer Sunday, 26 July 2009 12:19

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.

Learn More
Posted under agile management  |  No Comments

In the absence of done… there is risk.

Last Updated on Friday, 16 November 2012 12:51 Written by Mike Cottmeyer Tuesday, 21 July 2009 12:38

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.

Learn More
Posted under risk, risk management  |  2 Comments
« Older Entries