Johanna Rothman's Blog, page 8
August 24, 2015
Agile 2015 was the week of Aug 3-7 this year. It was a great week. Here are the links to my interviews and talks.
Interview with Dave Prior. We spoke about agile programs, continuous planning, and how you might use certifications. I made a little joke about measurement.
Interview with Paul DuPuy of SolutionsIQ. We also spoke about agile programs. Paul had some interesting questions, one of which I was not prepared for. That’s okay. I answered it anyway.
The slides from Scaling Agile Projects to Programs: Networks of Autonomy, Collaboration and Exploration. At some point, the Agile Alliance will post the video of this on their site.
The slides from my workshop Agile Hiring: It’s a Team Sport. Because it was a workshop, there are built-in activities. You can try these where you work.
My pecha kucha (it was part of the lightning talks) of Living an Agile Life.
I hope you enjoy these. I had a great time at the conference.
August 17, 2015
If you’ve read Reasons for Continuous Planning, you might be wondering, “How can we do this?” Here are some ideas.
You have a couple of preconditions:
The teams get to done on features often. I like small stories that the team can finish in a day or so.
The teams continuously integrate their features.
Frequent features with continuous integration creates an environment in which you know that you have the least amount of work in progress (WIP). Your program also has a steady stream of features flowing into the code base. That means you can make decisions more often about what the teams can work on next.
Now, let’s assume you have small stories. If you can’t imagine how to make a small story, here is an example I used last week that helped someone envision what a small story was:
Imagine you want a feature set called “secure login” for your product. You might have stories in this order:
A person who is already registered can login with their user id and password. For this, you only need to have a flat file and a not-too-bright parser—maybe even just a lookup in the flat file. You don’t need too many cases in the flat file. You might only have two or three. Yes, this is a minimal story that allows you to write automated tests to verify that it works even when you refactor.
A person who is not yet registered can create a new id and password.
After the person creates a new id and password, that person can log in. You might think of the database schema now. You might not want the entire schema yet. You might want to wait until you see all the negative stories/features. (I’m still thinking flat file here.)
Now, you might add the “parse-all-possible-names” for login. You would refactor Story #2 to use a parser, not copy names and emails into a flat file. You know enough now about what the inputs to your database are, so you can implement the parser.
You want to check for people that you don’t want to log in. These are three different small stories. You might need a spike to consider which stories you want to do when, or do some investigation.
Are they from particular IP addresses (web) or physical locations?
Do you need all users to follow a specific name format?
Do you want to use a captcha (web) or some other robot-prevention device for login (three tries, etc.)?
Maybe you have more stories here. I am at the limit of what I know for secure login. Those of you who implement secure login might think I am past my limit.
These five plus stories are a feature set for secure login. You might not need more than stories 1, 2, and 3 the first time you touch this feature set. That’s fine. You have the other stories waiting in the product backlog.
If you are a product owner, you look at the relative value of each feature against each other feature. Maybe you need this team to do these three first stories and then start some revenue stories. Maybe the Accounting team needs help on their backlog, and this feature team can help. Maybe the core-of-the-product team needs help. If you have some kind of login, that’s good enough for now. Maybe it’s not good enough for an external release. It’s good enough for an internal release.
Your ability to change what feature teams do every so often is part of the value of agile and lean product ownership—which helps a program get to done faster.
You might have an initial one-quarter backlog that might look like this:
Start at the top and left.
You see the internal releases across the top. You see the feature sets across just under the internal releases. This part is still a wish list.
Under the feature sets are the actual stories in the details. Note how the POs can change what each team does, to create a working skeleton.
The details are in the stories at the bottom.
This is my picture.You might want something different from this.
The idea is to create a Minimum Viable Product for each demo and to continue to improve the walking skeleton as the project teams continue to create the product.
Because you have release criteria for the product as a whole, you can ask as the teams demo, “What do we have to do to accomplish our release criteria?” That question allows and helps you replan for the next iteration (or set of stories in the kanban). Teams can see interdependencies because their stories are small. They can ask each other, “Hey can you do the file transfer first, before you start to work on the Engine?”
The teams work with their product owners. The product owners (product owner team) work together to develop and replan the next iteration’s plan which leads to replanning the quarter’s plan. You have continuous planning.
You don’t need a big meeting. The feature team small-world networks help the teams see what they need, in the small. The product owner team small-world network helps the product owners see what they need for the product over the short-term and the slightly longer term. The product manager can meet with the product owner team at least once a quarter to revise the big picture product roadmap.
You can do this if the teams have small stories, if they pay attention to technical excellence and use continuous integration.
In a program, you want smallness to go big. Small stories lead to more frequent internal releases (every day is great, at least once a month). More frequent internal releases lead to everyone seeing progress, which helps people accomplish their work.
You don’t need a big planning meeting. You do need product owners who understand the product and work with the teams all the time.
The next post will be about whether you want resilience or prediction in your project/program. Later
August 10, 2015
I’m working on the program management book, specifically on the release planning chapter. One of the problems I see in programs is that the organization/senior management/product manager wants a “commitment” for an entire quarter. Since they think in quarter-long roadmaps, that’s not unreasonable—from their perspective.
There is a problem with commitments and the need for planning for an entire quarter. This is legacy (waterfall) thinking. Committing is not what the company actually wants. Delivery is what the company wants. The more often you deliver, the more often you can change.
That means changing how often you release and replan.
Consider these challenges for a one-quarter commitment:
Even if you have small stories, you might not be able to estimate perfectly. You might finish something in less time than you had planned. Do you want to take advantage of schedule advances?
In the case of too-large stories, where you can’t easily provide a good estimate, (where you need a percent confidence or some other mechanism to explain risk,) you are (in my experience) likely to under-estimate.
What if something changes mid-quarter, and you want more options or a change in what the feature teams can deliver? Do you want to wait until the end of a quarter to change the program’s direction?
If you “commit” on a shorter cadence, you can manage these problems. (I prefer the term replan.)
If you consider a no-more-than-one-monthly-duration “commit,” you can see the product evolve, provide feedback across the program, and change what you do at every month milestone. That’s better.
Here’s a novel idea: Don’t commit to anything at all. Use continuous planning.
If you look at the one-quarter roadmap, you can see I show three iterations worth of stories as MVPs. In my experience, that is at least one iteration too much look-ahead knowledge. I know very few teams who can see six weeks out. I know many teams who can see to the next iteration. I know a few teams who can see two iterations.
What does that mean for planning?
Do continuous planning with short stories. You can keep the 6-quarter roadmap. That’s fine. The roadmap is a wish list. Don’t commit to a one-quarter roadmap. If you need a commitment, commit to one iteration at a time. Or, in flow/kanban, commit to one story at a time.
That will encourage everyone to:
Think small. Small stories, short iterations, asking every team to manage their WIP (work in progress) will help the entire program maintain momentum.
See interdependencies. The smaller the features, the clearer the interdependencies are.
Plan smaller things and plan for less time so you can reduce the planning load for the program. (I bet your planning for one iteration or two is much better and takes much less time than your one-quarter planning.)
Use deliverable planning (“do these features”) in a rolling wave (continue to replan as teams deliver).
If you keep the planning small, you don’t need to gather everyone in one big room once a quarter for release planning. If you do continuous planning, you might never need everyone in one room for planning. You might want everyone in one room for a kickoff or to help people see who is working on the program. That’s different than a big planning session, where people plan instead of deliver value.
If you are managing a program, what would it take for you to do continuous planning? What impediments can you see? What risks would you have planning this way?
Oh, and if you are on your way to agile and you use release trains, remember that the release train commits to a date, not scope and date.
Consider planning and replanning every week or two. What would it take for your program to do that?
August 4, 2015
In agile, we separate the Product Owner function from functional (development) management. The reason is that we want the people who can understand and evaluate the business value to articulate the business value to tell the people who understand the work’s value when to implement what. The technical folks determine how to implement the what.
Separating the when/what from how is a great separation. It allows the people who are considering the long term and customer impact of a given feature or set of features a way to rank the work. Technical teams may not realize when to release a given feature/feature set.
In my recent post, Product Manager, Product Owner, or Business Analyst?, I discussed what these different roles might deliver. Now it’s time to consider who should do the product management/product ownership roles.
If you have someone called a product manager, that person defines the product, asks the product development team(s) for features, and talks to customers. Notice the last part, the talking to customers part. This person is often out of the office. The product manager is an outward-facing job, not an internally-focused job.
The product owner works with the team to define and refine features, to replan the backlogs, and to know when it is time to release. The product owner is an inward-facing function.
(Just for completeness, the business analyst is an inward-facing function. The BA might sit with people in the business to ask, “Exactly what did you mean when you asked for this functionality? What does that mean to you?” A product owner might ask that same question.)
What happens when your product manager is your product owner? The product development team doesn’t have enough time with the product owner. Maybe the team doesn’t understand the backlog, or the release criteria, or even something about a specific story.
Sometimes, functional managers become product owners. They have the domain expertise and the ability to create a backlog and to work with the product manager when that person is available. Is this a good idea?
If the manager is not the PO for his/her team, it’s okay. I wonder how a manager can build relationships with people in his/her team and manage the problems and remove impediments that the team needs. Maybe the manager doesn’t need to manage so much and can be a PO. Maybe the product ownership job isn’t too difficult. I’m skeptical, but it could happen.
There is a real problem when a team’s manager is also the product owner. People are less likely to have a discussion and disagree with their managers, especially if the organization hasn’t moved to team compensation. In Weird Ideas That Work: How to Build a Creative Company, Sutton discusses the issue of how and when people feel comfortable challenging their managers.
Many people do not feel comfortable challenging their managers. At all.
We want the PO and the team to be able to have that give-and-take about ranking, value, when it makes sense to do what. The PO makes the decision, and with information from the team, can take all the value into account. The PO might hear, “We can implement this feature first, and then this other feature is much easier.” Or, “If we fix these defects now, we can make these features much easier.” You want those conversations. The PO might say, “No, I want the original order” and the team will do it. The conversations are critical.
If you are a manager, considering being a PO for your team, reconsider. Your organization may have too many managers and not enough POs. That’s a problem to fix. Don’t make it difficult for your team to have honest discussions with you. Make it possible for people with the best interests of the product to have real discussions without being worried about their jobs.
(If you are struggling with the PO role, consider my Product Owner Training for Agencies. It starts next week.)
July 30, 2015
The lovely folks at Thoughtworks interviewed me for a blog post, Embracing the Zen of Program Management. I hope you like the information there.
If you want to know about agile and lean program management, see Agile and Lean Program Management: Scaling Collaboration Across the Organization. In beta now.
July 29, 2015
Ryan Ripley “highly recommends” Predicting the Unpredictable: Pragmatic Approaches to Estimating Cost or Schedule. See his post: Pragmatic Agile Estimation: Predicting the Unpredictable.
He says this:
This is a practical book about the work of creating software and providing estimates when needed. Her estimation troubleshooting guide highlights many of the hidden issues with estimating such as: multitasking, student syndrome, using the wrong units to estimate, and trying to estimates things that are too big. — Ryan Ripley
Thank you, Ryan!
See Predicting the Unpredictable: Pragmatic Approaches to Estimating Cost or Schedule for more information.
July 23, 2015
Many product owners have a tough problem. They need so many of the potential features in the roadmap, that they feel as if everything is #1 priority. They realize they can’t actually have everything as #1, and it’s quite difficult for them to rank the features.
This is the same problem as ranking for the project portfolio. You can apply similar thinking.
Once you have a roadmap, use these tips to help you rank the features in the backlog:
Should you do this feature at all? I normally ask this question about small features, not epics. However, you can start with the epic (or theme) and apply this question there. Especially if you ask, “Should we do this epic for this release?”
Use Business Value Points to see the relative importance of a feature. Assign each feature/story a unique value. If you do this with the team, you can explain why you rank this feature in this way. The discussion is what’s most valuable about this.
Use Cost of Delay to understand the delay that not having this feature would incur for the release.
Who has Waste from not having this feature? Who cannot do their work, or has a workaround because this feature is not done yet?
Who is waiting for this feature? Is it a specific customer, or all customers, or someone else?
Pair-wise and other comparison methods work. You can use single or double elimination as a way to say, “Let’s do this one now and that feature later.”
What is the risk of doing this feature or not doing this feature?
Don Reinertsen advocates doing the Weighted Shortest Job first. That requires knowing the cost of delay for the work and the estimated duration of the work. If you keep your stories small, you might have a good estimate. If not, you might not know what the weighted shortest job is.
And, if you keep your stories small, you can just use the cost of delay.
Jason Yip wrote Problems I have with SAFe-style WSJF, which is a great primer on Weighted Shortest Job First.
I’ll be helping product owners work through how to value their backlogs in Product Owner Training for Your Agency, starting in August. When you are not inside the organization, but supplying services to the organization, these decisions can be even more difficult to make. Want to join us?
July 16, 2015
Do you have a title such as product manager, product owner, or business analyst?
We hear these titles all the time. What does each do?
Here is how I have seen successful agile projects and programs use people in these positions. Note that I am discussing agile projects and programs.
The product manager creates the roadmap. She has the product vision over the entire life of the product. Typically, what’s In the roadmap are larger than epics—they are themes or feature sets.
Product management means thinking strategically about the product. You might require several projects or programs to achieve what the product manager wants as a strategic vision.
Product owners (PO) work with agile teams to translate the strategic vision into Minimum Viable Products. The PO decides when the team(s) have done enough to release. See the release frequency image to understand the cost and value of releasing.
The business analyst may do any of these things. In my experience, I have seen business analysts focus on “what does this requirement/feature/story really mean to the team and/or the product?” I have seen fewer BAs do the strategic visioning of the product over its lifetime. I have seen BAs work with POs when the PO was not available enough for the team. I have seen BAs do great work breaking stories into smaller components of value, not architectural components.
Your team might have different names for these positions. Each team needs the strategic lifetime-of-the-product view; the tactical view for the next iteration or so and the knowledge of how to re-rank the backlog; and the ability to translate stories into small valuable chunks.
Can one person do each of these things? It depends on the person. I have found it difficult to move quickly from the tactical to strategic and back again (or vice versa). Maybe you know how. For me, that is a form of multitasking.
The more important questions are: do you have the roles you need, at the time you need them on your team? If you are one of these people, do you know how to perform these roles? If you are outside the organization in some way, do you know what you need to do, to perform these roles?
If you don’t know what to do to help your team, consider participating in Product Owner for Agencies training. Marcus Blankenship and I will help you learn what to do, and coach you in real time as to how to do it best for your team. I hope to see you there.
July 7, 2015
As I work with more clients on their programs, I see that what might work for a product owner for a team does not work for a program. In a program, if the product owner is shortsighted, does not take advantage of agile/lean for updates, and does not have small features, the program loses momentum. Here are my three tips:
When the product owner (or, in this case, a program product owner) creates a several quarter rolling wave roadmap the teams can see the product direction. This helps the teams see avoid bad product decisions that might inadvertently prevent the product from taking a direction the PO would like.
There is a challenge with this. Teams can rarely, if ever, commit to an entire quarter’s worth of work. That’s okay. The roadmap is a wishlist. The roadmap informs and guides the product development. Teams need detailed backlogs.
I know of just a couple of teams who can plan for up to three iterations and not replan. Some teams can plan for two iterations, some for one. Even if you can complete features according to a one-quarter roadmap, the product owner needs the ability to change the ranking of the remaining features.
As the teams finish features, it’s the product owner’s job to accept the features, or not. And, it’s the product owner’s job to update the one-quarter roadmap—and maybe the multiple quarter roadmap.
The bigger the product, the smaller the features/stories need to be.
I’m working with some programs who have only 5 or 6 teams. I’m working with some who have 20, 30, 40 teams. That’s a ton of people. How do those people stay in sync? By integrating and creating tests that test the product, end to end. If the stories are large, the teams have a ton of work in progress and lose the ability to collaborate easily. This can be a huge challenge for the product owners and teams.
For one-team projects, I like one and two-day stories. That way the product owner can see progress every day. (I’m happy if it’s even more often than that! Two days is my max story size.)
I know product owners who can barely make time for one meeting an iteration with their teams. That does not provide the product owner feedback about the story size, or what is in the stories. Stories tend to become more complex. Then, the team doesn’t finish the stories and everyone wants to know why.
When you have smaller stories, you see the value in what the team(s) do, all the time. The teams build momentum.
Making stories small requires you think about how little you can do, not how much. That’s a huge change, especially in a program.
Those are my three tips for today:
Create a big picture rolling-wave roadmap.
Update the roadmap often, as teams complete features.
Create small stories so the team(s) can maintain momentum.
If you liked this post, you might want to join Marcus Blankenship and me for our Product Owner for Agencies training. These things are tricky enough when you are inside the organization. They are more difficult when you are an agency/consultant working for the client.
July 2, 2015
We have an interesting problem in some projects. Agencies, consulting organizations, and consultants help their clients understand what the client needs in a product. Often, these people and their organizations then implement what the client and agency develop as ideas.
As the project continues, the agency manager continues to help the client identify and update the requirements. Because this a limited time contract, the client doesn’t have a product manager or product owner. The agency person—often the owner—acts as a product owner.
This is why Marcus Blankenship and I have teamed up to offer Product Owner Training for Agencies.
If you are an agency/consultant/outside your client’s organization and you act as a product owner, this training is for you. It’s based on my workshop Agile and Lean Product Ownership. We won’t do everything in that workshop. Because it’s an online workshop, you’ll work on your projects/programs in between our meetings.
If you are not part of an organization and you find yourself acting as a product owner, this training is for you. See Product Owner Training for Agencies.