Johanna Rothman's Blog, page 4
December 22, 2015
I am about to update Manage Your Project Portfolio: Increase Your Capacity and Finish More Projects to a second edition.
What would you like me to add? To remove? To change? What have your challenges been about project portfolio management?
Here are things I’m planning to add:
Many more kanban views of the project portfolio and some words about visualization.
Discussion (or more than one) about Cost of Delay.
How a project’s product backlog is not the same as an organization’s project portfolio.
More discussion about what you optimize and why.
What else would you like to see? Please either comment or send me email. Thanks!
December 15, 2015
The big problem with hardware going agile is that the risks in hardware are not homogeneous. Hardware and mechanical engineering are on different cycles from each other, and they are each different from software. Even with each discipline, the risks are different when the teams collaborate together on one deliverable and when the entire program has to collaborate to create a product.
The engineering teams simulate to see problems in their own work and solve those problems. Each team is ready for integration at a different time. They can’t integrate until they go to fabrication. That changes the feedback cycle(s) for the entire program.
Questions you can ask are:
Is there an interim physical form that would provide us value?
How much does that form cost us to create?
How long is it that prototype good for?
If there is not an interim physical form that would provide us value, how can we obtain value and reduce risks with what kind of form or demonstration?
Here are some sample problems you could test for and avoid with early prototypes:
The footprint is too large/too small.
The design by contract work you thought was good turns out to be wrong.
You have a design that works but doesn’t produce the product you want.
You may have other problems.
In set-based design, the designers iterate on the design, they rule in or out designs that do not intersect with the rest of the design components. In landing zones, the designers discuss the parameters of what makes a successful design and then converge on that success.
Either of these looks much more like “implement several features and see what architecture emerges, rather than design up front.” It’s also about using the intelligence of an entire team.
There’s a third option: is there a cost-effective way to make a prototype that can provide you feedback without having all the properties? For example, can you use a 3D printer to check the physical footprint, even if you can’t check heat dissipation? I don’t know if that would work for your program or would be a waste of time. I do know that 3D printing is much faster than going to fab for many parts of your product.
I used a fourth option some years ago. We wanted to simulate the traffic on an internal network to see if the design we had would work. I asked about 20 people to meet the architect and me (I was the program manager) in a large conference room. We organized the people according to the types of traffic. We had a metronome to help people walk on time. We simulated the network traffic—what was going where and when—with people. It wasn’t a perfect test, and it told the architect a ton of information about how the software would work with the current hardware. I’m not sure we would do that now—we did not have adequate simulators back then.
We had a metronome to help people walk on time. (The metronome simulated the clock ticks.) We simulated the network traffic—what was going where and when—with people. It wasn’t a perfect test, and it told the architect a ton of information about how the software would work with the current hardware. I’m not sure we would do that now—we did not have adequate simulators back then. At the time, it was a cheap and useful approach to help the architect realize that the hardware would not integrate with the software as he desired.
These methods are not infallible. However, they both provide feedback faster and better than waiting until the end of the project/program, when you have spent all the money and time—and you still don’t have hardware that works.
Hardware can be agile. In Helping Hardware Be More Agile, Part 1, the product owner defines when she wants to see what with a roadmap. That helps the team determine their interdependencies and make the interdependencies visible. In Helping Hardware Be More Agile, Part 2, I showed potential kanbans and how the teams might use them. In this post, I suggested you might gain value from early integration and ways you might do that.
I have more discussion in Agile and Lean Program Management. I started the hardware chapter in the beta that is available now, and expect to complete it “shortly.”
December 10, 2015
Once you have a roadmap/product backlog for hardware, the teams need to know what to do and when. As a program manager, program product owner, or other interested party, you might want to know where the work is. The roadmap shows the big picture. The demos and team-based backlogs show the details and interdependencies
One way to see the work is to ask the engineers to use a kanban board. I recommend each component have its own kanban to see the work in progress.
Here are possible kanbans for mechanical, silicon, and FPGA teams:
Possible Mechanical Engineering Kanban
Possible Silicon Kanban
Possible FPGA Kanban
The FPGA kanban might look much more like a regular software kanban, up until you make the decision to go to physical form.
These are possible kanbans, not the way your organization might work.
These kanbans help everyone see where the work is. The roadmap in Helping Hardware Be Agile, Part 1 shows when the Program Product Owner would like the demos to be. The teams use those deliverables to decide when to integrate and test.
The more integration points your program has, the easier it is to see the entire product, not just one component.
The issue with integration points is that going to physical form can be expensive (in money and time). What is the relative value of staying in simulation mode vs. creating a prototype that people can touch and use? There is no One Right Answer. Part of it depends on the cadence of each team and the team’s risks. I’ll address hardware risks in the next installment.
December 4, 2015
I’m writing like mad, trying to finish the program management book. I’m working on the “Integrating Hardware” chapter.
The problem is that hardware comes in several varieties:
Silicon (part of electrical engineering)
FPGA (which looks like software to me)
Each component (yes, I do call these components) has a different value at different times in the product development. The program needs all of them by the end. But how do you see the product evolve? Is it even possible?
Well, yes it is possible to see a product with hardware evolve. The problem is that hardware is expensive to transition to physical form. Every time you go to physical form, you incur NRE (Non-Recurring Engineering) Expenses. If you have to fabricate a chip or board, that’s expensive. In my experience, my organizations want to fab no more than three times(prototype, pilot, real product). And, all near the end of the program.
The first problem is ranking the features and organizing a product roadmap. In the book, I have a possible product, a robot arm. (None of my clients are developing robot arms, so I’m safe.) Here is the roadmap I created.
Notice that each monthly deliverable is a demo. For each of the first two months, the deliverable is component demos. The software team (OS) could show their completed software to date. The mechanical, silicon and FPGA teams would show their simulations. The simulations are separate for each component. For the third month, there is a potential joint simulation and a demo of the first prototypes.
The goal is to show every team’s work to every other team. For a complex product with hardware, the teams need to see what each other is doing, earlier rather than later.
You can try to do design by contract. It’s a great idea. My experience is it doesn’t matter what’s in the contract. The hardware is always a little different because the hardware people (mechanical and silicon) have to make tradeoffs be able to make the hardware fit the performance, footprint, or manufacturing capabilities. The earlier you can demo to each other on the program, the earlier you can see the changes.
This roadmap shows the teams what the program values first. It outlines the interdependencies. Yes, you need a product owner who either understands the interdependencies, or you need teams who can teach the product owner.
In my next post, I’ll talk about how to see the work each team does. The roadmap is insufficient for the details. The roadmap explains the big picture, and what you want to have happen. What the teams do is reality.
If you have an agile program with hardware, please comment on this post. I would love to know if this is helpful, what you do, and if you do something different what it is. Thanks.
November 25, 2015
When I teach agile, I explain I like small and short stories. I want to see value in the product every day.
Many developers can’t do that. That’s because they have interdependencies with other teams—not developers on their team, but other teams.
They can’t implement in the way the picture next to this shows: small, coherent slices through the architecture.
Instead, they implement in curlicues.
When you implement by curlicues, you often have to wait for other teams. You might have component teams. You might have performance teams. But you can’t implement in nice “straight” features. Your features are complex and don’t take a straight line through the architecture.
When I work with people who have curlicues instead of straight lines through the architecture, I often discover that the different teams can complete parts of features in one iteration. (It doesn’t matter how long the iteration is.) But completing an entire feature? Because that takes the efforts of several teams, the team members believe they have interdependencies and the full feature often takes longer than one iteration.
The teams are correct. They have interdependencies. Sometimes, those interdependencies are quite difficult to see when you start. You only know that they exist when you get stuck partway in the feature.
Implementing by curlicue creates delays. The iteration is not the two weeks, three weeks, four weeks. No, the iteration can be as long as eight, nine, or ten weeks. That’s because each piece of the curlicue has to get to the top of each team’s backlog. The teams might have different product owners who don’t realize each arc of the curlicue is actually related to each other, that you need all of them to become one finished story.
In the meantime, each team has work in progress (WIP) and might not realize it. Or they do realize it, but they can’t get “credit” for their work.
What can you do if you are in this pickle?
Consider asking the component teams to self-organize into feature teams.
Ask the teams and product owners to collaborate on backlog ranking for each team according to total feature. This will allow the teams to work together, as if they are in a program.
Ask one team to do the entire feature. Stop asking component teams to specialize in one component. That would allow the teams to see what the smallest value is, and implement that. (Repeat until you get the entire feature.)
Make the stories smaller to see the value build. When I see this, I often see very large stories. Too often, the teams work across the architecture, doing platform work, database work, GUI work, rather than see the simplest possible feature that would allow everyone to see the value.
I bet you have other alternatives you might consider. If you see other alternatives, please comment. I would like to help more teams see how to manage their interdependencies or remove them altogether.
November 19, 2015
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.
November 16, 2015
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.
November 2, 2015
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?
October 12, 2015
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:
Why agile in large enterprises and what are the challenges?
Where should you start?
Centralized? Decentralized? Where should agile live?
What is the one thing enterprises should do?
I had a number comments, which you should watch to see the entire context:
Agile requires cultural change.
Start with the people who want to change.
Agile should “live” everywhere.
Automate everything. And, retrospect to learn from what you have done and what you could do.
I had a terrific time along with my fellow panelists.
September 20, 2015
The discussion to now:
Resource Efficiency vs. Flow Efficiency, Part 1: Seeing Your System
Resource Efficiency vs. Flow Efficiency, Part 2: Effect on People
Resource Efficiency vs. Flow Efficiency, Part 3: Managing Performance
Resource Efficiency vs. Flow Efficiency, Part 4: Defining Accountability
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.