Practical Agile Blog

Practical Agile Blog

Wednesday, March 26, 2014

The Agile Success Algorithm

  1. 1.
    a process or set of rules to be followed in calculations or other problem-solving operations, esp. 

Those of you reading this are more than familiar that Agile is all the rage. Executives like to say that their organization is going "Agile". They throw out terms like Scrum and Kanban without truly understanding what they are getting involved in.

In order for Agile to be implemented successfully, I have created the following simple algorithm. Embrace Change + Learn from Mistakes = Agile Implementation Success.
Agile Success Algorithm

Input 1 = Embrace Change

The primary risk with implementing Agile involves the ability your organization to embrace change. You need to answer the following questions about your organization's culture and your leadership team before you can successfully implement Agile:

How does you organization respond to change?

When was the last time your organization underwent any major changes? Have they been through major layoffs? Have they introduced new leadership? How long have they been in business? Have there been major new product introductions? Have they been acquired or merged? 

How did these changes go? In this case, past performance often dictates future performance. If your company struggles with change, then they will have trouble introducing Agile. Agile introduces change in so many ways:
  • Changes in roles, title and responsibilities. Just look at the roles in Scrum, since it is currently the most popular Agile method being implemented. How easy is it for your organization to adopt these roles?
    • The Scrum Master??? How many managers or project managers do you know who truly understand the concept of servant leadership? How many organizations allow for management positions that do not have direct reports? To truly be successful with Scrum, a Scrum Master role has to be created from scratch, not just assigned to an existing function.
    • Product Owner? Organizations that have a mature product manager function can transition easily to this, but many organization manage product related decisions by committee with a team of business analysts. The role of a truly empowered Product Owner is difficult for many companies to swallow.
    • The Scrum Team????? A self-organizing team is the foundation of Scrum and of Agile in general. How many organization actually foster this? How many middle manager's jobs would be eliminated if an organization becomes successful with this? How many under performers would be exposed in this model? This is the most difficult, yet most critical change required. 
  • Changes to process.
    • No analysis or  business requirements phase? No Gantt charts? No 12 month project plan? Traditional project management was just formalized at many organization in the last decade. Formal PMOs have been rolled out, massive enterprise tracking tools implemented and teams of project managers hired to create and maintain documentation. Can your organization tolerate getting rid of all the process you just implemented?

Input 2 = Learn from Mistakes

Only a company or leadership team that has experienced project failures can truly appreciate and support an Agile implementation. These failures may have come in many different ways:
  • The project came in too late to meet the market opportunity.
  • The budget changes were so excessive that the project was either terminated to deemed a total failure.
  • The customer rejected the product because it was "not what they were expecting."
The list goes on and on....The Agile Manifesto was not crafted by grad students developing a thesis. It was developed by people who were clear that the way we were working wasn't working. Many people, like myself, have become Agile evangelists only after suffering through one or more project failures. One of the major downsides with introducing Agile to the "younger" workforce is that they don't truly appreciate how much more fun and enjoyable it is to work on an Agile project. Give them one month of using project time-sheets and hourly tracking in an ERP tool and they will start to see the light. 

Result = Agile Implementation Success!

The benefits of Agile are self-evident for those who have lived through traditional project failures and are willing to change. There are hundreds of successful case studies and stories of successful Agile implementation, but implementation failures are becoming more and more common. Becoming "Agile" is not just using the term "Agile", it is a transformation that will effect your entire organization.

Wednesday, March 19, 2014

Running an Effective Sprint Planning Meeting

To start with, for a Sprint Planning meeting to be truly Scrum, it adheres to the following guidelines outlined in the Scrum Guide. In summary, for a one month Sprint it has a time-box of 8 hours. It is typically performed on the first day of the Sprint and is intended to answer the following topic questions each in a 4 hour session.
  • Topic 1: What can we as a Team accomplish?
  • Topic 2: How can we accomplish it?
Sprint Planning Topic One:

An effective Sprint Planning meeting assumes that the Product Owner is prepared with an objective for the Sprint. They should not have a specific goal, since this will limit the creativity of the Team, but they should have a general expectation of what they would like to see accomplished. The Product Owner should have a high-level release plan based upon the product vision.
This release plan should contain what might be accomplished from the Product Backlog each Sprint. It is the Product Owner's responsibility to maintain and order the Backlog based upon this release plan.

During the first 4 hours, the Product owner should discuss their objective and the Development team will select those items from the Product Backlog that they believe they can accomplish in the coming Sprint. This becomes the "Sprint Backlog".  Once that is accomplished, the Product Owner, Development Team and Scrum Master agree on the Sprint Goal.
User Story Card - Front Side

If you are using the user story approach, in this session you will select the user story, prioritize the user story and then estimate its size using story points. You would be completing the front side of the user story card.

Sprint Planning Topic Two:

In the second part of the Sprint Planning Meeting, the primary objective is determine how the Development Team will achieve "Done" with the Sprint Backlog. This session sometimes also called a Design Session. Often times technical experts and SMEs are invited to this session to determine how best to deliver a certain piece of functionality from the Sprint Backlog.  If a Backlog items becomes more complex than expected, the development team will work with the Product Owner to refine the Sprint Backlog.

Under the user story approach, this session is also used to document many of the tasks associated with the user story and update the story point estimate from the the first session.

Ultimately, the Development Team will make a commitment to the Product Owner that they will self-organize and accomplish the Sprint Goal based upon the selected Sprint Backlog.

Boston Agile Training provides in-depth training on Sprint Planning and Users Stories in their Scrum Master and Product Owner trainings.

If you have any questions, please contact me at or find me on Twitter @scrumdan.

Dan Tousignant, PSM, CSPO, PMI-ACP