Plan and Deliver by Peter Schuh  A traditional-sounding name for a blog about agile processes, but let's face it - that's the stuff our customers grade us on.
Do we work with them to identify, assess, and plan functionality in a practical and predictable manner? And do we communicate on the details, report fictionless status, and deliver the goods when we said we would? This blog is about using agile practices and techniques to plan and deliver in real world environnents.
Get this RSS Feed -  - Subscribe to Plan and Deliver by Email
|
|
Saturday, 04 August 2007 |
This blog is the result of a great question asked in the comments of my last blog entry. Quinn asks:
"Of course we get side-lined by an occasional production support task or an overly optimistic lead developer that bites off more than we can chew.... I feel that it's a huge slap in the face when you are programming like a ferret and don't get to 1 or 2 stories out of 25-30 in a 2 week iteration and the PM or IT Director is "disappointed" that you have carry over.... And thus I bring the question to you--what is the TRUE measure of success?"
Great question!
Tags:
Click to add your tags...,
|
|
|
Tuesday, 24 July 2007 |
|
There is a simple equation that is the basis for most of the planning and tracking calculations I use with projects and teams. One permutation of this equation--for calculating Velocity--is well-known to many Agilists. This common permutation can be expressed as: v=e/t or Velocity (v) = Effort (e) / Time (t).
Casual readers beware. As advertised above, this blog entry uses math.
Tags:
Click to add your tags...,
|
|
|
Thursday, 25 January 2007 |
Whether you are an individual team member or a department manager, just about all of us--at one time or another--have been asked to produce an estimated work plan for some project or deliverable. And just about all of us-—at one time or another--have opened up Excel or Project, thrown in ten or a hundred tasks, slapped absolute-guess-estimates on each task, scrutinized the total until feeling comfortable with it, published the plan to get that manager or sponsor off our back, then moved on to actually doing the work, and never looked at that plan ever again.
This is not planning. This is storytelling. And it can kill your project. All of us have done it with small stuff. I’ve done it with small stuff. But some of us--I'd wager--have done it with 10 million dollar projects. And storytelling killed those projects, too.
Tags:
Click to add your tags...,
|
|
|
Thursday, 18 January 2007 |
|
The teams that I work with have two very important rules around task ownership. First, regardless of the number of people doing work on a task, each task should only have one person's name on it. Second, regardless of who is actually doing the work, the task should always belong to an active member of the team.
Tags:
Click to add your tags...,
|
|
|
Friday, 05 January 2007 |
|
Sometimes agile teams have to draft and deliver scope, discovery, requirements or high-level design documentation. I don't want to get into the how or why in this blog entry. Rather, I want to spend the entry discussing how these documents can be shaped as features and broken into discrete, estimated tasks so they can be prioritized, managed and tracked like any other development work in an agile process.
Tags:
Click to add your tags...,
|
|
|
Thursday, 28 December 2006 |
|
When transitioning a new team to a highly iterative planning process (where we plan and complete work in weekly Task Cycles) one question I always have to ask is: "When do we want to start and end the weekly Test Cycle?" The answer I almost always get is, "Monday and Friday," to which I typically reply: "How about Wednesday?"
Tags:
Click to add your tags...,
|
|
|
Friday, 15 December 2006 |
|
I’ve been working with a couple of new teams this week that
are transitioning to an agilish (yes, I did say agilish) process. What has
really struck me this week is how the entire software development industry is
still marooned on Gilligan’s Island when it comes to drafting a plan that
simply and effectively communicates what we are about to develop. Yes we’ve
been on the island forty years. Yes, the whole industry … well, percentage-wise
just about everyone if we cut off the decimal places and round up. No, I don’t
know where everyone fits or how they eat.
Tags:
Click to add your tags...,
|
|
|
Sunday, 22 October 2006 |
|
A team that I have been working with for some time has one project (we’ll call it Project X) that has had a problem getting traction over the last three months. What do I mean by “getting traction”? Specifically, on an ongoing basis the team plans the amount of work required to meet delivery commitments but consistently completes significantly less work than it plans.
Tags:
Click to add your tags...,
|
|
|
Friday, 13 October 2006 |
|
One could argue that Traditional Management arose from a concerted attempt by executives and directors to get reliable budget forecasts, staffing requirements, delivery date forecasts and quality commitments from development teams. They need this information to manage the company's budget, growth, strategic direction and overall product delivery. When they don't get this information--or don't trust what they get-- executives and directors institute rigid and often uncompromising processes on their development staff to wrest this data from their teams and to approve and steer projects.
Tags:
Click to add your tags...,
|
|
|
|
Blogs 
