In my last post I listed the Agile Dozen Characteristics and Practices that I felt were critical on all projects. In that list though, there were two characteristics that I did not expect myself and that may raise the eyebrows of Agile purists when mentioned. Before there is discussion on all the factors and I present the experience reports, I thought it would be of value to discuss the following two characteristics:
- Developer to Designer Ratio
- Team meeting estimates
1) Developer to Designer Ratio
Where to start on this one. The first immediately apparent item is that there is a difference between developers and designers. Yes, I would say that there is room for both of these roles and that I believe that perhaps all of the design and development activities can’t be pulled by any member of the team. I know this principle is tantamount to heresy in some of the Agile circles, but I believe that context is everything and there are no absolutes. Based upon the problem domain, team composition and solution complexity, there may be a requirement for a role that owns the solution vision at a very high level. Now this does not imply the creation of detailed requirements and architects and designers defining exactly what developers need to code, but merely implies that there is a role that provides the overall vision of the solution at a high level and then works with the entire team as they flesh out user stories to ensure that the solution remains cohesive and consistent. This designer can then also provide leadership in the architecting the automated test suite as well.
This has worked well on our projects. I’d really like to hear back from others on this concept…
2) Team meeting estimates
This was the other characteristic that I thought would be somewhat controversial. Now I firmly believe in Planning Poker and collaborative estimating techniques, but at the end of the day, no matter how the estimates have been created, a successful project must deliver to the estimates that they have made. 😐 Whether this is a Traditional Project where estimates are defined at the task level through to an Agile project where User Stories and tasks are defined in points and through planning poker, eventually the execution must somewhat match the plan. (now matter how defined or loose the plan is) If this continues to happen through many iterations, the clients will get concerned and possible business plans that depend on the iteration outcomes may be compromised. To demand 100% meeting of the estimates is not feasible, but if the project consistently deliver less than 50% of the plan then some action needs to be taken. (Which could be to just be less optimistic and committing to less)
What do people think of these two more traditional characteristics? I’d love to hear feedback!