Ballot Debris

Thoughts on Agile Management, Leadership and Software Engineering

Using the ‘Release’ Concept in Agile

clock January 18, 2010 11:42 by author Chad Albrecht

I’m spending quite a bit of time these days helping organizations implement Agile methodologies.  As such I hear the same set of questions and see the same set of issues over and over again.  One of the issues I see quite often is the “long sprint.”  To explain what I mean by this I’ll use a hypothetical conversation with a Team Lead new to Agile.

 

Team Lead: “How do you deal with the fact sprint planning and reviews take so long?”

Me: “How long is long?”

Team Lead: “Sometimes a week!”

Me: “How long are your sprints?”

Team Lead: “Usually 3-6 weeks.”

Me: “How did you determine that 3-6 weeks was a good length?”

Team Lead: “Because we couldn’t spend 2 weeks out of every month not coding!  We use longer Sprints to avoid spending so much time in review and planning.”

 

For those of you that are experienced in Agile, you should see a few problems here.  For now, let’s just focus on the “long sprint” concept.  The “long sprint” seems to manifest in organizations that are always sprinting.  First off, this is in direct conflict with the name sprint.  Sprints should be just that, a focused exertion of energy over a short period of time…2-3 weeks max.  So how do we solve our Team Lead’s issue with spending too much time in review and planning and not enough time writing code?  Enter the “Release.”

A Release is a means of building larger blocks of functionality in multiple Sprints. (usually 4-6)  Some Agile methodologies (XP) implement this concept directly, others do not. (Scrum)  There are many reasons to use the concept of a Release, a select few are:

  • Some features just might not fit into a two week Sprint.
  • Allow team to perform work in parallel to development.  In general team members can do work other than sitting in sprint review and planning sessions.  This is because these sessions are lighter weight and involve fewer people.  You simply review implemented sprint functionality ensuring it meets the needs of the stakeholder and grab the next chunk of the prioritized Product Backlog. (ok, a bit more than that, but you get the point) These two sessions should not take more than 3 days.
  • Reduce the overhead of delivering software to production every 2 weeks.
  • Reduce the information overload caused by releasing every 2 weeks.
  • Define a delivery pace more inline with that of the organization. (the rope in the Drum-Buffer-Rope of Throughput Accounting)

The next logical question is “Do we create a Release Backlog?”  I agree with Mike Cohn in this case and would say no.  I do however, use the concept of a Release Plan or Release Roadmap.  According to Mike a Release Plan contains:

  • Graph showing historical velocity.
  • Prioritized Product Backlog. (including some big user stories, "epics")
  • A predicted range of where we will finish. This should be either a date-range for a fixed-scope project or a functionality-range.
  • Personnel assumptions. (Team members and availability)
  • Velocity assumptions. ("we’ll go about half speed during December because of holidays and time off")

I would also add the following:

  • A Vision Statement.  (“We want to add the shopping cart functionality and connect it to PayPal”)
  • Estimated Release Value as I discuss here.

Using the concept of a Release in Agile organizations can be an extremely effective way to increase efficiency through the elimination of waste.  I will try to post more on this topic in the future.  As always, let me know your thoughts.

Further Reading:

Extreme Programming Release Planning:

http://www.extremeprogramming.org/rules/planninggame.html

Mike Cohn on Release Planning:

http://blog.mountaingoatsoftware.com/why-do-release-planning

Mike Cohn on why there should not be a release backlog:

http://blog.mountaingoatsoftware.com/why-there-should-not-be-a-release-backlog

Kelly Waters on Release Planning:

http://www.agile-software-development.com/2008/02/agile-release-planning.html



PMBOK, Agile & TOC: Initiating the Project

clock June 8, 2009 13:06 by author Chad Albrecht

There are many facets to initiating a project according to the PMBOK.  Questions like, “Should we do this project?” and “Will we be able to deliver results?” all need to be answered.  To answer these questions we need to run the core process of this step, Scope Initiation.  The Scope Initiation process has, as do most PMBOK processes, Inputs, Tools and Techniques and Outputs.  Inputs include things like the product or service description, statement of work, strategic plan and historical information.  The Tools and Techniques include things like project selection methods and expert judgment. Finally, the Outputs are the Project Charter and the Preliminary Project Scope Statement.  I will examine the relevance of these documents in Agile Management one at a time.  Additionally, given the fractal nature of Agile development, this step can be used at the release level or at the individual iteration level.

The Project Charter is used to authorize the project and document its business need.  In Agile this step is very important as it helps create a unifying vision for the product or service.  It is easy in an Agile environment to lose track of the original intent, this document can help remind the team of what and why of the project.

The Project Scope Statement defines the deliverable requirements, boundaries of the product or service, methods of acceptance, etc.  This statement is present either implicitly or explicitly in most modern Agile methodologies and is usually represented by one or more artifact.

Agile correlation for these two documents are shown below.

 

Scrum

XP

FDD

Project Charter

Release and/or Sprint Goal

Vision statement

Informal vision statement as part of overall model

Project Scope Statement

Release and/or Sprint Backlog

Release and Iteration Plan with User Stories

Release and/or Iteration Feature List



PMBOK, Agile & TOC: The Project Lifecycle and Process Groups

clock May 5, 2009 08:36 by author Chad Albrecht

In my last article I established that we have a shot at using PMBOK tools in Agile Management.  Today I want to take a look at how the PMBOK Process Groups map to Agile. As any PMP will tell you the five phases of a project (according to PMI) are:

  1. Initiating
  2. Planning
  3. Executing
  4. Controlling
  5. Closing

While I will examine each in detail, let’s take a high level look at the above and compare it to one of the more prevalent Agile methodologies, Scrum.

Figure 1 - PMBOK Project Management Process Groups


Figure 2 - Simplified Scrum Process


From Figures 1&2 you the correlation between the PMBOK Process Groups and the steps of Scrum should be obvious.  For clarity, I am defining a project in terms of Scrum as a Release.  Some organizations may choose to define the project as the Sprint itself for the purpose of controlling products or services that don’t have the concept of a Release.


Here is the Process Group alignment matrix for some of the Agile Methodologies:

 

 

 

Scrum

 

 

 

XP

 

 

 

FDD

 

 

 

Initiating

 

 

 

Release Planning & Product Backlog

Release Planning & User Stories

Develop Overall Model & Build Feature List

Planning

 

 

 

Sprint Planning

Iteration Planning

Plan by Feature

Executing

 

 

 

Sprint

Development

Design & Build by Feature

Controlling

 

 

 

Sprint Backlog & Sprint Burndown

Project Velocity

Milestones

Closing

 

 

 

Release

Release

Release (Build)

So again we see that PMBOK concepts hold up as we examine Agile in more detail.



About me...

bio_headshot

I am a leader, entrepreneur, software engineer, husband, father, pilot and athlete. Over the last 17 years of my career I have built numerous successful companies and software development teams. This amazing journey has taken me all over the world and allowed me to work in a number of diverse industries. I have had the privilege to meet and work with thousands of unique and talented people. As you will see from my blog I am a strong believer in Agile techniques and the Kaizen corporate culture. I am always looking to grow myself, my teams and the companies I am partnered with.

Contact me... View Chad Albrecht's profile on LinkedIn Follow Chad Albrecht on Twitter Subscribe to this blog

Professional Scrum Trainer

Professional Scrum Developer Professional Scrum Master I Professional Scrum Master II Professional Product Owner I Professional Product Owner II Certified ScrumMaster

MCTS

Calendar

<<  September 2014  >>
MoTuWeThFrSaSu
25262728293031
1234567
891011121314
15161718192021
22232425262728
293012345

View posts in large calendar

Blogroll

Download OPML file OPML

Sign in