Lately, I have been struggling with some of the management side of projects. The concepts of estimates, deadlines and work completed do not always align in ways that make people happy. The problems with estimates and deadlines had pushed me closer to agile methods before, but not all projects can be run in the manner you want them run if you are dealing with a client. So, I was having problems reconciling all of this when I saw a post from Matt Block asking Is Working Software Enough? Matt highlights an interesting problem:
The team seemed very concerned about achieving a high velocity. They showed reluctance to slow down and spend more time in “grooming” and planning. Previously, in an effort to optimize velocity and reach “hyper-productivity” the team had capped the amount of time the product owner could use for grooming at 5% of the sprint. However, I was starting to think that really wasn’t enough time. It was forcing a lot of important design decisions off onto myself and the UX designer without getting the opportunity to explore different options and get feedback from the development team. There may be situations where this setup works well, however I have a very smart and talented development team and I felt that spending more time grooming and brainstorming potential solutions to the problems on the backlog with the team prior to designing the solution would, in the end, result in a much better product.
Basically, the development team was so focused on the amount of work to be completed in a specified amount of time that they forgot the goal of producing a better product. This type of stress normally comes from the project manager, they were worried about the calendar. When did developers start worrying about the calendar?
Part of the problem is that developers are required to estimate project tasks. In traditional or waterfall projects, these estimates are given in hours or days. With agile methods, developers are often asked to only provide a relative difficulty of the task. For relative difficulty, I have seen various measures like points (based on the fibonacci sequence), t-shirt sizes (S, M, L, XL), donuts, beans and many others. The problem with relative measures is that they do not relate to the calendar directly. In the end, most clients want to know when a selected feature set will be complete, and sometimes there are other calendar pressures like launching before a conference or staying aligned with some business cycle (like monthly accounting). Why is agile used in these scenarios? Because agile methods are related to getting a working product. You implement a feature during a sprint, instead of various people working on tasks that are not entirely related to each other except due to related due dates.
Another problem with estimates is that they are typically not related to the developer doing the work. One way that this issue has been avoided is to have the developer scheduled to do the work, to estimate the task. However, we all know that schedules and reality do not always see eye to eye, so you may have a developer working on tasks that they did not estimate. Invariably, there are differences in the actual hours needed to complete the task and the original estimate. Some of this is due to the estimate-developer mismatch, but sometimes it is just a matter of expectations. In most projects, developers are allocated as 100% utilization for the project. In reality, this is almost never true. During a week, the developer will at least have project status meetings or scrums. In many agile methods, a daily 15 minute scrum is required, which means that the developer already loses 1.25 hours for the week. If you add in the time to process emails, about 30 minutes per day, you have lost 3.75 hours or almost 10% of your week. This does not include any other types of distractions, and the best you can expect is 90% utilization from the team members.
So, we already have the fact that estimates are likely flawed, the project plan is possibly flawed due to lower than expected utilization, and the potential for a business driven deadline, all pulling for attention when looking at the project schedule. Agile methods have attempted to remove the first two issues, by using relative difficulty as the estimate, but that often gets translated to effort hours in the long term in order to determine an approximate date when the project will be complete. Obviously, we could talk this problem in circles, because without data, there is no proof of what could happen or at least data showing trends of what has happened.
In agile methods, the concept of velocity has tried to make use of the trend of previous sprints’ work completed. However, this trend tends to become a target instead of just a trend based on data. Developers try to increase their velocity, because it makes them feel productive, and management likes to see the velocity remain stable or even increase over the life of a project. This is the problem with data, it makes people feel like they can make decisions about the project, while they are forgetting about the main goal of developing a solid, functional product.
What if the only metric that was measured was total points delivered? Or we measure points delivered as a percentage of the required points for the minimum viable product? This is what we really want to know. Is the product done? If not, how much work needs to be done until the product is minimally ready for launch?