« Velocity Signature Analysis | Main | Batch Size and Velocity Fluctuations »

December 20, 2008

TrackBack

TrackBack URL for this entry:
http://www.typepad.com/services/trackback/6a00d834527c1469e20105368796fe970b

Listed below are links to weblogs that reference Lifecycle Variables:

Comments

Good job bringing the "right" brain aspect in.

I think the visuals do a good job showing how stakeholders can influence a project longer throughout the cycle vs. the dream it up front approach.

I think a lot of people mistake "agile" for speed, when really what it means is "ability to respond to change." Basically, built to change over built to last.

Where most folks struggle is I see they try to switch to time-based projects, but they don't flex scope. They think in terms of backlog burndown instead of value-delivered. Part of building a rhythm of success is being flexible in the value you deliver -- as you learn more, tune more .. and remember that the backlog is input, but value is the ultimate yardstick.

The other place folks fall down is they just do "user stories" and they don't do "system stories" or "business stories" (they mix up perspectives in a way that makes trade-offs tough.) Designing software is about trade-offs and a simple way I checkpoint is I ask to see the user stories, business stories and system stories. When it's all mixed up or just plain absent, then I know the thinking is mixed up which means I need to start digging for the likely risks. Balance is key and so is making deliberate choices.

People make better choices when you give them a better lens.

Excellent discussion. Perhaps you would also like to address scope creep? We all know scope changes cost more when executed later in a project (more rework, various penalties with the cost of change after competitive bidding, etc.) and I think the software environment has a particularly perverse outcome here. As the work progresses, the work effort becomes more esoteric to software languages and constraints, etc. with developers doing their own thing more and more, and all of the sudden every single one of them has the opportunity to put his/her own signature on the project with some simple doodad. Hey, it’s only a few extra hours of work, right? Wrong! If everybody does that, we’re over budget! Unique to software, I’m not sure the risk of scope creep ever diminishes throughout the life of the project, and incorrectly managing that agile flexibility could become a double edged sword.

Hi Joe,

Thanks for sharing your perspective. If developers were tempted to embellish or add their signature to the project then I can see that scope could increase. This has not been my recent experience, usually as the project progresses and the demo’s to the users illustrate velocity, the team wants to deliver the system as quickly as possible.

I think visibility might be the key here, when I used to develop on traditional projects there was little or no accountability to real progress or motive to finish early. Yet when we are demo’ing every week or two, progress always seems slower than desired. Everyone hears the business requests for the next piece of functionality and people work hard to simplify and deliver.

As PM I track budget, schedule, scope, risks, and quality much like anyone else, but the biggest graph on the wall is velocity. Anything not planned for an iteration earns zero points, people don’t like working on things that do not gain velocity credit, it brings the teams average per iteration down. I do not think this is why the team is so focussed, I am fortunate to work for a great team, but our metrics are simple and relevant to the real goal, getting the project finished to the satisfaction of the business and I think this helps a lot too.

Thanks for your comment, I know gold plating is a very real software project issue and one that deserves an article itself.

Best regards
Mike

I like your velocity points idea. Years ago as a project engineer, I used to do my own breakdown of the budget allocated to me, and at the end of the week if I found I had engagement hours with no budget to place them against, I knew I was in trouble! Same idea, velocity points move the ball forward, and nothing else counts, at least in this context. Great visibility and goal alignment, and yes, the issue I was referring to is scope creep due to lack of visibility.

The comments to this entry are closed.

AddThis Social Bookmark Button

Your email address:


Powered by FeedBlitz

Tracker

  • Google Analytics
Blog powered by Typepad
Member since 07/2006

May 2014

Sun Mon Tue Wed Thu Fri Sat
        1 2 3
4 5 6 7 8 9 10
11 12 13 14 15 16 17
18 19 20 21 22 23 24
25 26 27 28 29 30 31