Agile Experience Reports – The Agile Dozen

My main purpose for this BLOG was to try and share some personal Agile Experience Reports and get discussions going with others on what worked and what didn’t work. My first challenge was to create a framework where some sense could be made of my personal project results.

When I compiled the list of Agile practices that I feel are important to projects, I was worried about how any patterns could emerge with that many factors. And I was right. I had compiled a list of 42 characteristics and practices that covered the Project Team, Project Planning, Execution, Requirement Gathering, and Development activities on the project.

What I did next was look at those 42 characteristics and practices and whittle it down to 5-10 Agile practices that I believe are really key to project success. Unfortunately, I could not get it below 12. So I was stuck with the Agile Dozen.

Next was the step to validate that those practices were indeed a true indication of project success. And through the projects reviewed so far, they have held.

For my upcoming Agile Experience Reports I’ll share how well we followed all 42 characteristics and practices on a rating scale of 1-5. But I want to caution that I am not viewing this rating as:

  • An Agile scorecard
  • An Agile Maturity
  • An Agile report card

I think those constructs cause teams to focus on the wrong things. Namely, getting a good grade rather than project success, client success, and continuous improvement. I created this framework to help myself understand what practices really contributed most to project and client success and help me to improve and focus on the right practices.

In the next BLOG post I’ll discuss in details the Agile Dozen and my rationale for including them. For now, here is the list of the Agile Dozen..

  • Team Experience (Technical & Domain)
  • Developer to Designer Ratio
  • Embedded Engaged Client
  • Team Continuity
  • Team Estimating
  • Automated Tests
  • Team meeting estimates
  • Daily stand ups
  • Retrospectives
  • Iterative Delivery
  • Epics, User Stories and Product Backlog
  • Continuous Integration

Then I’ll provide some context on where these characteristics existed and practices actually worked on projects and share lessons learned.

I hope you will find this interesting. I tried to find information like this when I was starting out and I could not find it very easily.

Advertisement

Author: Terry Bunio

Terry Bunio is passionate about his work as the Manager of the Project Management Office at the University of Manitoba. Terry oversees the governance on Information Technology projects to make sure the most important projects are being worked on in a consistent and effective way. Terry also provides leadership on the customized Project Methodology that is followed. The Project Methodology is a equal mix of Prince2, Agile, Traditional, and Business Value. Terry strives to bring Brutal Visibility, Eliminating Information islands, Right Sizing Documentation, Promoting Collaboration and Role-Based Non-Consensus, and short Feedback Loops to Minimize Inventory to the Agile Project Management Office. As a fan of pragmatic Agile, Terry always tries to determine if we can deliver value as soon as possible through iterations. As a practical Project Manager, Terry is known to challenge assumptions and strive to strike the balance between the theoretical and real world approaches for both Traditional and Agile approaches. Terry is a fan of AWE (Agile With Estimates), the Green Bay Packers, Winnipeg Jets, and asking why?

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 )

Facebook photo

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

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.

%d bloggers like this: