Posts Tagged “planning”

The solution sheets practice can be used to quickly and accurately define a previously undocumented feature, user story or initiative. One solution sheet can generate all the detail and agreement required to begin development on a surprisingly large chunk of work. I’ve used this technique to quick start projects, to bid on big fixed cost initiatives, and to provide a sensible alternative to otherwise onerous documentation requirements. Slap a set of solution sheets together to create a ream of USEFUL documentation. Read the rest of this entry »

Comments No Comments »

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! Read the rest of this entry »

Comments No Comments »

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. Read the rest of this entry »

Comments No Comments »

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. Read the rest of this entry »

Comments No Comments »

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. Read the rest of this entry »

Comments 1 Comment »

This morning I met with a new team that has asked me to help them put some process around how they plan, manage and commit to work. This was our second meeting and the team is completely new to agile practices and techniques, so we started by shaping some of their work into features and breaking those features into tasks. Read the rest of this entry »

Comments No Comments »