Blog : June 2006

Friday, June 02, 2006

Brad the Variator

Just a quick post to link to some great stuff from Brad Appleton recently, Six Sigma and Good versus Bad Variation, Cost, Cruft and Constraints, Feedback, Flow and Friction, and I just loved this little piece on Business Agility Defined. Go add Brad to your blogroll or RSS feed reader if he isn’t already there. He’s got some of the best content out there for the software engineering management field.

Posted by David on 06/02 at 03:21 AM Agile • (0) TrackbacksPermalink

Manage Value Creation not Effort Expended

So why did I make a fuss over a post from Jon Kern yesterday? Why is that the definition of a feature in FDD is so important and why is it that we don’t want tasks tracked as features?

Put simply, managing tasks really isn’t that interesting or useful from a management perspective or a customer perspective. Managing value creation provides greater leverage and greater risk management. By not managing tasks the team is empowered to self-organize and perform the work in the way that best suits them. They can delay task definition until the last responsible moment and execute tasks in any order. There is no need to estimate tasks. All that is required is to define them locally. It’s empowering. It’s liberating. And most of all it removes any opportunity for micro-management. HOWEVER, I’m about to explain the occasions where we are interested in tasks and why some types of tasks can be important.

Figure 1.

Figure 1 shows the elements involved in performing a task. Advocates of TOC and Critical Chain will see that I have extended Eli Goldratt’s definition by the addition of a Cleanup step at the end. Cleanup is a term that also encompasses the concept of handoff to the next stage in the chain or the consumer at the end of the chain. Setup and Cleanup together can be considered the transaction costs associated with the performing of the task.

Imagine you are going to paint a fence(the agile way). Setup involves changing clothes, preparing the brushes, the moving the tools and paint from the garage to the starting location and so forth. Cleanup involves cleaning the brushes, fixing the lid on the paint pot, returning everything to the garage, washing up, and changing clothes again. What are the queuing and waiting times?

Figure 2.

Figure 2 helps to explain what queue and wait times are through the concept of batching tasks. In a batch, we perform the setup only once and the cleanup only once. Batching is more efficient because it spreads the transaction costs of performing a task across many tasks. However, batching gives us queuing and waiting times. Imagine each task here is painting a section of fence. While section one is being painted section 2 must queue as does section 3 and section 4. Once completed sections must wait (physically to dry) before they can be handed off to the customer (and payment can be made).

Figure 3.

Now imagine we take this concept and apply it to project management of value creation. Now we have a batch of features to be developed as shown in Figure 3. There are actually only three tasks of interest to management in the batch: the setup; the value creation of features; and the cleanup. All the tasks associated with creating the features are not significant to management. WE DON’T CARE ABOUT THOSE TASKS! Honestly, we don’t. Hence, we only need to track features in the feature set or chief programmer work package. During task 2, we manage value creation not effort expended.

However, we do care about the setup and cleanup tasks. These are the overhead and transaction costs to building the customer value captured in the features. Also the setup is probably a pre-requisite to the feature creation and any delays in setup will cause the schedule to slip. In Lean they call this idea “changeover” or “setup” and one of the key ideas in Lean is to minimize the time it takes to perform setups. By doing so the transaction costs (or waste known as muda) are minimized.

Hence, when people hear me recite the mantra that we should be managing features and not tasks that isn’t totally true. It is true to the extent that if setup and cleanup are trivial then we don’t care. However, on projects where setup, cleanup and handoff (installation or deployment) are not trivial then we do care about these. So a project plan should reflect tasks for those, while the development should have only one task per batch or iteration. The contents of that task should be broken out as value work items e.g. Features in FDD. Technorati tag: Agile, David+Anderson, FDD, Lean

 

Posted by David on 06/02 at 02:24 AM AgileLeanShiftAltCtrlPermalink

Thursday, June 01, 2006

Just what _is_ a Feature?

Jon Kern adds another definitive piece to the FDD literature giving some clear guidance on what is and is not a feature in FDD. Technorati tag: Agile, David+Anderson, Jon+Kern, FDD

Posted by David on 06/01 at 01:34 AM (0) TrackbacksPermalink
Page 3 of 3 pages  <  1 2 3