Subscribe to Methods & Tools
if you are not afraid to read more than one page to be a smarter software developer, software tester or project manager!
Software Development Blogs: Programming, Software Testing, Agile Project Management
Subscribe to Methods & Tools
if you are not afraid to read more than one page to be a smarter software developer, software tester or project manager!
I spoke with a Scrum Master the other day. He was concerned that the team didn’t finish their work in one 2-week iteration. He was thinking of making the iterations three weeks.
I asked what happened in each iteration.¬†Who wrote the stories and when, when did the developers finish what, and when did the testers finish what? Who (automated tests, testers or customers) reported¬†defects post-iteration?
He is the Scrum Master for three teams, each of whom has a different problem. (The fact that he SMs for more than one team is a problem I’ll address later.)
Team 1 has 6 developers and 2 testers. The Product Owner is remote. The PO generates stories for the team in advance of the iteration. The PO explains the stories in the Sprint Planning meeting. They schedule the planning meeting for 2 hours, and they almost always need 3 hours.
The developers and testers work in a staggered iteration. Because the developers finish their work in the first two-week iteration, they call their iterations two weeks. Even though the testers start their testing in that iteration, the testers don’t finish.
I explained that this iteration duration was at least three weeks. I asked if the testers ever got behind in their testing.
“Oh, yes,” he replied. “They almost always get behind. These days, it takes them almost two weeks to catch up to the developers.”
I explained that the duration that includes development and testing is the duration that counts. Not the first two weeks, but the total time it takes from the start of development to the end of testing.
“Oooh.” He hadn’t realized that.
He also had not realized that they are taking too much work (here, work in progress, WIP). The fact that they need more time to discuss stories¬†in their planning meeting? A lot of WIP. The fact that the developers finish first? That creates WIP for the testers.
Sequential work makes your iterations longer. What would it take for you to work as a team on stories and reduce the lag time between the time the development is done and the testing is done?
The next post will be about when you have a longer duration based on interdependencies.
I’ve been teaching workshops these last few weeks.¬†A number of the participants think that they need to create great estimates. I keep hearing, “I have to create accurate estimates. My team needs my estimate to be accurate.”
I have found that the smaller the work, the better the estimate. If people work as a team, they can provide more accurate estimates than they can alone. And, if they work as a team, the more likely they are to meet the estimate.
The people in my workshops did not want to hear this. Many of them wanted to know how to create an estimate for “their” work, accounting for multitasking.
I don’t know how to create great estimates when people assume they work alone, or if they multitask.
In all of my experience, software is a team activity (especially if you want to use agile or lean). For me, creating an estimate of “my” work is irrelevant. The feature isn’t done until it’s all done.
When we create solo estimates, we reinforce the idea that we work alone. We can work alone. I have discovered I have different ideas when I pair. That’s one of the reasons I ask for review, if I am not actively pairing. I have also discovered that I find problems earlier when I pair or ask for frequent review. That changes my overall estimate.
Multitasking creates context switching, with built-in delays. (See¬†Cost of Delay Due to Multitasking, Part 2¬†or Diving for Hidden Treasures.) I don’t know how to account for the context-switch times. For me, the context-switching time varies, and depends on how many switches I need to do.
If you want to create great estimates, estimate as a team. For hints, see Predicting the Unpredictable: Pragmatic Approaches to Estimating Project Cost or Schedule.
I urge you to make the thing you estimate small, you consider how you work with other people to deliver this thing, and you do one chunk of work at a time. All of those ideas will help you create better estimates. Not for “your” work, but for the work you deliver to your customer.
I’ve been traveling, teaching, speaking and consulting all over the world. I keep encountering managers who talk about the “resources.” They mean people, and they say “resources.”
That makes me nuts. I blogged about that in¬†People Are Not Resources. (I have other posts about this, too, but that’s a good one.)
I finally determined what we might call people. People are “resilience creators.” They are able to recognize challenges, concerns, or problems, and adjust their behavior.
People solve problems so the project can continue and deliver the product.
People fix problems so that customer support or sales can make the user experience useful.
People deliver products and/or services (or support the people who do) so that the company can continue to employ other people, deliver the company’s work, and acquire/retain customers.
We want resilient companies (and projects and environments). When we encounter a hiccup (or worse) we want the work to continue. Maybe not in the way it did before. Maybe we need to change something about what we do or how we do it. That’s fine. You hired great people, right?
People can solve problems so that the company can be resilient. To me, that means that the people are resilience creators, not “resources.”
People create resilience when they have the ability to solve problems because you asked them for results.
People create resilience when they understand the goals of the work.
People create resilience when they have the ability to work together, in a holistic way, not in competition with each other.
What would you rather have in your organization: resources or resilience creators?
A couple of weeks ago, I had a great time participating in the Agile in Large Enterprises panel, a part of the Continuous Discussions (#c9d9) that Electric Cloud hosts.
Here’s the recording:
We discussed these questions:
I had a number comments, which you should watch to see the entire context:
I had a terrific time along with my fellow panelists.
The discussion to now:
When you move from resource efficiency (experts and handoffs from expert to expert) to flow efficiency (team works together to finish work), everything changes.
The time that people spend multitasking should decrease or go to zero because the team works together to finish features. The team will recognize when they are done—really done—with a feature. You don’t have the “It’s all done except for…” problem.
Managers don’t need to manage performance. They manage the system, the environment that makes it possible for people to perform their best. Managers help equip teams to manage their own performance.
The team is accountable, not a person. That increases the likelihood that the team will estimate well¬†and that the team delivers what they promised.
If you are transitioning to agile, and you have not seen these things occur, perform a retrospective. Set aside at least two hours and understand your particular challenges. I like Agile Retrospectives: Making Good Teams Great,¬†Getting Value out of Agile Retrospectives – A Toolbox of Retrospective Exercises, and¬†The Retrospective Handbook: A Guide for Agile Teams¬†for creating a retrospective that will work for you. You have unique challenges. Learn about them so you can address them.
I hope you enjoyed this series. Let me know if you have questions or comments.
This is the next in a series of posts about resource efficiency vs. flow efficiency:
Managers new to agile often ask, “How do I know people will be accountable?” Let’s tease apart the pieces of accountability:
Let’s take¬†the first two together:Accountable for finishing their own work and by doing their work
I suspect that managers mean, “How do I know each person does their work? How do I know they aren’t asking other people to do their work? How do I know these people are learning to do their own work?”
Those are good questions. I have yet to see a single-person feature. At the least, a developer needs someone to test their work. Yes, it’s possible to test your own work. Some of you are quite good at that, I bet.¬†Many people are not. If you want to prevent rework, build in checking in some form or another: pairing, design review, code review, unit tests, system tests, something.
So the part about “own work” seems a little micro-managing to me.
The part about doing their work is a little trickier. When people get stuck, what do they do? Often, they ask someone else for help. The help might be: talk to the duck, an explanation about what is going on in that area of the product, pairing on solving the problem, or even talking to more people.
There is no such thing as “cheating” at work. Managers are right to be concerned that people work to their capabilities. And, if those people are stuck, I don’t want them mired in the problem. We want people to learn, not be stuck.
Here’s the answer: You can’t know as a manager. You never did know as a manager.
The team knows who is hardworking and who slacks. The team knows how people are learning and if they are stuck. Even in waterfall days, the team knew. Managers may have had the illusion they knew, but they didn’t. Managers only knew what people told them.Accountable for documentation
For me, the question is who will use the documentation? I am always amazed at how many managers want documentation other than end-user documentation and how few teams find this useful. In agile, you could make it part of the definition of done.
If people build documentation time into their estimates and the team finds the internal documentation useful, the team will pressure each person to deliver their documentation. The team knows whether the person documents their work.Accountable for living up to estimates
When I ask managers if they want good estimates or completed features, they almost always say, “completed features.” Too often, the people multitask on fixing defects or production support work while they are supposed to work on a feature. I do understand the need for estimates, but holding people to their estimates? Sometimes, that’s about money.Accountable for how the project spends money
Of all the accountabilities, this one makes the most sense to me. However, it doesn’t make sense in agile, where the customer/product owner is the one responsible. As long as the team completes features, the PO determines when either there is no more value in the backlog, or there is no more money for the project. With any luck, the team has met the release criteria by this time.
For me, the idea of accountability is a team-based idea, not a person-based idea. In flow efficiency, you can ask the team to be accountable for:
When you look at accountability like this, it looks pretty different than a single person’s accountability.
Part 5 is the summary post for this series.
Resource Efficiency vs. Flow Efficiency, Part 1: Seeing Your System¬†explains resource efficiency and flow efficiency. Resource Efficiency vs. Flow Efficiency, Part 2: Effect on People explains why flow efficiency helps you get features done faster. Here, in part 3, I’ll address the performance management question.
New-to-agile (and some experienced) managers ask, “How can I manage performance? How will I know people are accountable for their work?”
These are good questions.¬†Performance management and accountability are two different things in flow efficiency.
Here are some ways to manage performance:
If you do these things, you will discover that people are accountable to each other for their work.¬†The point of a standup is to help people vocalize their accountabilities. If the team works as a swarm or as multiple pairs/triads/whatever, they might not need a standup. They might need a kanban board with WIP (work in progress) limits. If your organization likes iterations because it provides boundaries for decision-making or providing focus, that works. It can work with or without a kanban board.
Here’s a question I like to ask managers, “Have you hired responsible adults?” The managers almost always say, “Yes.” They look at me as if I am nuts. I then ask, “Is there a reason for you to not trust them?”
Now we get to the real issues. If the managers have encouraged/enforced resource efficiency, the people often multitask. Or, they have to wait for other people to finish their work. People have a difficult time finishing their work “on time.” Managing “performance” is a function of the system.¬†The system of resource efficiency requires someone to check up on people, because the expertise bottlenecks can become severe.
Instead, if you manage the system by focusing on what you want—features—instead of tasks, you don’t have to do much performance management. Will you make a mistake and hire someone who doesn’t fit? Maybe. The team can tell you.
What if you hire a superstar? Maybe you’re worried that person won’t have enough to do. My experience is that the team will ask the so-called superstar to help them with other things, making her even more of a superstar. In addition, this superstar can help with everyone learning more.
If you don’t rub people’s noses in the fact that someone might be “better” than they are, they will use that person well. Yes, sometimes, I was the person who learned from the superstar. Sometimes I was the superstar. I never noticed. I noticed I got better when I worked with certain people and asked to work with them more often.
Think about what makes people happy at work. Once you take money off the table by paying people enough, it’s all about mastery, autonomy, and purpose.
As managers, you create the system to provide mastery, autonomy, and purpose. You don’t have to manage what people do all day. If you think you do, why would you want to use agile?
BTW, managing for results isn’t new. Peter Drucker first published Managing for Results in 1964.
In part 4, I’ll address accountability and what it could mean in flow efficiency as opposed to resource efficiency.
If you haven’t read Resource Efficiency vs. Flow Efficiency, Part 1: Seeing the System, ¬†I explain there about optimizing for a given person’s work vs. optimizing for features. Some people (including managers) new to agile have questions about working in flow vs. optimizing for a person.
The managers ask:
This post is about the length of the work and how people feel when they can’t finish work.
When you have experts, as in resource efficiency, the work queues up behind the expert. Let’s say you have three senior people with these separate expertise areas:
You want Features 1 and 2, which have significant UI impact. Abe is a master at iterating with all the necessary people to get the UI just right. In the meantime, Cindy and Brian go on to Features 3, 4, and 5 because they aren’t needed (yet) on Features 1 and 2.
If you measured cumulative flow, you would see that all five features are open for a while, because these three people have started on them and not finished anything.
Abe encounters a problem with the UI. The customer doesn’t respond or the product management people are not available. Something impedes his progress. So, he starts Feature 9, which is the next feature with significant UI design.
Notice that he doesn’t start the next ranked feature. He starts the next one he can work on.
Cindy and Brian also encounter delays because the test automation isn’t there, or the build takes too long (or something). Choose whatever happened to you last week as an impediment.
They need to stay busy, so they see that Feature 6 needs them both. They start on it. They realize there is a need for UI work. They ask Abe if he is available. No, Abe is working on Feature¬†9, not Feature 6. Now, Cindy and Brian have another feature in progress.
If this sounds like your project, you are not alone. This is a result of resource efficiency.
The human effect of resource efficiency is multitasking, a feeling of impending pressure because you can see the deadline but you’re not getting closer. You wonder if you will ever finish the work.
Instead, imagine if Cindy, Brian, and Abe along with a tester took Feature 1. They might prepare their platform and middleware parts of the work. They might help Brian with the prototype generation and iteration. They might be able to bang on doors if Abe needs to concentrate on something specific. “I’ll be done with this in a couple of hours. Can you reserve a conference room and ask the product manager to be there? She always gives me a hard time on the UI. I want to know what she thinks of it now.” Or, “Can you call Customer A and get ready for a walkthrough in a couple of hours?”
You might think of this reserve-a-room or call-people work as something a project manager should do. In reality, these actions are servant leadership actions. Anyone can do them.
We often have lead-time for some parts of development. Even if we want to work in flow, we might need other people to finish.
Even if Cindy and Brian can’t directly help with the UI, they can make it easier for Abe to succeed. And, if the tester¬†is involved at the beginning, the tester can create automated tests that don’t depend on the GUI. Maybe the developers not working on product code can help with an automated test framework. (I find that testers new to data-driven ¬†or automated testing don’t always know how to start. Developers might be able to help.)
Imagine if Cindy, Brian, and Abe are not the only people on their team. They are the most senior, and there are two or three other developers on the team. What happens when those more junior developers have a question? Cindy, Abe, and Brian have to stop working on their stories to work with the other people. Or, maybe they don’t and the other people are stuck. I see this in teams all the time. I bet you do, too.
When we optimize for resource efficiency, we have people with unfinished, open work. The more work they have not done, the more they have new work queuing up behind them. They work hard all day and don’t feel as if they accomplish anything, because nothing gets to done.
When we¬†optimize for flow efficiency, people finish things, together. They have less work in progress. They feel a sense of accomplishment because they can point to what they have completed.
I can’t guarantee a team can finish faster in flow because I am not an academic. However, you’ve heard, “Many hands make light work.” That’s the idea. When we help each other move a chunk of work to done, we all succeed faster.
Part 3 will talk about what managers perceive as performance management.
I’ve been working with a number of people who want to work in a more agile way. These nice folks have one stumbling block: resource efficiency vs. flow efficiency. This is partly because of how they see the system of work.
If you ever used phases or a waterfall approach, you might have tried to optimize resource efficiency:
Each person is a specialist. That means they—and only they—can do their work. The more senior and the more specialized they are, the more they need to do the work and the less capable other people are (for that work). Think of a UI designer or a database admin. I often see teams who don’t have those necessary-for-them roles.
With resource efficiency, you optimize for each person along the way. You get the feature when you get it. Each person is “fully utilized.” This leads to a cost of delay. (See Diving for Hidden Treasures to see more costs of delay.) It also leads to problems such as:
Contrast that with flow efficiency:
In flow efficiency, the team takes the feature. The team might specialize in that feature area (I see this a lot on ¬†programs). If anyone needs to be away from work for a day or a week or two, the team can continue to do the work without that one person. Yes, the team might be a little slower, but they can still release features.
In flow efficiency, it doesn’t matter what each person “knows.” The team optimizes its work to get features done. You can see this when teams limit the backlog coming into an iteration, when they pair, swarm, or mob to finish features. If the team uses kanban and they keep to their work in progress limits, they can see flow efficiency also.
Resource efficiency is about optimizing at the level of the individual. Flow efficiency is about optimizing for the feature.
If you are transitioning to agile, ask this question, “How do we optimize for features? It doesn’t matter if we keep everyone busy. We need to release features.” This is a mindset change and can challenge many people.
Here’s why you should ask this question: Your customers buy features. They don’t buy your busy-ness.
When I tell managers about resource vs. flow efficiency, they often react, “Yes. But how do we know the features won’t take more time?” and “How will we know how to do performance management?” I’ll address that in parts 2 and 3.
I keep seeing talks and arguments about how the portfolio team should manage the epics for a program. That conflates the issue of project portfolio management and product management.
Several potential teams affect each project (or program).
Starting at the right side of this image, the project portfolio team decides which projects to do and when for the organization.
The product owner value team decides which features/feature sets to do when for a given product. That team may well split feature sets into releases, which provides the project portfolio team opportunities to change the project the cross-functional team works on.
The product development team (the agile/lean cross-functional team) decides how to design, implement, and test the current backlog of work.
When the portfolio team gets in the middle of the product roadmap planning, the product manager does not have the flexibility to manage the product backlog or the capabilities of the product over time.
When the product owner value team gets in the middle (or doesn’t plan enough releases), they prevent the project portfolio team from being able to change their minds over time.
When the product development team doesn’t release working product often, they prevent the product owner team from managing the product value. In addition, the product development team prevents the project portfolio team from implementing the organizational strategy when they don’t release often.
All of these teams have dependencies on each other.
The project portfolio team optimizes the organization’s output.
The product owner value team optimizes the product’s output.
The product development team determines how to optimize for features moving across the board. When the features are complete, the product owner team can replan for this product and the project portfolio team can replan for the organization. Everyone wins.
That’s why the product owner team is not the project portfolio team. (In small organizations, it’s possible people have multiple roles. If so, which hat are they wearing to make this decision?
The product roadmap is not the project portfolio. Yes, you may well use the same ranking approaches. The product roadmap optimizes for this product. The project portfolio team optimizes for the overall organization. They fulfill different needs. Please do not confuse the two decisions.
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.
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:
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:
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
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:
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:
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?