Group items tagged

team that had some problems getting their process right

their velocity was decreasing and spirits were low. Luckily we managed to change our process by changing some basic Scrum practices and replacing some of them with Lean practices, inspired by the new Kanban articles and presentations. Productivity is now higher than ever and we can now focus on what really matters: product quality and customer satisfaction.

one major issue: getting things done. The major symptom was the frustration of management and the team with the project. The first 3-week time box (sprint) ending with about 30% (!) of all features still in progress, when, of course, they should all have been done and ready for shipment.

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

The Roadmap consists of a series of planned release dates, each of which has a theme and a prioritized feature set.

While it is a simple thing mechanically to represent the Roadmap, figuring out the content for anything beyond the next release is another matter entirely. The topic of what else the team plans to ship and when can be a fascinating and contentious topic in agile

the easiest way to think about the Roadmap is that it is an output, rather than an input to the Release Planning process.

I do believe for Scrum to work beyond the team you need more than Scrum

what to add to Scrum making it more effective when it won't readily work

lack of team agility is not always the major impediment to Enterprise Agility

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.

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.