Group items tagged

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.

Coaches help teams learn Agile practices get from 'Agile seems to be something we should do' to 'we are practicing Agile development and succeeding by regularly delivering business value'.

ncreasingly there are reports of initial success followed by failures with Agile adoption.

I believe that there is a problem to how current Agile coaches - especially external ones (such as the author) - have traditionally performed their jobs. In fact, I think we are part of the problem

Scrum in a nutshell Split your organization into small, cross-functional, self-organizing teams. Split your work into a list of small, concrete deliverables. Assign someone to be responsible for that list and to sort the list by priority. The implementation team estimates the relative size of each item. Split time into short fixed-length iterations (usually 1 – 4 weeks), with potentially shippable code demonstrated after each iteration. Optimize the release plan and update priorities in collaboration with the customer, based on insights gained by inspecting the release after each iteration. Optimize the process by having a retrospective after each iteration. For more details check out “Scrum and XP from the Trenches”. The book is a free read online. I know the author, he’s a nice guy :o) http://www.crisp.se/ScrumAndXpFromTheTrenches.html Kanban in a nutshell Visualize the workflow Split the work into pieces, write each item on a card and put on the wall Use named columns to illustrate where each item is in the workflow Limit WIP (work in progress) – assign explicit limits to how many items may be in progress at each workflow state. Measure the lead time (average time to complete one item, sometimes called “cycle time”), optimize the process to make lead time as small and predictable as possible.

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.