Agile, People, Project Management

Agile Project Characteristics – Two Controversial Factors

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!

Re-posted from http://bornagainagilist.wordpress.com

About Terry Bunio

Terry Bunio has worked for Protegra for 14+ years because of the professionalism, people, and culture. Terry started as a software developer and found his technical calling in Data Architecture. Terry has helped to create Enterprise Operational Data Stores and Data Warehouses for the Financial and Insurance industries. Along the way Terry discovered that he enjoys helping to build teams, grow client trust and encourage individual career growth, completing project deliverables, and helping to guide solutions. It seems that some people like to call that Project Management. As a practical Data Modeller and Project Manager, Terry is known to challenge assumptions and strive to strike the balance between the theoretical and real world approaches for both Data Modelling and Agile. Terry considers himself a born again agilist as Agile implemented according to the Lean Principles has made him once again enjoy Software Development and believe in what can be accomplished. Terry is a fan of Agile implemented according to the Lean Principles, the Green Bay Packers, Winnipeg Jets, Operational Data Stores, 4th Normal Form, and asking why

Discussion

No comments yet.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: