One or Two Day Tasks

Recently while coaching Agile to a large client in the Salt Lake City area one of the developers on one of the teams asked me why an Agile team should decompose features into one or two day units of work.  It seems, he said, the particular unit of work he was considering could not be broken down into anything smaller than 4 days.

This is a common question for groups first exposed to Agile.   Decomposing features into one or two day tasks can be challenging at first.  Here are several reasons why it is a good practice:

1. Breaking down features and large tasks into one or two day units of work forces the Agile team member to really understand the nature of the tasks.  Ambiguity is the enemy of success and large units of work really are ambiguous.

2. Smaller units of work limit the amount of risk that a particular task can adversely impact a schedule that was estimated incorrectly.

3. Decomposing work into many one or two day tasks gives the team member a win every one or two days.   They and their teammates will enjoy a sense of accomplishment more frequently, helping team morale.

4. Decomposing work in to one or two day tasks creates more transparency and precision so the team can account for completed work more accurately.  This many not be noticeable for one single work item but imagine the effect if the entire team kept work items at a non-decomposed level...too much ambiguity.

5.  Some teams I encounter hold stand-up meeting less frequently than daily.  This is a mistake.  Stand-up meetings should be held daily.  When I drill down and ask why, I typically hear that the team is reporting on the same work item the whole week.  Further questioning reveals they are not decomposing work into one or two day tasks.  When they start decomposing work into one or two day tasks then they have something new to report each day, and the stand-up meetings become more helpful.

Mike J. Berry Red Rock Research

What is the PMI-ACP (Agile Certified Practitioner)

The Project Management Institute created the PMI-ACP (Agile Certified Practitioner) in 2011 to establish credentials for someone who has been adequately trained with how to implement the Scrum Framework.  Scrum was one of the original Agile methodologies and remains by far the most popular today.

The PMI-ACP is a combination of everything you'd learn in a Certified Scrum Master class, and everything you'd lear in a Certified Product Owner class, along with advanced Risk Management techniques, some Lean concepts applicable to software development, and a few extra accessories that help Scrum scale up for larger projects, and larger group sizes.

In addition, PMI requires at least nine months of actual experience working with a Scrum team before they will aware the credential.

If you are an HR Professional, rest assured your candidate presenting with a PMI-ACP certification is slightly better equipped than one with a Scrum Master, or Product Owner, or both.

Project Management Institute Announces the PMI-ACP Certification

Agile Certified Practitioner (PMI-ACP) will be the designation of the new PMI Agile credential.  PMI has decided to recognize the prevalence and effectiveness of Agile practices within the project management community and has constructed a tangible foundation of requirements and guidelines for establishing what constitutes an Agile framework.  Perhaps we'll soon finally see an Aglie BOK?

Key dates for the PMI-ACP are as follows:

• May 2011- PMI is now accepting and reviewing applications for the PMI-ACP.

• Sep 2011 -The PMI-ACP examination will be available.

• Oct-Dec 2011 - The first PMI-ACP certifications will be awarded to successful pilot candidates


CBAP and Agile Development

I attended an excellent presentation hosted by the Northern Utah PMI Chapter, featuring Mike Sandberg, Novell's Chief Business Analysts.  Mike spoke to a room of well over 200 folks about the CBAP certification.  This is the Certified Business Analysis Professional credential that us now coming of age.Mike talked about his own experience discovering the CBAP community and about the successes and issues involved with adopting the framework.

Specifically, Mike spoke about how the PMP and CBAP roles work together.  He talked about some challenges regarding turf and terminology that sometimes befall newer groups.

Someone in the audience asked Mike about how CBAP fits in with Agile.  Mike explained that this is a common question and that the business analyst would be most suited for the Agile Product Owner role. This se to make the most sense to me, and to the others present.

Mike J. Berry

Agile Development Requires Documentation

I keep hearing horror stories from managers about how their teams that have adopted Agile Development insist there are no documented requirements necessary when using the Scrum framework.This is wrong.  

Scrum is intentionally quiet about software requirements so that groups can use what works best for them.

In our training seminars, we show groups practicing Agile how they can benefit from a high-level "strategic" use case model.  This strategic model, or High Level Analysis, is used to flush out the users, the needs of the users, and to expose any data flow components. This technique has proved quick and effective.

Mike J. Berry

Book Review: The Book of Five Rings

Recently, while attending the '09 Agile Roots conference in Salt Lake City, UT, Alistair Cockburn--the keynote speaker--referenced Miyamoto Musashi's 16th-century book called The Book of Five Rings.

I like Asian philosophy (and swords and such) so I picked up the book and read it.  The book was written in 1643 by an undefeated Japanese samurai master who was so effective he was rumoured to have spent the latter part of his career entering sword-fights purposely without a weapon.  Although meant as a battlefield manual, the book has gained popularity as a handbook for conducting business in the 21st century.

The book was translated into English by Thomas Cleary at some point and the edition I read was published in 2005.   Improperly named "The Book of Five Rings," the book is actually a compilation of five scrolls.

The Earth Scroll: Musashi talks about how a straight path levels the contours of the Earth and how various occupations provide life-improving principles.  He talks about observing patterns and learning from them.  Certainly a great primer for any business trying to get across the chasm.

The Water Scroll: Here Musashi talks about how water conforms to the shape of its container.  He suggests a separation of one's inward mind against it's outward posture, maintaining that one's control over one's mind must not be relinquished to outward circumstances.  He translates these philosophies into about 80 pages of sword fighting techniques.  An interesting modern parallel is found in Jim Collins book, Good to Great, where he talks about how the most successful companies are able to say 'No' and not be influenced by immediate but non-strategic opportunities.

The Fire Scroll: As with any book written by a 16th century samurai master, you'd expect a core discussion on combat strategy.   The fire scroll is full of combat strategies, positioning, and pre-emptive theory.  Very interesting.  Did anyone notice how Apple's announcement of the latest iPhone came about 1 day after the Palm Pre phone was officially launched--killing it's market blitz?  No coincidence there.

The Wind Scroll: The wind scroll contains a directive to study and be aware of your opponents techniques.  Translated into business speak, this means one should always study ones competitors.  Be aware of new offerings, partnerships, markets, etc. that they persue.  Emphasis is placed on observing rhythms and strategically harmonizing, or dis-harmonizing with them as appropriate.

Finally, The Emptiness Scroll:  This scroll discusses the value of escaping personal biases.  Emphasis is placed on not lingering on past situations and being able to adjust quickly to new scenarios.

Overall I found this book 'enlightening' to read.  If you like metaphors and inferences, or sword-fighting, then you will enjoy this book.

Mike J. Ber />

Two Days with Alistair Cockburn

I recently attended an Agile Development Product Owner class taught by Alistair Cockburn.  The content was excellent.  He taught us about the proper perspectives an Agile Product Owner needs to successfully interact with the project sponsors, users, and the development team.Alistair Cockburn has authored several books on Agile Development, and is one of the original signers of the Agile Manifesto.I would describe Alistair's environment as squirrely and fun.  We built user-stories out of the Rumpelstiltskin and Cinderella stories (from the original Nicht fur Kinder European versions--full of violence and gore!)We also discussed the differences between Use Cases and User Stories.  I was happy to hear he prefers Use Cases, because so do I.All class attendees had already been through the Scrum Master course, so as we executed sprints for our product backlog, it was interesting to see how many attendees actually sought the sponsors/users feedback during the iterations--without being reminded.Overall it was an educational and enjoyable experience.

Mike J. Berry

Book Review: Integrating Agile Development into the Real World

Hooray, another book on Agile Development! 

In Integrating Agile Development in the Real World, Peter Schuh explains in depth how to get your team to adopt the Agile Development Model.

Schuh covers several Agile Methodologies including the problems to watch out for during the process.

I do have to say, this book seemed like a "whole bunch of everything" and so I didn't feel, after reading it, that I was really any more informed about Agile Development.

I would recommend the book for a group just being introduced to the Agile Development Model.

Mike J Berry

Agile Development and Government Contracts

So I attended our SLC-based agile development forum yesterday.  Alistair Cockburn was there, along with some other associates from around the valley. We discussed various successes and challenges with using the Agile Development Model for software development. 

One particular topic that became a main discussion point was how to get government agencies to accept Agile Development Model contract bids. Fortunately, executives from several companies were represented in the room that use the Agile Development Model and pursue government contract work.  They gave us some insight on how to proceed. The challenge is that the Waterfall Development Model (SDLC) is the traditional project development process for government contract submissions.  They like it because it expresses a project in terms of scope, components, time-lines, and milestone dates.  All of this is measurable, so it works very well with the government procurement types.

Agile is a less structured methodology--where you build requirements and code more in a module, by module format.  These modules, called user-stories, aren't spec'd in detail until they are actually being worked on.  Because of this, milestones and time-lines for an Agile project are not as predictable.  The Agile Development Model accepts this reality, and suggests that most projects are not really so predictable anyway.

The trick with the Government is to bid your first project as a waterfall project.  Then, after you have a relationship, suggest that forthcoming projects have an Agile model. You can also submit a Waterfall project with some additional requirements listed on the contract.  ie: "Requirements base-lined at a high-level" or "Progress reported via Project Backlog" or "Prioritization by Need" or "Daily Scrum" or all of these things.

Mike J Berry