Group items tagged

Helicopter Managers – who step in too soon to rescue thereby depriving the team to think and solve problems together.

Absentee Managers – who would not step in at all irrespective of whether the team has all the necessary skills to tackle the problem.

If the team has sufficient skills to solve the problem then give them space else ask questions to help them get unstuck. This would help in building the skills eventually.

Second getting them to understand Story Points, a seemingly meaningless measurement, seemed to be a non-starter for them.

deal hours first This is where ideal hours came to the rescue. They were far more able to wrap their heads around ideal hours i.e. if you lock the developers and testers in a room with zero interruptions, how long would it take. I figured that once they got their initial stories estimated in ideal hours down, switching to Story points will be easy as they would have established a scale of reference to compare against. This approach worked really well. They're now into their 3rd Sprint and now that they have an existing scale, whether the number is in ideal hours or story points or dog points for that matter, it really doesn't matter any more. If you're new to agile estimating, and you're having trouble coming to terms with Story Points try this first and then make the switch later.

*Please note that I'm specifically talking about productivity. Velocity is a great tool for estimating and planning and I'm not trying to change that. It's just not a good measure of productivity.

rather than asking your business experts to measure business value after delivery (difficult!), have them estimate it beforehand. Every story (or feature--keep reading) gets an estimate before it's scheduled. At the end of each iteration, add up the value estimates for the stories you completed in that iteration. This is your "value velocity."

And rather than reflecting the hours programmers work, as cost velocity does, value velocity actually reflects productivity. Remember, productivity equals output/time. Value estimates are a much better indication of output than cost estimates are.

training strategy for a significant enterprise that is contemplating an “all in” (immediate and across the entire company) enterprise scale transformation approach

for the enterprise, a combination of team-based and role-based training that would touch every practitioner is ideal

all team practitioners receive a minimum of two days of agile training, (agile team training for the each team in the enterprise)

How to make a LOT more money using agile

More frequent releases

expectations must be set for releases to be smaller but still have significant marketable value.  It also means managing scope for smaller releases so the value can actually be delivered to meet the expectations.  If we make the assumption these two pre-requisites can be handled, then we can also assume faster releases are possible.  Yes, I know, releasing software is expensive, requires other groups, etc.  For now, let’s assume all of those costs are negligible compared to the potential results and see where we end up.

The executive makes a “vendor” or external “coach” responsible for the transition If you have handled the first risk and have defined success and success metrics, you likely will not find a vendor who will base his payment on your metrics.  After all, the metrics likely call for less project failure rate, faster response times, etc.  You probably can’t measure these things in less than a year if you really want objective metrics and not one optimized for short-term results at the expense of the longer term.  A vendor might want: # of people trained % of teams using an “agile” project management tool # of teams with an embedded “agile champion” # of successful iterations It is really easy to accomplish the above metrics and still not make any material change in the organization.  I have worked with a client that did something similar to the above.  Most of the teams starting using some new Scrummy project management web application for project tracking.  They declared that monthly status meetings were now iterations.  They declared a member of the team to be the Scrummaster (and sent that person to training).  Overall, the same organizational problems persisted.  Vendors cannot produce real change in an organization unless the organizations executive leadership alters the culture in a meaningful way.