TrainingConferencesAbout UsContact UsAdvertiseSQE.comRSS Feed

StickyMinds.com: brain food for building better software

Log In
 Clarify Your Search Criteria

Tips on Using Our Search Feature(s)
 
StickyMinds.com Home
ResourcesTopicsCommunityPowerPassBlogs
Home  >  Detail: Are You Making Progress or Spinning Your Wheels?



A StickyMinds.com Original
Article Picture
Are You Making Progress or Spinning Your Wheels?

By Johanna Rothman

Send This Content to a FriendGet a Short Link to This ContentPrint This ContentSee User Comments About This Content

Summary: While managing a long project, it's easy to lose track of progress. And, when that happens, how do you even know whether you're still making progress? In this article, Johanna Rothman offers suggestions to help you take your project one step at a time and keep it under control.


ThoughtWorks
When I coach managers or leads, one of the most frequent questions I hear is: "How do I know I'm making progress?" Typically, the manager or lead is working on a long project or a long initiative, such as transitioning to agile, and it can be difficult to know if you are making progress or spinning your wheels.

Plan in Small Chunks
No matter what project you are working on, plan in small chunks. Sure, keep the vision of the end product in mind, but know that you can only do so much in a given time period and plan what you can do for the short term.

One way to do this is with rolling-wave planning. As an example, suppose you want to plan a large Web application release. You would note your major milestones, such as "UI walkthrough for shopping interface," "financial integration with financials package," or "limited release to trusted users," in addition to "release for general public." Now, take the first milestone and ask yourself and the project team, what do we need to do—in detail—to get to that milestone?

I like making rolling-wave plans on sticky notes on the wall, not in Gantt charts. I ask people to plan in inch pebbles—one- or two-day tasks that are either done or not done. With inch pebbles, people see the details of what they have to do, and it's easier to see if anyone has trouble with a task.

With inch-pebble sticky notes, if anyone on the project team sees a problem and needs to change something quickly, it's obvious what the effects are. They can ask the people affected to work with them on the change.

If you're agile, you already do something like this when you take a number of items off the product backlog and commit to completing them inside an iteration. The difference is that an iteration is timeboxed, and your rolling-wave plan doesn't have to be.

If you want to optimize your rolling-wave plan, ask the team to plan in small chunks inside a timebox. "How much of this can we accomplish in the next two weeks?" That helps people reduce the size of their work items and focus on what "done" means for that milestone.

When you get to the end of a timebox, you can see your progress—even if you're not using agile iterations, because you have met a milestone on your rolling-wave plan. Once you finish one wave of work, you plan the next. If you're like me, you start planning the next wave before you've finished this one—hence, the "rolling wave." I normally have three to four weeks of detailed inch pebbles, so everyone on the team knows where we are and what's next. We plan only a week's worth every week. Replanning is quick and easy, because we're not planning a lot at any one time.

Finish Small Chunks
Once you start planning in small chunks and replanning frequently, you realize that you need to finish small chunks, so your replanning makes sense.

One of the problems of a lot of work in process is that you are not completing work and making progress on the project. For example, if you're working on "UI walkthrough for shopping interface" you don't want to start work on "financial integration with financials package" until the UI walkthrough work is done.

When you ask people to complete just one task or a series of related tasks for one major milestone, everyone focuses on that one milestone. When people pay attention to just one feature or feature area, they are likely to complete work faster or know what's preventing them from completing the work.

The problem is that work in progress is not a measure of completion. If you're halfway through a project and have everything half-started, are you half done? You can't tell. But, if you're halfway through a project and have half the deliverables completed, are you half done? You could be half done—maybe a little more or less—but you know with certainty how long it took you complete this work.

The more work in progress you have, the more it feels as if you are spinning your wheels.

Measure Progress
It's really difficult to know how long a project will take, because projects are full of work we've never done before. So, we guess at the estimates—a reasonable thing to do.

But, what if you could gather data from your estimates about your completed work and use that to measure progress and look forward? When you keep a rolling-wave plan and use inch pebbles to break the work down, you have a small enough effort to return to the original estimate and say, "Well, we thought this would take us a couple of days. It took three days. Do we have more tasks like this in our wave? Maybe we want to make them three days." Or, if you get lucky, maybe your work takes less time.

If you and your team always underestimate, try breaking the tasks down into smaller chunks, so you can see where the time goes. Instead of defining two- or three-day tasks, break work down into half-day or one-day tasks. That will make your schedule more accurate for this project and make it easier to see where you are spinning your wheels.

One of my clients realized that developers spent hours every day waiting for their builds to complete. Originally, everyone just accepted this problem as "the way things work here." But, when they chunked down their tasks and self-imposed pressure to complete work, they realized they no longer were willing to accept the long build time. In the time it took them to deliver one feature, they also reworked the build system so that they eliminated the circularities and made the build much faster. Now, they could finish features faster and with less aggravation.

Measuring your estimates against actuals only works on completed work. You can try to measure this on development or testing alone, but, until the whole feature works, you won't know how much more development or testing you will need to do and, therefore, whether your measurement is accurate.

Check Yourself
If you're wondering if you are making progress or spinning your wheels, check how your project is organized: Are you planning in small chunks and completing work? Are you measuring how long it took you to finish work?

You'll start making progress before you know it.


About the Author
Johanna Rothman is a management consultant and a regular StickyMinds.com and Better Software magazine columnist. Johanna is the author of the recently published Manage Your Project Portfolio: Increase Your Capacity and Finish More Projects, Manage It! Modern, Your Guide to Modern, Pragmatic Project Management--winner of the 2008 Jolt Productivity Award, as well as the coauthor of Behind Closed Doors and author of Hiring the Best Knowledge Workers, Techies & Nerds. She is a host of the Amplifying Your Effectiveness Conference. Johanna has presented at STAREAST, STARWEST, the Better Software Conference & EXPO, and Applications of Software Measurement & Management conferences. You can reach her at jr@jrothman.com or by visiting www.jrothman.com.

Back to Top
 

StickyMinds.com Weekly Column From 3/29/2010 

Member Comments
Add Your CommentExpand Comments
 
Comment:    
by bilal marshall 4/22/2010

There is an old Chineese saying that"Little medication is better many times then a ton in one time"
SO i believe that if you divide the things in many small parts
Its always easy to manage.
ACCORDING TO THE OLD MUSLIM SCIENTIST ALKHARWARZAMI THAT BREAK THE THINGS IN MANY SMALL PARTS AND on this simple rule our whole software industry is based.
But where there is a comfort in this style of management,on the other hand it has MUCH responsibility arises to manage these small parts other wise whole puzzle will be ruined.

Thanks

Author's Response:
4/22/2010    
Bilal, yes, if you break something into many small parts, you do have the responsibility shepherd all those parts into a whole. Each team member has responsibility for his/her part, and the PM can coordinate risks.

 
 
Comment:    
by Keith Collyer 4/15/2010

This is excellent advice. I would add that we need to distinguish between planning and scheduling. The "plan", even in an agile environment, should identify the overall goal and have some breakdown of what has to be done to reach that goal. In order to create the inch pebbles, you need to carry on the breakdown until the level where one or two day tasks are meaningful. This gives you the schedule, at least for the next couple of weeks. BUT, you don't need to do this for the whole project. I think this is where a lot of the more myopic agilists fall down, they think a plan is something complete, rigid and unchanging, when it should be...Read On

Author's Response:
4/22/2010    
Keith, yes, the idea is to plan only what you need to!

 
Back to Top



 
Ads By Google
What's This?
 
 



Home   |   Resources   |   Topics   |   Community   |   PowerPass



© 2010 StickyMinds.com. All rights reserved.
StickyMinds.com is a division of Software Quality Engineering.
Privacy Policy    Terms & Conditions    Link to StickyMinds.com    Feedback


ThoughtWorks

Rally Software




Agile Development Practices 

STARWEST