ART OF SCRUM: Scalability and The Achieve Approach

Posted: January 7, 2008 in Art of Scrum
Tags: , , , , , , , , , , , , , , ,

At the 2007 Achieve Summit, Gary Markowitz presented The Achieve Approach. This is — from my point of view as a ScrumMaster — essentially a scalable series of questions that needs to be asked and acted upon for each and every thing that an Achieve Team does, no matter how large or small the chore is. To quote Chuck D from Public Enemy, “here come the drums.”

The Achieve Approach consists of four items:

  1. Discover
  2. Architect
  3. Develop
  4. Deploy (or Launch)

If you look at these items as a series of questions that are to be asked of every Task, Story, Project, Sprint, or other work that we do at Achieve, we have a framework to insure that the Team is thinking through a problem, rather than rushing to Development and missing critical bits of information that later crop up as impediments. Even though it may seem — at first blush — a little ridiculous to ask these questions for every Task that a Team creates for a Product Owner’s Story, the scalability of the Achieve Approach will make this a valuable exercise.

Scalability means that a routine (in this case, examining the four parts of the Achieve Approach) is suited for both large and small applications, and that it is nimble enough to apply equally in micro- and macro-environments. The Approach seems to be built for a Project: these four steps are “phases” or “stages” that are dealt with in order to be able to produce the needed information to move to the next stage or phase. This type of approach will be derided by hard-core Scrum practitioners as “waterfall methodology.” Just the fact that you have to complete Discovery before you move on to Architecture sends CSMs into a foaming-at-the-mouth frenzy. “This is not Agile! Waterfall is for lumbering oafs! We don’t need no stinking Discovery!” Although there is some concrete value in having a phased approach, Scrum itself loathes this sort of Six Sigma PM thinking because of the perceived waste of time that comes from doing classical due diligence with rigid phases.

That is not what the Achieve Approach is about. The scalability of the Approach is what keeps it Agile. At a Project level, there may be specific phases that Achieve walks through in order to insure that when we hit the Development phase, we have all of the information needed to successfully Develop. At the Scrum level, it is much more of an Agile process where we simply ask the four questions on a per-Story or per-Task basis in order to bubble up impediments before they interrupt the Sprint. Ingraining these four steps into our everyday thinking should help us ask the questions that need to be asked in order to provide accurate estimates, the correct number of tasks, and bite-sized chunks of work to insure that we can deliver quality and timely releases to our Product Owners within the timebox of the Sprint.

Here’s a real-world example of the Achieve Approach working in a Sprint in question format:

STORY: As a [client developer] I want to be able to [easily theme the four verticals on my website] in order to [implement the new Rotato without making it look like it is a new part of the website]

REQUIREMENTS: [simple functional specifications and use test cases as provided by the Product Owner] — this is to be addressed in a later Art of Scrum

TASK IT OUT: Normally, the Team would start throwing out sticky notes with tasks on them in order to try to meet all of the requirements that were laid out by the Product Owner within the Story; here is where, as a ScrumMaster, I am going to ask for the Achieve Approach to be considered.

  • Scrum it up and bounce out all of the Tasks needed to complete the Story
  • Arrange the Tasks in the order that is needed to complete the Story
  • Keep in mind the Team’s resources, and if Tasks can be done in parallel — this is important for Agility
  • Have the Team consider the four elements of the Achieve Approach: even if it takes 15 minutes extra per phase (mostly Discovery and Architecture I am guessing) it is massively important to think these things through at the Planning Scrum so that estimates are accurate and that the Team does not incur Technological Debt
  • Perhaps each Task can be labeled with the Achieve Approach steps in order to insure none are missed

START SPRINTING: If an impediment occurs, again run through the four elements and see where the impediment was missed, if applicable

DELIVER THE GOODS: Make your Product Owner feel like a Hero by giving them a Product that they cannot wait to demo to their Stakeholders

I would like to see Achieve be able to understand Projects, Stories, and Tasks — especially with their resulting impediments — categorized into Discovery, Architecture, Development, and Deployment so that we could understand better where additional work is being generated by not thoroughly planning ahead of time. Although Scrum is designed to deal quickly with problems as they arise, I still feel that the best way to avoid problems is to think them through in the first place. Perhaps we as a company are not doing enough Discovery. It may be that we are arrogantly trying to Architect on the fly. It could be a common misconception that Launching (or Deploying) is a simple push-button process.

This is a rather long blog (hooray for Nyquil), but the upshot is this: learn it, love it, repeat it: Discover, Architect, Develop, Deploy. This mantra will become a saving grace as we find it reminding us of the path to quality code and products.

Comments
  1. […] ART OF SCRUM: Scalability and The Achieve Approach […]

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 )

Google+ photo

You are commenting using your Google+ 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 )

w

Connecting to %s