Many of the customers I talked to during the past few years are either starting the process of becoming Agile or have been doing Agile for a long time. With very few distinctions, most of them have to plan their projects, monitor them, and report on them to upper management in a non-Agile way. Is that a problem? Are they truly being Agile? What does it take to become Agile? And what is the Return on Investment?
“We usually spend the first few months of our projects gathering detailed requirements”.
Does this sound familiar? If so, this should be a first flag that you are not truly agile. It doesn’t mean that you are doing anything wrong. It just means that your process doesn’t adhere to agile principles. If you wanted to ask what are these principles, then let’s take a moment and review them: http://agilemanifesto.org/principles.html . Specifically let’s focus on the following agile principle: “Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.” Thus if you have spent a good chunk of your project initial months writing requirements are you going to welcome having them changes late in the game? Probably not. You are most likely going to push back as much as you can and you will most likely embark on a negotiation with your customers or stakeholders. Negotiating with stakeholders, or compromising, leads me to talk about another agile principle: “Customer collaboration over contract negotiation“. This is actually part of the original Manifesto: http://agilemanifesto.org/ . It doesn’t means that we are going to just ‘accept’ whatever comes from stakeholders or customers, but the key is collaboration over negotiation. Do you have the right environment or framework to collaborate with your customers? If not try to evaluate how you can implement one that fits your context.
“We monitor how much time our developers spent on their tasks to pulse the project health: we have many reports to watch this data”
Usually these reports show mainly whether team members are working or not (you may disagree). Is it a good metric to measure the health of an agile project? Well let’s compare the data they would show to the following agile principle “Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.” If you are focused on how much time a developer spent on his/her task, are you implying that they should spend less time? Are you implying that they are not going as fast as they should? Probably a better metric is to monitor the remaining time, which will indicate to you how close you are to being done. The basis of the relationship among team members in an agile world is trust, motivation and empowerment. They real question you should be asking is do I trust my team? Do I trust that they are doing their best to get their tasks done correctly in the least possible time? Do I provide them with the support they need to get the job done? And last but not least, what is their motivation to work on your project. In addition there is an additional agile principle that is worth mentioning while we are on this topic: “Working software is the primary measure of progress“. Do you have the right metrics in place to measure whether your product is working? Working doesn’t mean that it runs only. It also means that it responds to my business needs and that it is providing the expected value while of course maintaining or enhancing its quality.
“Our team leads estimate the work based on their long expertise”
If that’s what you’re doing for estimate, are you taking in consideration everybody’s input? Are you being realistic? How is it working for you? Estimation is one of the hardest phases of a project, especially in an agile project. Your team leads are probably doing the best estimating a story that has very little details, they are not to blame if the estimation is off. While the agile principles don’t necessarily address estimation directly because the focus on the way we work to deliver value. However there are techniques that exist to help you get the best estimate possible. First of all the estimation should include everybody! If that’s not possible try to get representatives from every aspect of your project delivery team. Then trying playing poker! Yes it’s called Planning Poker. The idea is that using standardized values, some use Fibonacci numbers (0, ½, 1, 2, 3, 5, 8, 13, 20, 40, and 100), some use T-shirt size, to estimate the complexity of a Story (or requirement) rather than the hours it would take. You will have some sort of mapping between these values (points) and the equivalent hours. For instance, your team will know that a value “3″ means 16 hours. And for the rest of the estimation you will just focus on comparing other stories (in complexity) to that reference story. Everyone in the team will share what value they evaluate the current story at? If you don’t agree on the value it means you don’t have the same understanding, and that will triggers discussion that will have great business value, and will allow you to have shared knowledge about the project. You don’t see the value of doing so? The key is to make your estimation not decided by one person, takes in consideration all aspects of the project and remove the stress of estimating hours. There are sites such as http://www.planningpoker.com/ that allow you to do your estimation online using this technique (ideal for remote teams).
We can’t possibly cover all what it would take to become agile or to achieve agility in one blog post, but I would like to use a Diagram to attempt to explain how you can be agile while not completely ignoring all your current methodologies:
If we think about a project or product as three major phases: Envisioning, Implementation and adoption. The activities during the envisioning phase are supposed to be conducted at a high level, while during the implementation we’re supposed to be as thorough as possible. Then of course while our customers adopt (or not) our product we should continuously be getting feedback, monitoring the health of our product, evaluation its needs to scale and implementing it and finally thinking about its next evolution based on all of these factors.
I will be address each of these activities in separate blog posts over the next few months, so Stay tuned!