Agile Works So Why Do Large Enterprises Fail So Often?Steve Elliott
schedule 2 years agoSold Out!
We would all agree that Agile is mainstream, agile is the future and that Agile DOES work. So why then do we see so many failed or moderately successful large scale transformations? The answer is complex but there are many things that can be done to improve your odds of success.
In this talk we will explore 7 proven methods to help you see bottlenecks, clear land mines and drive better results. The seven points we will explore include:
- Methods to scale up collaboration (above the team level) using agile principals
- New methods to scale up estimation by combining standard methods like WSJF, Points, T-Shirts, Team Weeks with Monte Carlo what-if simulations.
- Objectives as work packages
- Value streams in a three tier model with a RACI twist
- Agile Ghantt-ification and other scaled-up visualizations
- The effects of WIP discipline at the portfolio level
- How calculate capitalization regardless of team methods (cycle time, points, hours)
Agile Release Planning with Scrum
Release Planning is not part of Scrum, but Releases still need to be managed. How do we “promise dates” and manage to them without losing our agility? This seems like a hard problem – and it is – but in this talk I’ll show you how to do it. According to standard Project Management principles, the Release Manager does two things: she produces a Release Plan, and she keeps this plan in balance with the Realities of Development throughout the Release. A bad Release Manager tries to change Reality to match the Plan, and a good Release Manager knows that she must change the Plan to match Reality. This balancing the Plan with Reality is an inherently agile process… and is an example of the basic “contract” between Development and Management – that Development will provide good information and data to Management, and that Management will make good decisions based on that information and data.
Come let me show how you can have good Agile Release Management in your Organization.
Advanced Discussion of StoryPoints for Project Management
We know that StoryPoints are "a relative measure of size that can be applied to Stories and Epics." Beyond this simple statement there is not much about StoryPoints that we can all agree on - teams and organizations are free to estimate and use StoryPoints as they see fit. Well, I want to use them to aid in Project (not Sprint) Management, and in this talk I present a way to define StoryPoints for this purpose. Come and hear words like "Ideal Effort", "Intrinsic Difficulty", "Function Points", and "Earned Value", and how StoryPoints become the basic currency for Release budgeting and metrics.
Many Scrum/XP Teams are using StoryPoints to size their Stories, and they are using StoryPoints to be a relative measure of “actual effort”. This is a horrible mistake if you also want to use the StoryPoints to help manage a Project, and has led to many issues, including:
- The “my StoryPoint is not your StoryPoint” mantra that many people have, which just gives up on the notion of normalizing StoryPoints across Teams; and
- The “we need to resize our Stories constantly” issue, which leads to consternation on the part of Project Managers.
One of the biggest issues, called the “grandmother of all issues” by Ken Schwaber, is that the creation of technical debt will gobble up our projects. By using StoryPoints as a surrogate for actual effort, I see many projects resize things constantly in order to account for the additional effort needed to produce the same Scope. This confusion of Size and Effort is a serious killer of projects.
The Project Management discipline has struggled with the differences between Size (used to manage Scope) and Effort (used to manage Cost) for decades, resulting in discussions about Earned Value, Function Points, and so on. This is a difficult problem. In my opinion, Scrum (with its incremental development) actually makes it easier to solve this problem.
This is what the talk is about.