Some Thoughts (and Some Frameworks) on Agile

Posted on April 4, 2011 Updated on September 3, 2014

I had an interesting coffee meeting today with Gregg Wheeler with Solstice Consulting.  Solstice is increasingly becoming known as a solid Agile partner, both in applying the principles to their work and also in helping technology teams apply these principles to their own methodologies.  They’re hosting a workshop in April – find more information here.

Gregg and I discussed how Agile is now viewed not as the label to “keep things the same” as was the fad with many technologists in the 1990’s.  Now, both technology AND business teams are seeing the value in applying these principles that allow the business-technology partnership to quickly adapt to and exploit business opportunities before the competition.  Below are a few frameworks that are worth posting, reading and if applicable at YOUR shop, are worth swiping.  All of them are broken down into that most magical of numbers – three:

THREE ROLES ON THE AGILE TEAM

1. Product Owner: Plain and simple, this is the business partner who has the business need and decision-making authority.
2. Scrum Master: The “project manager” or team lead, whose primary function is to remove obstacles to progress and to coordinate discussions, decisions and where necessary, activities.
3. Project Team: The people doing the work.

THREE ARTIFACTS FOR THE AGILE TEAM

1. Product Backlog: The prioritized “wish list” of enhancements, features, maintenance items, etc., that are required to meet the businesses needs.
2. Sprint Backlog: The next level of granularity, consisting of a breakdown by task with ETC (estimate to complete)
3. Burn-down Chart: The breakdown of tasks against the available hours.  For example, if a given Agile cycle is two weeks or X hours, the burn-down chart shows how the available time in the cycle will be consumed by the tasks within the Sprint Backlog.

THREE TYPES OF AGILE TEAM MEETINGS

1. Sprint Planning: Breaking down the Sprint Backlog into the requirements that will ultimately drive the tasks.
2. Daily Scrum: Led by the Scrum Master; these are typically 5-10 minute “stand up meetings” where the Scrum Master asks three key questions: 1.) What did you do YESTERDAY?; 2.) What is planned for TODAY?; and 3.) What OBSTACLES to progress need to be removed (the role of the Scrum Master, as noted above).
3. Demo and Retrospective: The team meets with the Product Owner to demo the work to date and to perform a brief postmortem to identify lessons learned and action items with SINGLE owners (a single point of accountability) and with DUE DATES (e.g., not “TBD”)

I think it’s worth repeating the three questions that are at the heart of the Daily Scrum.  Again – they are:

1. What did the team to yesterday?
2. What will the team do today?
3. What obstacles must be removed to ensure team success?

I really like the idea of the 5-10 minute “stand up” meeting.  I first read about these in Patrick Lencioni’s ‘Death by Meeting’ – a book I highly recommend as it’s full of good info and written in Lencioni’s parable-style that makes for a better read in my opinion.

Agile is a solid set of principles that, when employed by the right type of team, can not only provide exceptional business value to the “business” part of the business-technology partnership, but also creates a fun and rewarding working environment!

© 2011, Mark E. Calabrese

Automating PMO Workflow

Posted on February 3, 2011 Updated on May 25, 2011

Lately, I’ve noticed that a lot of organizations are seriously considering purchasing tools to automate their PMO workflow.  While there are certainly some good products out there worth considering, I think it’s important to avoid the “rush to automation” as a solution to all problems.  Automation doesn’t solve every problem, so it’s always a good idea to initially approach the problem using a version of the following framework BEFORE committing company resources to the purchase, installation and integration of a PMO or project workflow tool:

• Understand the Current State: Clearly define the current project workflow.  Make sure you not only document and understand the PUBLISHED workflow, but how it actually works in practice.  If there’s a gap between the processes and practices in the current state, things will only get more complicated as you try to move to a defined future state.
• Understand, Clarify and Document the Future State: Make sure that the desired future state is clearly understood and documented.  This will become important when you sell the idea internally, as well as when you begin to gather and document requirements.  Make sure that there is agreement on the future state among all stakeholders – business AND technology.  EVERYONE has to agree on what “tomorrow” looks like or you’ll be setting yourself up for another host of interesting complications.
• Gap Analysis – Part I: Perform a gap analysis of the Current and Future states and DOCUMENT WHAT YOU FIND.  This will serve two purposes, as I’ll point out below.
• Analyze and Improve the Current State Workflow: Before building out your requirements, looking up and talking to vendors or scheduling demos, stop for a moment and determine whether your existing workflow is optimal.  Can some of the problems be resolved by simply improving the existing workflow and avoiding the expense of finding and implementing an automated solution?  As advisors to our business partners on how they invest their IT dollars, it is incumbent upon us to make sure that the PMO workflow we intend to automate is optimal in the CURRENT STATE.  Avoid the idea that “we’ll improve the workflow when we implement the new solution”.  You may find that optimizing the current solution will be enough to meet the business’ needs.
• Implement the Improvements: Once you’ve identified ways to optimize the existing workflow, implement the changes.  Make sure you’ve captured any metrics as a baseline so that you can test the improvements to see if they deliver the desired changes.  If they do, then you’ve resolved a business operations issue at minimal cost.  If the changes do NOT yield the desired results, at minimum you’ve not only improved the existing process that will be automated, but you’ve shown your business partners that you treat their IT investment as YOUR investment, too.
• Gap Analysis – Part II: Now that you’ve optimized the existing workflow, perform the gap analysis between the new and improved Current State with the Future State.  This should result in a set of RFP-ready requirements that can be used in vendor selection and as a basis for the implementation and integration effort.

Remember that as IT leaders, our mission is to deliver products and services that meet or exceed our partner’s business needs and to ensure that we advise them such that they NEVER waste their IT investment.

© 2011 – Mark E. Calabrese