I Want Control
Last Updated on Friday, 16 November 2012 12:53 Written by Mike Cottmeyer Friday, 1 February 2008 03:05
As an Agile Project Leader, I feel like I have lost control.
In my last post “The Road to Agility”, my original premise was that in order to be trusted, we have to be trustworthy. To earn the trust of our organizations, teams have to consistently deliver. To deliver regularly, we have to have structure and control.
I wimped out. I substituted the word discipline for control because I was concerned I would lose my audience. I was afraid people would react to the word control and stop listening.
I lost control, now I want it back.
As an Agile Project Leader, why should I be scared to use the word control? As a community, are we scared to be in control of our projects? I sure hope not.
But wait… we want collaboration, not control…. right? Control suggests authority. It suggests top down management. It suggests all those outdated project strategies we have seen fail time and time again.
Maybe when we talk about control, we just need to be specific about what we are controlling. Are we controlling people or are we controlling processes? Are we trying to control using predictive methods or recognizing the need for empiricism. These things matter when we talk about being in control.
As I write this, I am on a plane to Denmark. I sure hope my pilot is in control of this aircraft. Does that mean he knows every pocket of turbulence or mechanical issue we might encounter? Of course not. I do expect him to know where he is, to measure frequently to make sure we are on track, and adjust if we are not. I have to trust he will know we are off course long before we find ourselves out of fuel and having to land short of our destination.
Control on an agile project is all about visibility, inspection, and adaptation. You need to know what you have delivered and what is left to do. You need to know where you are at all times in relation to your goal. When you adjust, you need to be able to understand and communicate the impact to where we thought we were going.
Just like the pilot relies on a skilled support team to help him stay in control of the aircraft, the agile leader needs to collaborate with the team to maintain control of the project. It is not either collaboration or control, we must have both.
Don’t be afraid to be in control of your projects. Your teams and your business owners will thank you for it.Learn More
The Road to Agility
Last Updated on Friday, 16 November 2012 12:53 Written by Mike Cottmeyer Saturday, 26 January 2008 07:28
“Freedom consists not in doing what we like, but in having the right to do what we ought” – Pope John Paul II
“The more you tighten your grip Tarkin, the more star systems will slip through your fingers” – Princess Leia, Star Wars
Moving towards a more agile management approach is hard. Agile is hard because it requires a tremendous amount of trust. Trust can only be developed over time and must be earned. Managers must trust their employees to work in the best interests of the business. Teams must trust their management to create a safe environment where they can be successful. We must both be looking out for each other’s best interests.
Unfortunately, many organizations are not high trust environments. Controlling management hierarchies, office politics, and disempowering policies have created a culture where people expect to be told what to do instead of using their own judgment and initiative. People are not encouraged to offer their best thinking and are rewarded for playing by the rules. This slows down delivery and damages the overall effectiveness of the organization.
Businesses always demand more for less in a competitive market. This creates pressure for more productivity while at the same time productivity is being eroded. To get better results, management introduces more rules and more governance. Employees closely follow the rules because that is what is expected. This cycle continues until the management overhead becomes an impediment to completing any of the real work and no decisions can be made without management’s explicit consent.
Current thinking in the project management community is reflective of this flawed paradigm. In an attempt to get better project performance, we plan more, create more documents, deliver more frequent status reports, and try to hold people accountable for tasks on a plan. We slowly begin to hold ourselves accountable for the process and lose focus on delivering real value to our customers.
This process focus becomes so overwhelming that we find ourselves with either a suffocating bureaucracy or too little real day-to-day management of the project.
Agile seeks to solve many of these problems but methodologies are not transformed overnight and cultures take time to adjust. We cannot ask managers to abandon traditional management techniques without giving them alternate means to make sure their projects are delivering value to the organization. We cannot expect team members to self-organize and be empowered when they’ve seen so few first-hand examples where this has been rewarded.
We need a roadmap for helping teams incrementally adopt Agile. We need a framework for building trust in an organization. This framework must start with changes people can easily get their heads around and implement without losing focus on our desired end result. The agile community has focused on where we want to go but not enough on how we plan to get there. Trust is not sufficient until we prove ourselves trustworthy.
It may sound paradoxical but the path to agility begins with structure and discipline. Our goal is to create an environment of total transparency and accountability using techniques people can begin doing immediately. Making and meeting commitments is where it all begins. Establishing a routine pattern of delivery is key. Regardless of what methodology we are using now, regardless of our current project plans, let’s begin the journey by focusing on making and meeting commitments.
Link to original post on Agile Chronicles: