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.
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
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
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.
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
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