I call this the "Vicious Cycle of Distrust". Having been on both sides of this cycle, I'm quite familiar with the damage it does to a culture.
I've also seen the reverse of this cycle, I call a "Virtuous Cycle of Trust":
I've changed the term "management" to "leadership" because a significant purpose of leadership is to drive this cycle, to create safety and purpose. I've also called out "teams and individuals" rather than "developers" because the two act differently and teams are ideally more capable than just the sum of individuals.
I've also left some question marks at the interfaces as a question to you. What are the interactions and values that need to occur to drive a virtuous cycle of trust? To me these include:
- Focus. Because we focus on only a few things at a time, we work well together and produce excellent work. We deliver valuable items sooner.
- Courage. Because we are not alone, we feel supported and have more resources at our disposal. This gives us the courage to undertake greater challenges.
- Openness. As we work together, we practice expressing how we're doing, and what's in our way. We learn that it is good to express concerns, so that they can be addressed.
- Commitment. Because we have great control over our own destiny, we become more committed to success.
- Respect. As we work together, sharing successes and failures, we come to respect each other, and to help each other become worthy of respect.
I read an interesting exchange on Google+ about Agile process transformation successes and failures. Here is one of the comments. Tell me if it sounds familiar.
My previous employers had big problems with Agile. Attempted to use it multiple times and had a nice failure rate of 100%. As far as I know, they are trying again. I’m rather curious. Would be interesting to know how it turns out this time.
It’s hard to say this but I believe it’s ok if they’ve failed a few times, if they understand why and what needs to change this time around to be successful. Usually, they first need to become better planners and more predictable. The recommendation usually catches people off guard. I’ve interacted with Agile zealots who believe that doesn’t sound like Agile. Personally, I don’t care if it sounds like Agile or not, if we’re able to get teams to deliver consistently over time when others can not.
If you like it or not, I can pretty much guarantee that company mentioned above will fail again, if they don’t have the proper organizational structure, governance, and clearly defined criteria for progress and success. In other words, their agile process engine is going to stall.Priming the Agile Process Engine
Beginning an agile process transformation is like trying to start an old vehicle on a cold day. To add complexity, that vehicle has a carburetor and manual choke knob. If you’re old enough to remember carburetors and chokes, you’re either going to smile or wince thinking about starting a “cold” engine. The important thing to remember is if you don’t do the proper sequence of events, given the current environment, you’re going to stall. It could take an experienced driver only a few seconds of asking you questions to figure out what you did wrong and tell you what you need to do. Still, being told what you need to do is just treating a symptom. You, as the proverbial inexperienced driver, will need to learn new skills given the environment. It takes time, persistence, and finesse.Carburetors and Manual Chokes
When it comes to running gas powered engines, the only things old vehicles have in common with new ones is they all need a spark and fuel delivery. Getting a new one started is much easier, thanks to a complicated series of electronics, while starting an old one is dependent on what the temperature is and how well tuned the ignition might be.
If you’ve never started a car built before 1990, you need to realize that just turning the key won’t get the engine running. All it will do, especially if it’s cold, is crank away until the battery is dead as a door nail. Instead, you need to set the choke to allow the engine to suck in lots of raw gas so some of the vapor will ignite.
If your old car had a choke knob, you pulled it out to close the “butterfly” valve on the carburetor (this limits air intake, thus allowing a far greater fuel-to-air ratio).
I know this may be way too mechanically nostalgic or geeky for some but bear with me.
Now it’s time to start her up. With your foot pushing the gas pedal down about half of the way, crank the engine until it fires. It will usually start running, but rather rough. As you give it some gas you can slowly push in the choke knob until the engine smoothes out.
If you do it wrong, you’re going to flood the engine and you’re going to stall. The same goes for an Agile process transformation.The Agile Process Transformation
When you decide you’re going to transform your organization, don’t just jump into the driver seat, crank on the starter, and put your foot to the floor. It’s not that simple. For a car, you should be thinking about how long it’s been sitting or how cold it is outside. What is the current environment and state of affairs? For a transformation, you want to do some form of Agile adoption assessment. Understanding the current environment allows an experienced coach to know what the next crucial steps will be to ensure you don’t stall. Next, you’re going to want the proper organizational structure and governance in place. That’s right, you need to know the rules of the road. Lastly, you’ll need a system of measurements (metrics) in place to provide feedback and know when your transformation engine is warm enough or if your fuel to air ratio is still off. Are you giving it too much gas? Are you going to stall? Do you have both hands on the steering wheel at all times?
As an experience driver, you’d listen very closely to the sound of the engine as she tries to turn over. You’re prepared to either pump the gas pedal or adjust the choke knob. If you smell gas, you know it’s time to curse and let the engine sit a while because you just flooded the engine. More often then not, the experienced driver can react quickly because they’ve been through this before. It’s easier for an experienced driver to do it, then describe how to do it. Enterprise Agile coaches are experienced drivers.Agile Process Test Drive
When I was in high school, I took Drivers Ed. I sat in a classroom, reading book about cars and driving. Regardless of how much classroom training I got, it was really just teaching me the basics. Once I jumped into a simulator, I realized how complicated things could be. Here’s the kicker. The simulator was a controlled environment. Everything I learned up to that point got shelved, as soon as I got behind the wheel of a real car. There were so many variables! Not only did I have to figure out how to start the thing, I had to figure out how to accelerate and shift gears. I had to learn how to avoid that old person in the left lane who’s had the right blinker on for the last mile. And yes, in my youth, I crashed the car more than once.
Working with Agile teams is no different for the coach or the client. It doesn’t matter how many certification classes you take, it doesn’t matter how many workshops or conferences you go to, nothing can compare to being on the ground with a team and having a client who is insisting on results.Some Free Advice
When you were a kid, trying to start that 1979 AMC Pacer for the first time in 45 degree weather, you listened to your Dad or whoever when they warned you about the manual choke and what to be mindful of when you were ready to turn that key.Tips
- If you think you’re ready for an Agile process transformation, get an Agile adoption assessment.
- Be prepared to change your organizational structure.
- Get ready to harden up your ALM governance.
- Identify metrics that are going to provide you feedback as to conditions on the ground.
- Don’t text and drive!
Kleine Stories sind das, was wir uns wünschen. Aber warum? Was bringt uns das? Und warum schafft es der eine Product Owner, solche Kurzgeschichten zu schreiben und der andere schreibt ganze Romane? Diese Frage beschäftigte mich in einem Projekt, in dem wir skaliert mit mehreren Scrum Teams und daher auch mit mehreren Product Ownern arbeiteten.
Um diese Frage zu klären, suchte ich einen dieser Product Owner auf, von dem ich wusste, dass er sich für kleine Stories ausspricht und auch solche schreibt. Im entsprechenden Scrum-Team herrschte sogar die Absprache, dass Stories mit mehr als 5 Storypoints nicht in einen Sprint aufgenommen werden. Das Team arbeitete in 2-Wochen-Sprints. Der Product Owner, nennen wir ihn „Peter“, lieferte ein interessantes und sehr anschauliches Argument für das Schreiben kleiner Funktionalitäten, das ich genauer beleuchten möchte. Er sagte: „Ich stelle mir vor, dass mein Scrum Team eine kleine, eigenständige Firma ist, die direkt an einen zahlenden Kunden liefert. Dieser Kunde bezahlt natürlich nur für fertige und laufende Funktionalität, nicht für Entwicklerstunden. Wenn nun aus unerfindlichen Gründen der Strom ausfällt, das Netzwerk lahmgelegt ist oder andere unvorhergesehene Dinge eintreten, so bin ich bei kleineren Stories einfach sicherer, dass eine Arbeit und damit Funktionalität auch abgeschlossen und somit bezahlbar ist. Die Gefahr, dass eine Story nicht abgeschlossen ist, weil sie zu groß ist, ist mir wegen der schwierigeren Planbarkeit einfach zu groß und ich möchte die Firma nicht gefährden.”
Dieses Argument fand ich sehr einleuchtend. Natürlich würde ein Geschäftsführer einer kleinen Entwicklerfirma mit sagen wir sechs Entwicklern nie etwas anderes wünschen. Sein eigenes Geld und die Arbeitsplätze seiner Mitarbeiter sind ihm natürlich wichtig. In sehr großen Unternehmen, wo Kunden, Stakeholder und Manager oft weit weg zu sein scheinen, ist das möglicherweise anders. Es gibt keinen unmittelbaren Bezug und somit fällt es schwerer, sich in die Lage der kleinen Firma um die Ecke zu versetzen. Umso besser also das Beispiel von Peter.
Auch auf die Frage, warum nun der eine Product Owner kleinere Stories schreibt und der andere nicht, gab es aus Peters Sicht eine interessante und gar nicht so sehr fachliche Antwort: Er scheue sich nicht, im Gespräch mit dem Kunden in die Rolle des Beraters zu schlüpfen, der sich in den Kunden hineinversetzen kann. In deser Beraterrolle regelt er die Dinge so, dass sie funktionieren und nicht einfach nur gemacht werden, wie der Kunde es wünscht. Ich will nicht sagen, dass Peter seinem Kunden wiederspricht – er wagt es, auf sachlichem Niveau sinnvolle Diskussionen mit dem Kunden zu führen, um die richtige Lösung zu finden, ja sogar zu empfehlen. Aus Peters Sicht gibt es eben auch jene Product Owner, die den Weg des geringsten Widerstandes gehen, konfliktscheu sind und Diskussionen aus dem Weg gehen, was durchaus menschlich ist.
Für mich wird aber dabei deutlich, dass es trotz aller Technik auch um das Thema Persönlichkeit und Charakter geht. Es ist durchaus nützlich, wenn man es auch mal wagt, sich auf sinnvollem Niveau „unbeliebt“ zu machen und Diskussionen einzugehen. Im Sinne des Produkts. Aus meinen Erfahrungen als Berater kann ich jedenfalls sagen, dass jeder Kunde dankbar ist, wenn man im Sinne des Nutzens auch mal „widerspricht“ und einen anderen Lösungsvorschlag empfiehlt.
Provokativ könnte man also sagen: Die Tatsache, ob jemand große oder kleine Stories schreibt, beruht durchaus auf persönlichen Gründen und nicht nur auf technischen. Zusammengefasst und schlussendlich also die Frage: Was bringen uns kleinere Stories?
- Bessere Planbarkeit
- Höhere Zuverlässigkeit der Estimation
- Schnellerer Abschluss
- Größeres Verständnis der Story
- Häufigere Erfolgserlebnisse.
- Zufriedenere Kunden und Mitarbeiter
- Mehr Wirtschaftlichkeit
Ein Product Owner trägt die Verantwortung für die Profitabilität eines Produkts. Viel Spaß also beim Schneiden.
- Product Owner – Das unbekannte Wesen
- Was stört, ist der Kunde
- Der Kunde ist König, der Product Owner Kaiser
On Friday and Saturday, many of our users experienced 504 error and dropped connections. We apologize for these annoying events. We have a plan to make sure that it does not happen again. Thank you for your patience.What happened?
We were overloaded. We got too many requests for data from Subversion, and our firewall and proxy servers were overloaded. Load spikes from the repository servers disrupted both repository traffic, and Web traffic. The load came from game updates. Some of our users are hosting game content, and on Friday night, when a lot of gamers start up, thousands of them were pulling updates from Assembla Subversion servers.What are we doing?
- Rate limiting our repository servers, so that the servers in our private, high-availability datacenter cannot become overloaded in this way.
- Organizing our proxy servers so that repository problems cannot affect the Web app.
- Adding a high-throughput server in a public cloud datacenter, so that we can host games and other high-throughput applications.
A couple of years ago… gosh, probably more than that now… I got turned onto the idea of Shu-Ha-Ri by Alistair Cockburn. Alistair talks about this concept in both Crystal Clear and Agile Software Development: The Cooperative Game. While it’s been a few years since I’ve read these books, what’s stuck in my head is that Shu means Beginner, Ha means Journeyman, and Ri means Master.
The idea is that, when you are just getting started, you need to follow one way of doing something. As you progress, you’ll learn the limitations of that one way, and ultimately discover that there are other ways to achieve the same or better results. Once you have mastery, you blend and adapt approaches without even thinking about it. That’s the point where the student has become the master.
Quite often though, I hear people using the idea of Shu-Ha-Ri as a way to mandate that new Scrum teams follow the rules of Scrum by-the-book. In a sense, this is fairly consistent with Alistair’s quote from Ron Fox in Agile Software Development. The Shu level student is copying techniques without fully understanding why and that Shu implies an allegiance to a single instructor (page 18, 2nd edition).
I think this is fine when we are learning a given style of martial arts, but what about when we are applying process or methodology to a complex business problem? What if the teachings of the instructor aren’t working? What if the teachings are not applicable to our given context? Should the student blindly apply the teachings without understanding why and without modification?
I think that some of us have taken the concept of Shu a little too far. I think some of us bring a certain arrogance in believing that any one approach is applicable to any given student in any given context. That said, I do believe that as students we progress through a Shu-Ha-Ri process as we learn… it’s just that my Shu isn’t necessarily your Shu when it comes to process.
I have always taught that Shu means the beginner must have one way that can work. If we give the beginner too many choices up front, they won’t know how to choose and may be overwhelmed. As the student gains experience, that one way will inevitably have limitations and need adaptation. Once the student has achieved mastery, they can adapt and blend techniques as necessary.
Let’s say I want introduce agile into a large complex organization like the one I wrote about in my last post. I can teach team level Scrum all day long, but it won’t solve their fundamental business problem. The problem is too large and too complex for team level Scrum. For this organization, a Shu level approach might be an implementation of Leffingwell’s SAFe model.
While SAFe is more complex than Scrum, it may be minimally sufficient for the more complex needs of the enterprise.
When LeadingAgile engages an organization, we’ll bring our skills and experience with Scrum, XP, Lean, Kanban, and SAFe to blend an approach that is minimally sufficient to run that particular enterprise at scale. From the receiving organization’s point of view, this approach is a Shu level implementation… even thought we’ve brought Ha and Ri level understanding to help develop the solution.
Even though we have blended approaches to create the Shu level implementation, there are many more options available to solve even more complex problems. As the client learns, they will learn the limitations of our Shu level implementation and begin to adapt their own process. This is Ha level understanding. In time, and with practice, the organization will progress toward mastery and achieve Ri.
In summary… don’t confuse a Shu level implementation of enterprise agile with a by-the-book implementation of Scrum. Your organization may require more advanced mechanisms to implement agile at scale. What you need is one combination of approaches that works consistently while you are getting started. Once you’ve got that working… you’ll learn, inspect and adapt, and make it your own.
Check out the next post, Should You Use Agile To Build Your Next Home?
Check out the previous post, How to Structure Your Agile Enterprise.
The post Shu Level Agile Isn’t The Same As By-The-Book Scrum appeared first on LeadingAgile.
One of the best books on management I have ever read is Simon Sinek’s “Leaders eat last”. This book delivers a completely different message like most of the other books about management. Its core message is: As a manager you must treat your co-workers like family members. In his great talk (that you should definitely watch) Simon goes beyond the basics of his book. The real value of his book starts to shine when you reach about the middle of the book. He makes pretty clear that the real work of managers is to create a circle of safety that includes all people – from the top ranks to the bottom line.
It is a great book – read it. In this short movie he talks about the reason for the title of this book.
How would you visualize the value stream of a restaurant?
A great teaching example for a team wishing to start Kanban.
How do you like to visualize the concurrent activities of beverage service and meal preparations? I like to see them stacked (not sequential).
Hat tip to Derek Wade of Kumdio Adaptive Strategies for the simulation.
Partnership & Possibilities: A Podcast on Leadership in Organizations
EPISODE 5: RETROSPECTIVES FOR THE REST OF US
“Retrospectives help us define and examine a body of work, what we can learn from it, and what that tells us about going forward and then choosing those next steps to move forward.”
Running time 27:46
What would be useful for you to learn to incorporate retrospectives in your organization? Who would benefit from exploring this idea and how to do this kind of work in an effective way? How open do you think people in your organization would be to including retrospectives as a process for continuous improvement?
Leave a comment on this blog or email us at firstname.lastname@example.org
[Intro] Defining retrospectives for the rest of us.
[03:45] There are many different methodologies focused on continuous learning for continuous improvement.
[08:36] Encouraging openness and transparency when talking about improvement.
[11:28] Important to reflect on the specific action taken and to learn from it – each learning experience may be different.
[14:18] Engaging all the relevant stakeholders in the process is key.
[15:06] Retrospectives work best when there is a specific focus vs trying to improve everything.
[19:02] How are organizations embracing the idea of learning?
[22:34] Importance of creating safe spaces for people to share freely.
[25:35] The retrospective facilitator must be capable of understanding the needs and process for a successful retrospective.
Agile Retrospectives by Diana Larsen and Esther Derby
Adaptive Action by Glenda H. Eoyang and Royce J. Holladay
Chris Argyris: theories of action, double-loop learning and organizational learning
Seeing Systems – Unlocking the Mysteries of Organizational Life by Barry Oshry
Pedagogy of the Oppressed by Paulo Freire
A Guide to the Project Management Body of Knowledge (PMBOK® Guide) – Fourth Edition
Project Retrospectives: A Handbook for Team Reviews by Norman L. Kerth
If you were a satellite whose job was to capture high-resolution images while orbiting millions of feet above the earth, it would be important for you be agile: you’d need to be able to adapt to changing environments, produce results quickly, and listen to users’ needs.
As it turns out, if you’re the company operating the most sophisticated constellation of these commercial imaging satellites in the world, it’s important that your company be agile, too.
DigitalGlobe, the leading provider of earth observation and advanced geospatial solutions, started its agile journey a few years ago with a desire to transform its development practices and rethink how it does its planning. To start off on the right foot the company focused on "blocking and tackling," getting comfortable with the fundamentals of scrum and using coaches and training to guide the way. This has allowed the company to confidently scale its initial pilot of four teams up to 11 teams, adopt the SAFe (Scaled Agile Framework) methodology, and prepare to deploy agile at the program/portfolio level, across the entire business.
Want to know what a release planning session looks like at scale? One room, four agile release trains, and 250+ people, all cooperating to produce quantifiable results -- it's the picture of a well-oiled agile organization:
Along its path, DigitalGlobe enlisted coaches from Rally Services to train its own internal coaches. With the company now well-positioned to nurture the next phase of its transformation, DigitalGlobe's Director of Software Engineering, Ben Buxton, appreciates how the investment has paid off.
“They [Rally] are true partners, which is a nice thing to have in our toolkit as we’ve adopted agile and transformed our organization. Rally has helped us grow our teams, and then gifted us by growing internal coaches … they gifted us an internal culture. “
After five years of Scrum, we decided to break free of it’s shackles. Abandoning fixed length sprints, work-life became one long un-estimated party. Diverse collaborations throughout the organisation enabled us to take on new challenges. The backlog was full of surprises: I had little idea where half the stories came from. For a while I thought we were seeing, the beginnings of the hallowed Agile Organisation, but it seems the euphoria got the better of me. Drunk on the freedom, I ignored the signs that all was not well (a team member’s screams raised little concern) and today after a couple of years of experimentation we decided it’s time to end the party.
Last year was a challenging one for our company, our development team was being pulled in all directions by an influx of opportunities. Our cross-functional team became cross-functional pairs. We shared less, supported each other less and started to understand less about what each other were doing. We grew weary. The common goal was gone, replaced by pair goals, consisting of long difficult stories. Stories that deserved a whole team approach.
So today we decided to go back to a fixed length sprint with an unchanging backlog and a goal. A goal that the whole team is focused on delivering. I remember how powerful that felt when we first did it and we’re excited about doing it again.
That fixed sprint not only gives us focus, it wraps us in a bubble protecting us from changing priorities and challenging personalities. From inside the bubble we’re insulated from the dysfunction outside. I used to resent this bubble, I thought we needed more exposure to the reality of the business world around us, but know I’ve seen the effect it can have on creativity and quality, I’m happy to let the team keep their distance. I’m going to be a Rottweiler at the door of our team room.
I thought we’d grown out of Scrum, I admit to describing it as agile training wheels, but I’ve found a new love for it and it’s constraints. I’m glad I got a taste of what happens when you remove them, and perhaps there are organisations that will flourish when you do. But I wonder if there really is? Our anxiety too easily gets in the way of intelligent thought. A Scrum team can be protected from that, and be left to draw strength from each other. For now I’m happy to see the buzz return to the team and excited to see what we can build in the next couple of weeks.
Bobtuse can be wildly informative
Here’s a problem I encounter often. A middle manager calls me, and asks for an estimation workshop. I ask about the environment. The manager tells me these things:
- The developers meet their dates and the testers never do (this is not an estimation problem)
- The project starts on time, and the project staff comes in close, but not quite on time (this might be an estimation problem)
- The project starts off late (this is not an estimation problem)
When the developers meet their dates but the testers never do, it’s almost always a couple of things: Schedule Chicken, or technical debt masquerading as done in a waterfall project.
If the project starts on time and it’s close, it might be an estimation problem, assuming no one is multitasking.
But if the project starts late, this is not an estimation problem. This is a cost of delay due to management indecision.
Wouldn’t it be nice if you could say,
A lack of planning on your part does not constitute an emergency on my part
to your managers? Well, just call me the Queen of the Career Limiting Conversation. This is why managers are supposed to manage the project portfolio.
When I hear the plea for the estimation workshop, it’s for these reasons:
- The managers have received estimations for the work, and they don’t like the estimates they have received.
- Someone other than the project team did the estimation two years ago. They know the estimate is out of date, and they need a new estimate.
- The managers still can’t make a decision, because they are trying to decide based on ROI, date, or cost or some sort of hard to predict quantitative measure, rather than on value.
The managers are, ahem, all tied up in their shorts. The can’t decide, which is a decision. They don’t fund the potentially transformative projects or programs. They go with the safe bets. They do the same projects over and over again.
If they get lucky, they choose a project which is small and has a chance of success.
How do you discuss this cost of delay? You ask this question:
When did you first start discussing this project as a potential project? or When did this project first go on our backlog?
That provides you the first date you need. This is your next question:
When did we actually start working on this project?
You want to see how long it takes you to consider projects. It’s okay to consider some projects for a while. The difference between the time you first start discussing a project and the time you start working on it is your management cost of delay. I just made that up. I bet there’s a real name for it.
What is the difference in those two dates?
Project lead time is the time you started discussing a potential project and the time you finished it. Project cycle time is the time you started a project and the time you finished it. Yes, we normally discuss lead time and cycle time for features. But sometimes, it makes sense for projects, too.
If you release projects, not features, and you have managers who have decision problems, they need to know about this cost of delay. Because the project lead time will take time out of your maximum revenue. The longer that lead time is, the more it will take.
The worst part is this: how much value does the project have, if the project lead time is “too long?”
What can you do?
- Track your project lead times. Decide how much time a project can spend on the backlog in the project portfolio before you decide to transform or kill it. Yes, I am serious.
- Shorten all your projects, so you release something at least every six months, or more often. That provides you more capability in assessing your project portfolio and frees teams for more work.
- Move to an incremental lifecycle or an agile approach.
I didn’t say it was easy. It’s healthier for your organization.
Who do you think can measure this cost of delay in your organization? What do you think might have to change to make this cost of delay visible?
In Cost of Delay: Not Shipping on Time, Part 1, I introduced you to the notion of cost of delay. I said you could reduce the cost of delay by managing your projects: have shorter projects, using release criteria, or selecting a lifecycle that manages the risk.
Sometimes, you don’t have short projects, so projects get backed up, and your managers ask you to work on several things at once. Or, the managers can’t decide which project is #1. Somehow, you end up doing several things “at once.” This is the multitasking problem, and this is the cost of delay in this part.
You know me, I hate multitasking. The costs are significant. But those are just the costs of multitasking on the work you are doing now. That has nothing to do with the cost of delay to your projects.
In Manage It!, I have this nice picture of what happens when you try to multitask between two projects.
Imagine you have two projects. Each of them should take a week. Hey, they’re short projects. I’m trying to illustrate a point.
You can deliver one of them at the end of the first week. You can deliver the second one at the end of the second week.
But, imagine you have to multitask between them. Instead of being able to deliver anything at the end of the first week, you can’t deliver anything at all until the second week. And, depending on how much context switching you do, you might not be able to deliver anything until sometime during the third week. The blue boxes show the time lost due to context switching.
This is a huge cost of delay due to multitasking.
How do you calculate this?
“Big” is not quantitative enough for some people. This is where using some of the tools from the people who do this for a living might be good.
I’ve always drawn a picture like this and explained, “I don’t know how to estimate the time in the blue boxes. The blue boxes are the delay times. I can’t estimate them, because everyone else is delayed by multitasking on their projects, too. Sometimes, it takes me an entire day to get an answer to a question that should only take me an hour to get an answer. All I know is that “ideal” time is irrelevant to actual time. And even calculating using relative estimation is hopeless. That’s because we are multitasking. All of our estimations are out the window because we are multitasking.
“The amount of time we spend working on a project might be accurate. It’s the wait time that’s killing us. I don’t know how to estimate that.”
What I’ve done before is take a two- or four-week window, and ask people to write down their predictions of what they thought some task would take. Then, I ask them to write down, as they spend their time on each task, how much time they actually spend on each task. Now you can compare the prediction to reality.
Remember that all of the context switching and wait time is the time you need to remove from the maximum sales revenue, had you released the product.
This is very difficult to do. It saps the morale of the people doing the work. They quickly realize how often they go back to the same thing, over and over and over again, making zero progress, trying to realize where they are. Do not do this for more than a four-week window. If you must do this, label this an experiment to obtain data. Explain you are trying to obtain actual work time, context switching time, and wait time. Let people label the time as they will.
The managers will be astonished by how little time the technical staff spend on real work. They will be amazed by how much time the technical staff spend on context switching and wait time. This is why managers think technical staff are bad at estimation. Who can be good at estimation when they are multitasking?
The problem is this: the cost of delay due to multitasking is real. It’s invisible to most people, especially management. It’s not just the cost of the blue boxes in the picture above. It’s the fact that nothing gets out of your organization until the end of Week 2 or later. Remember the back of the napkin in Part 1? Even if you use that calculation, you can see you are losing revenue left and right due to multitasking.
Remind the managers: Remember that all of the context switching and wait time is the time you need to remove from the maximum sales revenue, had you released any of the products.
Can you use this as an argument for your managers to end the multitasking and manage the project portfolio?
Cost of delay due to multitasking is real. What would you need to know to calculate it in your organization?