Delivery teams manage and deliver value supported by the tool user stories. These teams tell stories about who, what, why, and acceptability using standard form, “As a <persona>, I want <capability> so that <delivered value> occurs,” and behavior acceptance form, “Given < context>, when <action occurs>, then < consequence >.” These stories form the foundation of repeatable delivery and management of value. While these forms support delivery team conversations well, they are inadequate to support the richer conversation needed by executives to manage investment and value. What forms the basis of these stories? How do we tell stories about delivering…read more
LeadingAgile takes the mystery out of leading an agile transformation. We can explain why you may have struggled with agile in the past and what you can do differently next time to get better results. We believe in safe, incremental, pragmatic change and we are passionate about improving the business drivers executives repeatedly tell us are behind their desire to adopt agile in the first place.
Agile tends to focus on adaptability, but predictability is most often cited as the reason for an agile transformation.
As organizations scale, product quality often suffers. Agile focuses on quality from requirements through implementation.
Many organizations struggle with 18 month delivery cycles. Agile helps your team accelerate time to market and revenue.
Cost savings are tough to promise, but agile can help make sure you are only spending money on the features most likely to generate revenue.
the road map
Executives hire us because we have a credible point of view and a plan. We don’t start with culture and we don’t leave it up to you to figure out everything by yourself. We work with your team to develop a scaled agile delivery model specific to your organization, a pilot strategy to exercise the model and validate any assumptions, and a transformation plan for leading and sustaining change.
We offer a package of coaching, training, and staff augmentation services wrapped within our cutting edge framework for leading large scale enterprise agile transformations. Our Compass and Our Roadmap make all the difference in how those services are brought to bear within your organization. Our team is always focused on business outcomes and leading sustainable change.
Take a look around and see what we have to offer.learn more
let your journey begin...
If you’re ready to get started, or even if you’d just like more information, the first step is to reach out and let us know you’d like to talk. Our team will setup a quick call to learn more about your organization and what you’d like to accomplish. Next we’ll put you on the phone with Mike or Dennis to dive a little deeper. If we both think there is an opportunity to help, next step is to get in a room and talk.
latest field notes
The LeadingAgile Blog
Did We Build the Right Product? And, Did We Build the Product Right? Acceptance criteria are an important yet, in my experience, often overlooked or undervalued aspect of the iterative planning process. Acceptance criteria are super important because projects succeed or fail based on the ability of the team to meet their customers documented and perceived acceptance criteria. When we clearly define acceptance criteria up front, we avoid surprises at the end of a sprint, or release, and ensure a higher level of customer satisfaction. In other words we’re able to answer these two important questions: Did we build the…read more
This is part three in a series on estimating. Part one was “Don’t Estimate Software Defects” and Part two was “Don’t Estimate Spikes”. I don’t estimate stories in sprint planning. Nor do I re-estimate stories in sprint planning. I estimate stories in a separate estimating meeting and usually at least a couple sprints in advance, if not more. There are a few reasons why (re)estimating during sprint planning is a dangerous practice: In sprint planning, we are thinking at a lower level of detail with far greater knowledge about the story, the code base and the system than we had…read more
Flow: Nice Work If You Can Get It A number of years ago I worked with an EDI (Electronic Data Interchange) team that was troubled with a large level of WIP (Work In Process) and slow movement of work through a system with many external dependencies. Work was regularly blocked waiting for unresponsive peers from the other companies. Work would languish in partially completed states and eventually be abandoned, either because the business relationship changed or the team gave up and turned their attention towards more likely prospects. Looked like great place to apply kanban These sounded like great problems…read more
First, I would like to credit Eric Ries in his 2010 Web 2.0 speech for giving me the idea for these awesome graphics. If you have never seen the speech then I highly recommend the version found on YouTube. I have always admired people with creative slides who can capture ideas with elegant simplicity. Since my artistic ability peaked in the first grade, the images in this post demonstrate my foray into abstract expressionism and hopefully convey the point of why we in software need iterative planning. Unknown Problem | Unknown Solution Most software changes start life in the state…read more