Group items matching

in title, tags, annotations or url

One of the developers had checked in some code that failed the regression tests. The application, on which the company had spent considerable time, money and effort, was now in an uncertain state. It wasn't behaving as expected. In the past, this type of bug usually wasn't discovered for months. Usually, it wasn't discovered until the System Integration Testing cycle got underway. For this project, that wasn't scheduled for another 6 months.

In the past, this bug would have lingered in the code for 6 months before anyone even realized it was a problem

. The light had gone off only 6 minutes after the code had been committed. Notice: not 6 months...but 6 minutes!

Identify the technical leaders within projects; those that are “self-driven to produce quality results on time … combine technical ability with enough people skills …are trusted and respected by both their managers and fellow developers, are determined to make the team succeed, and usually live the work.” (Chief programmers, Chapter 2:  A Practical Guide to FDD).

Sell them the vision: if you cannot sell these people on the benefits to them, their colleagues and the organization of the new way of working then something is wrong

Provide in-depth training and on-going coaching. It is better to have a single lead person trained in-depth who can coach his teammates through the basics than to have the whole team trained on the basics with no-one on the team to turn to when the basics are not enough.

*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.

Institute an agile transition team, and have the agile PMO play a significant role on that team. If you are starting on the journey, establishing an agile transition team can be a critical factor in your success. The agile transition team plans and implements the strategy for the organization’s agile transition (using a backlog, iterations, planning meetings, retrospectives and, in general, responding to change) This group monitors and communicates results throughout the organization, and is responsible for removing organizational level impediments. The PMO representative can act as ScrumMaster for the agile transition team. Members should be leaders representing different departments and functions that are impacted by the agile transition. For example, having leaders from development, QA, product development and the PMO is an excellent practice.

Establish a “Meta Scrum” that is tasked with mapping projects and features to corporate strategy. As part of optimizing the whole, it is important for there to be a big picture view across products and features. In general, product managers are tasked with defining, prioritizing and communicating the vision and features for their products. When you have a program that encompasses multiple products with multiple product owners and project teams, keeping everything in line with the corporate vision can sometimes be overlooked.   Unlike the Scrum of Scrums--which is tactical, i.e. focused on execution--the Meta Scrum is focused on the strategic planning and decisions guiding the program or programs as a whole. Establishing a Meta Scrum with the PMO representative acting as ScrumMaster to plan and facilitate meetings (as well as reporting and tracking decisions and action items) can add significant value in having a program able to rapidly respond to change while staying true to the corporate strategy and objectives.

I like using story points to establish the velocity of individual teams. From a program point of view, however, story points are difficult to use across multiple teams. The nut there is that one team’s story point is not equivalent to another team’s story point. To crack that nut, I use agileEVM to “normalize” to standard project management metrics like the Cost Performance Index and the Schedule Performance Index, as well as the Estimate At Complete in integrated dollars. These metrics can be aggregated across teams to establish progress against the plan for the entire program.

A problem with the basic index-card task board is that there is nothing to prevent you from accumulating a big pile of work in process. Time-boxing, by its nature, sets a bound on how much WIP that can be, but it can still allow much more than would be desirable.

then you need another mechanism to regulate the “money supply.” In our case, we simply write the quantity of kanban in circulation on the task board, and allocate new cards according to that limit.

You might have a simple principle like: prefer completing work to starting new work, or you might express that as a rule that says: try to work on only one item at a time, but if you are blocked, then you can work on a second item, but no more. In our example, that rule gives us an effective WIP limit of 6.