Managing the Impossible with an Agile Budget
Last Updated on Tuesday, 1 April 2014 08:13 Written by Isaac Hogue Tuesday, 1 April 2014 08:13
The Agile Budget
Release planning is without a doubt one of the most challenging responsibilities for agile teams… at least that’s what I’ve experienced both personally and while coaching enterprises through transformations.
Most teams are working to deliver solutions where the question of “what will I get” at the end of a release can not be left open ended. Furthermore, these teams don’t have an unlimited capacity. They are working within what appears to be a constrained iron triangle, cost, time and scope are all fixed. Mike Cottmeyer’s recent blog about the agile home builder, discusses this challenge from the perspective of establishing a categorized budget.
It is an approach that I’ve seen work on several occasions. The process is pretty straight forward, not easy… but also not complex
Here’s a script that I like to use to help move teams from “this is impossible” to, “hey I think we can deliver!”
Before determining how much of the budget should be spent on features, its important for the team to understand the goal of the eventual release. To help with this, I usually encourage the team to form of a mock press release, announcing their successful release to the world. Typically this includes key areas or attributes of the release that have made the release impactful to the reader. These are now key success areas for the release
Establishing your Budget Categories
Each of these key success areas start to emerge as high-level categories within the context of a releases budget that can be used to help focus initial scope conversations. From here the key stakeholders can allocate their budget across each of the category areas.
Quick sidebar, the asset that is available for budgeting is usually the delivery system’s planning velocity.
Keep your Eye On the Ball (successful release, budget available)
Now that budget categories are set, the teams need to start working through their release plans and refining their needs for the “right” implementation based on the budget available. There are many methods for going about this process; but, by far my goto method starts with high-level acceptance criteria for each category, or feature area, that can be clarified through a mix of example user journeys or system interactions. The funds available to each of the categories should be brought down and further applied to each of these so that the planning team remembers to keep its eye on the ball. A successful release will need to both (1) deliver the functionality needed, and (2) live within the budget that is available.
This is key, without a focus on the budget available (cost) most teams will struggle to limit the scope of a release until its too late. Early budget constraints help to drive out scope that is not critical to the success of a release.
What do you think, what are your favorite ways to vary scope to successfully deliver on previous market commitments? For more on this topic, take a look at an earlier blog about calculating the budget, in cost, for agile teams.
Product Vision Tools Part 1: The Product Vision Board
Last Updated on Wednesday, 16 April 2014 02:09 Written by Chris Spagnuolo Tuesday, 11 March 2014 07:52
Creating a Clear Product Vision
Product vision is super important to the success of your product. I know, its just a simple statement, right? How much impact can it really have? More than you can imagine. A product vision gives us the direction and focus we need to deliver something, anything, that will ultimately solve the problems of a customer segment and deliver value to both your business and to your customer. If it is well-crafted and well-communicated, product vision should permeate everything you do, from business models and product roadmaps to the stories in your backlog and how you execute them.
Here’s a test for you. Take a minute and scribble down the vision statement for the product you’re currently work on. Now here’s another test. Have the co-workers who sit near you do the same without discussing it. Compare notes. Do your notes match? Are some notes still blank? Are any of the notes the same? Do the same test across your organization. If your notes match, you can stop reading now…well, not really, but you obviously work on a product with a clear vision. If you have blank notes or notes that vary widely, read on.
Test number two. When you finally find your product’s vision statement on the company website or wiki, how does it read to you? Is it delusional? Cloudy? Confusing? Dismissive? Heady? Wordy? Lengthy? Boring? Uninspiring? Generic? Maybe a little of all of those.
Don’t feel bad. Some of the best organizations in the world have difficulty using words to define what it is they do, who it is they serve, and what success looks like to them. You are NOT alone, trust me. But you don’t have to wallow in the words of your vision statement much longer. There are some very simple tools that can help you clearly define your product and use it to drive your product’s business model, your product roadmaps, your product-market fit experiments, and your backlogs for your teams. In this post and posts to follow, we’ll introduce several of these tools and discuss how they can help you create a vision that resonates with customers and the people who you work with, and help you constantly align the work you do with the vision you have created.
Defining Your Initial Product Vision
When most organizations develop their vision statements, they default to some standard template. One of the more popular templates comes from Geoffrey Moore. While I love Geoffrey Moore and consider him a mentor, I think his traditional vision template leads to rather unexceptional vision statements that all sound the same: “For blah blah blah customer who needs blah blah blah, our blah product is a blah blah blah that will blah blah blah. Unlike our competitors (insert list of competitors that are usually not competitors) our product blah blah blah blah blah…”
You’ve heard vision statements like this before. Somehow, they hit all the right points, but more often than not, every time I see this template used, the vision statement gets very long winded and all I can hear is “blah, blah, blah…”
What I’d rather have is a simple, concise, visual representation of the vision that I can understand and relate to. I’d rather see an inspiring overarching vision that I can get excited about and say “Yes! That’s where I want to go!”. I’d like some detail too…about who it is we’re building for, what problems they have, and how our idea solves that problem. I might even want some info on how our company gets value from what we build, but really I’m more interested in who we are addressing and what their problems are.
Enter Roman Pichler’s super simple Product Vision Board. It’s the tool I turn to most often when I start working with teams to define their product vision. It simple, concise, AND visual. Check it out:
Let’s walk through the sections and see what we need to think about.
Steps to Create a Product Vision
First, we need to craft a vision statement. Here’s some simple advice on what to write in this box: Say a lot in just a few words. Pick your words wisely. Don’t be generic. Describe a long-term vision but don’t be overly restrictive. Clear, concise. Calls people to action. Oh, and if you took the two tests above with your co-workers, they’d all remember it…or at least a pretty close flavor of it.
Need some examples? Try something like Innocent Drinks’ vision statement: “Make natural, delicious food and drink that helps people live well and die old”. Too simple for you? Want something a little more “corporate”? Here is Ikea’s: “To create a better everyday life for the many people, we shall offer a wide range of well-designed, functional home furnishing products at prices so low that as many people as possible will be able to afford them.” A little wordy for me, but it does get the point across.
After you’ve wordsmithed your awesome, clear, thoughtful, inspiring vision statement (and if you have, share it here, I’d love to read them), write it in the box, pat yourself on the back, high-five your teammates, and move forward one space.
The next four boxes should be easier. Mostly because they are all hypotheses, or guesses at what you think the right answer is. The first box “Target Group” is all about our customer hypothesis. Who do we believe we are trying to serve? Typically, for a new product, or even existing products, we’re looking at the earlyvangelists. We’re looking for customers who clearly identify with our vision. Notice I did say our solution? We want customers who to buy into our vision. They fall in love with the idea, not the solution. So try that out and see if turns out to be different than the customers you currently view as your target segment. Got it? Good, write one sentence in the box that simply describes these people, pat yourself on the back, high-five your teammates, and move forward one space.
The next box, “Needs”, addresses our problem hypothesis. What do we think the problems of our customers are? Again, don’t fit the problem to your solution. Empathize with your customers and truly try to understand what their problem is. Not what you want it to be. When you think you have a good problem hypothesis, write it in the box in clear, simple terms, pat yourself on the back, high-five your teammates, and move forward one space.
Box number four: “Product”. This is your solution hypothesis. Based on the customers you described, and the problem you identified, what is the minimal thing you can do/build to solve that problem and make them smile? Again, this isn’t rocket science. It’s a guess. First guess. It doesn’t have to be right. It just has to be something you can build, test, and see if your customers smile. Got it? Awesome! Write it in the box in clear, simple terms, pat yourself on the back, high-five your teammates, and move forward one space. You are nearing the end of this game.
Last box: “Value”. This box vexes me a bit and to be honest, I don’t usually fill it in the first time around. So first timers, leave it blank. It’s OK. The world will not end if you do not define the value to your business right now. Why? Because so far, the other boxes have been guesses. Hypotheses need to be tested, validated. Chances are very high that the things you wrote in those boxes will change as soon as you start using the tool we’ll be covering in our next post, the Validation Board.
So for now, feel good that you’ve defined an initial product vision and you are ready to start testing in the real world. Pat yourself on the back, high-five your teammates and grab a beer…or maybe one of Innocent Drinks’ product, they might make you live well and die old.
For specific information on designing teams check out Product Owner Team Design Considerations.Learn More
We Need a Shared Understanding
Last Updated on Friday, 27 September 2013 11:12 Written by Derek Huether Friday, 27 September 2013 11:12
Earlier this week, I facilitated a backlog refinement meeting. In the past, the team was used to the analysts to complete all of the requirements in advance. The delivery team would then execute on those requirements. The problem, of course, was no shared understanding.
We came into the meeting with everyone agreeing they were on the same page. That was true for about 15 minutes. The more we talked, the more they realized they were looking at things from individual perspectives.
At the beginning of the meeting, we had less than 10 user stories, from an analyst’s perspective. By the end of the meeting, we had a prioritized backlog with over 100 user stories at different levels of granularity. They understand that it’s not perfect. But, it’s a start. For the first time, developers and testers were engaged at the beginning of the process. At LeadingAgile, we call this the Product Owner team. When the highest priority stories get to a “ready” state, they will be pulled into a delivery team’s queue. Until then, we need to answer some of the more complicated questions, mitigate risk, and achieve that shared understanding.
Image Source: Based on a hand drawn image from PictofigoLearn More
Agile Release Planning Kick-Starts Agile Adoption
Last Updated on Tuesday, 4 February 2014 11:37 Written by Doug Brophy Wednesday, 3 July 2013 07:00
Organizations just starting out in their Agile adoption are eager to begin seeing results. After proper Agile teams have been formed and trained in the basics of Agile, they are ready to begin practicing. But what is the first step in your Agile adoption, where should they start? Agile Release Planning is the answer.
Agile Adoption : Release Planning
Agile Release Planning enables teams to speed up their Agile adoption. It brings the stakeholders together in a working session focused on developing the software requirements and plans to develop the software incrementally and iteratively. Risks, issues, dependencies and assumptions are identified and addressed in the planning.
This kick-starts the Agile adoption practices, enables teams to begin delivering results quickly, and sets them up for success with the release. A recent coaching engagement provided a good example of this.
An Agile development team had been formed to build the next generation platform for a Resource and Operational Planning tool suite. A new platform with a single, common database and user interface was needed to better integrate and present the product offerings, in line with the product vision and roadmap. The legacy platform had become overly burdened with technical debt after years of ad hoc development, and became costly to support and extend.
The new team was in its forming stage. There were conflicting views and differences in understanding of the requirements for the next generation platform. There were strong differences of opinion about what and how to leverage from the existing platform architecture and code base, which was large and complex.
Most of the new team came from the legacy platform development team. But the Product Owner (PO) and Product Manager (PM), two developers and a tester were from a different but similar product suite. The PO had recently been part of a similar platform uplift program for the other product suite, and had a developer background. As such, the PO had strong opinions about how to execute this project, including on the subject of architecture and code reuse. He strongly advocated for starting over with a new clean architecture since, for example, the existing platform had lots of business logic tightly coupled with the UI.
But the legacy development team members were very concerned about doing this. They were counting on re-using a lot of the legacy code (and architecture). In their minds, that would be the fastest way to complete the project, since they were very experienced in development of the legacy platform.
Agile Adoption : Release Planning Workshop
To overcome these issues, we held a Release Planning Workshop. Representatives from Product Management, Development, and other stakeholders in the release were in attendance. Our workshop began with an intentional focus on reviewing the business goals and associated product vision and roadmap, as a precursor to talking about architecture, epics, features, and stories. This quickly made it clear to Product Management that they were not fully prepared to discuss the platform requirements in this manner.
We were able to identify some epics/ features and stories on that first day of the workshop, but it was mostly a training exercise for the team to learn what and how we do release planning to improve their Agile adoption. With this new understanding, Product Management asked for a week to go “do their homework” to fully prepare for another try at Agile release planning.
Agile Adoption : Outcomes
We reconvened a week later for “take two” of release planning. This time we made rapid progress and accomplished the goals of release planning. Notable outcomes include the following.
1) Development finally understood and accepted that Product Management wanted a new, simplified, de-coupled architecture – not just a refactoring of the existing architecture. This would be the basis for a normalization of how data entry, processing, and presentation would be done across products/ features running on the new, common platform.
2) Delivery date would be negotiable as the project progressed. Development had been assuming that there would be a fixed due date 9-12 months later, which they would be pressured to accept, even though it would be high risk to commit to a delivery date that far out. But Product Management did not have a fixed due date in mind. Instead, getting the new platform they envisioned was the priority for them. They could be flexible about the final completion date.
3) Product Management did want to see incremental milestones of progress, and fortunately, that is exactly what Agile release planning is designed to provide. The plan was for Development to deliver a release every quarter, internally only, incrementally and iteratively building up the platform with every internal release, leading up to the final product release.
4) With a well-groomed release backlog coming out of the gate, the team could begin planning and executing sprints, and gauging their velocity. This in turn would enable refining of the release plan as the project progressed.
5) The team delivered a demo by the end of the second sprint, and every sprint thereafter. They recently made their first quarterly release milestone.
Agile Adoption : Summary
For a new development team with only basic Agile training prior to release planning, within two weeks we had a mutually agreed upon viable release plan that enabled the team to begin executing sprints aligned to the first quarterly release. They had learned how to capture product requirements as user/ role and goal –centric epics, features and stories, create acceptance criteria, estimate stories in relative story points, and they were ready for the first sprint planning and execution.
Without good Agile release planning, teams often try to start sprinting with a poorly groomed backlog, with no clear direction towards delivering on release goals. This can result in wasted time and effort (money), engraining of bad habits, as well as frustration and disappointment with Agile adoption.Learn More
Visual Evidence of an Agile Release
Last Updated on Wednesday, 12 June 2013 02:54 Written by Peter Callies Wednesday, 12 June 2013 02:54
Below is a fancy release burnup chart (click it to see the full image) that visually shows the work of a team from a recent release by a LeadingAgile client.
The red line effectively is the amount of risk. You can see that the team started the release with about 50% of their stories unsized, but consistently drove that down through the first half of the release.
You can see the impact of end-of-release hardening in the flatness of the shaded blue area on the right side of the chart.
In the shaded gray area, you can see the team performing backlog grooming, breaking down the work into estimated stories and even cutting scope mid-release (the gray area increases as the red line decreases).
The flatness of the shaded blue area early in the release shows the impact of a backlog that isn’t well-groomed, but as the team drove that red line down, the blue area takes on a more-consistent positive slope.
Cool stuff that demonstrates the impact of a groomed backlog and the effectiveness of a team.