- Agile Leadership Development
- Product Owner
Change can be scary. Change at work is particularly threatening. After all, most of us spend more time working that doing any other single thing. Even a potentially good change, one that promises a better future, is risky. The better future might not pan out. It might be worse than the status quo. It’s that risk that makes talking someone into accepting a change so ineffective.
To gain acceptance of a proposed change, stop trying to persuade on the merits of the change. Very few changes have to be permanent, so you don’t need to convince people to accept the change forever. Instead, look at ways you can remove the risk, ways to make the change undo-able. Frame your change as an experiment that can be rolled back if it doesn’t work. Set a date to evaluate the results and make a decision whether to continue with the change or roll back. And then stick to that plan, even if the change is going overwhelmingly well. It’ll remind people that you’re trustworthy and that when you propose an experiment you really mean it—you’re not just being sneaky.
When you consider how long to make an experiment, remember that it can take 21 or more repetitions for a new practice to become a habit. Think about the learning curve associated with your change. Try to make the experiment longer than that initial learning, habit-building period.
Scrum’s sprints and retrospectives give you a nice built-in cycle for experiments. It’s easy to propose trying something for 1, 2, or 3 sprints, to be reevaluated in the corresponding retrospective. Want to adopt TDD or pair programming? Want to move QA people into your team? It doesn’t have to be permanent. Just try it for a few sprints. Maybe measure cycle time or defects while you do it. If it doesn’t work for, you can always go back to what you’re doing today. It’s just an experiment.
In agile it is often counterproductive to use the title of “manager” for any role. Manager tends to imply command and control which is just not present in an agile environment. I often have teams struggle with this basic concept. Read More
Welcome to the “Making Agile a Reality™” blog! I’m hoping to use this blog at least weekly to accomplish several things:
- Capture my thoughts about agile software development
- Answer questions I receive
- Give examples of best practices I observe
- Point out interesting content created by others
- Have fun!
Maybe not in that order (I kind of like #5 best!).
I’m keeping this one short because I don’t want to dilute it with my normal rambling. Feel free to email me from the Contact Us page and ask questions. Who knows, I might answer it here in my blog!
Two Hours of Waiting, an Hour and a Half of Waste, and a Burrito
One day last week, I took what was supposed to be a quick lunchtime ride to my local bike shop to have a faulty bike computer fixed. Unfortunately, it turned into a two hour illustration in how multitasking harms lead time, predictability, and customer satisfaction.
I arrived at 10:15, just after the store opened. I explained my problem, and they immediately assigned a mechanic to put a new computer on the bike. I asked how long it would take. “10 or 15 minutes,” he said. So I went out to a bench to work on email.
Twenty minutes later (allowing for some estimating error), I went back to pick up my bike. They were still working on it. But now, instead of just my bike on a repair stand, there were three more. I watched them start work on two more as customers brought them in over the next few minutes. That’s six bikes being worked on. Or, more accurately, six bikes on repair stands—there were only three people working in the store, and at least one of them needed to be available in the retail part of the store for sales.
I waited in the store for another 20 minutes or so. A few small repairs went out and a few more came in, but my bike still wasn’t done. My granola bar breakfast was wearing off, so I gave up waiting there and crossed the street to get a burrito for lunch. When I came back 40 minutes later my bike had just been finished.
What happened? Was the mechanic just bad at estimating the job? I don’t think so. Installing a bike computer definitely can take longer than you might expect—it’s hard to get the cable length just right. But if he’d focused on just that job, he’d have finished in 15 or 20 minutes, certainly within a half hour. Instead, he bounced back and forth between my bike and three or four others. Everyone’s repair took longer than it should have and longer than he estimated. By multitasking, he undermined his ability to predict completion times. Who knows what jobs would come in while he was working on mine? In exchange for that lost predictability, he gained the appearance of responsiveness as he started each job quickly.
It’s Not Just Bike Shops
Software organizations do the same thing. In fact, I often tell teams that if my job was to destroy a team’s productivity, the first thing I’d do is find ways to get them multitasking, to increase work in process (WIP). Increasing WIP is well known to increase lead time, even with immediate switching between tasks. The time required to switch tasks in knowledge work like software development makes the problem even worse. It doesn’t take much WIP before more time is spent switching tasks than actually completing them.
Agile approaches like Scrum and XP help somewhat; they get teams working on prioritized, well defined chunks of work. But I often see organizations in which key resources like system engineers or DBAs are assigned to many projects. As these people multitask across several projects, their availability to each individual project becomes unpredictable. Then, when work on a feature hits a dependency on one of these scarce resources who’s not available, the team moves onto another feature, increasing their own WIP. I’ve seen teams with shared resources frequently reach the end of a sprint with every sprint feature in progress and none complete, all either waiting on a dependency or with too much work to complete after the dependency was resolved.
How Do You Fix This Problem?
- Start with a presumption against multitasking. Use an approach like the 5 Whys to dig into why someone needs to be assigned to multiple projects.
- Reduce dependencies on shared resources. Look at the tasks they do and consider which tasks really have to be done by that person and which could be done by other team members, perhaps after some training.
- If you can’t fix it now, make it more visible. For example, modify your task board to feature the task area where things get stuck. Or put up a big number representing the current stories in process. (More on these options, including examples, coming in a future post.)
- Get some help. Sometimes, it takes an outsider to point out to management that they’re sabotaging their results by forcing their team to multitask. It often seems like half my work as a coach is saying the things everybody knows but nobody can say.
Kathy Sierra tweeted: “The big Q: how much does the *perception* of working in tech need to change, and how much does the *reality* need to change?”
I’m focusing my career on the belief that tech work is *really* messed up and that it doesn’t have to be. If a team I coach gets more productive but doesn’t get happier, I haven’t done my job. The big win with agile/lean/TOC is that they align work with how humans actually function: limited attention span, need for community, continuous learning and limited ability to predict the future, need for frequent positive reinforncement.
In my experience, the daily Scrum serves two purposes:
- for team members to make and follow up on commitments to one another, and
- for team members to raise and start resolving impediments.
Both these purposes are directed towards reaching the Sprint goal.
I started coaching a development team in an IT department this week. Most of the team is officially full-time on their project, but unlike the consulting teams I often work with, no one is ever really full-time on a project. There are production apps to support, people management issues, requests for technical help from other projects, non-project meetings, and a variety of other distractions.
Observing this team’s daily Scrums, I noticed that they talked a lot about what they did in the past 24 hours and what they would do in the next 24. Everyone seemed busy and could account for their time. But I had a hard time connecting their busyness to the work they’d committed to do in the Sprint.
So, I suggested a slight change to the three questions that I learned from Mishkin Berteig. Instead of answering the questions, “What did you do in the last 24 hours?” and “What will you do in the next 24?,” I had the team answer the questions, “What did you complete in the last 24 hours?” and “What will you complete in the next 24?” I recommended that they point at tasks and stories on the task board while answering the questions to keep them focused on the work for the Sprint.
There were some objections:
“But I’ll feel uncomfortable saying I’m not going to complete anything today…” To which I say, “Good. You should feel uncomfortable if you’re not helping the team follow through on its commitment for the Sprint.”
“But our tasks are too big to complete in a day…” “Many of them are. This will give you an incentive to make them smaller in the next Sprint, which will increase your visibility into the state of the work.”
Nonetheless, they agreed to try it, and I’m glad they did. The change in the daily Scrum with the new questions was striking. Conversation was more focused on their commitments. Since team members couldn’t use work from outside the project to show how busy they were, they were motivated to fight the distractions and find project tasks they could commit to. The few team members who are spread across multiple projects now can see clearly where the multi-tasking is hurting their commitments to this team.
If your daily Scrums seem unfocused, even though everyone has lots to talk about, consider changing the questions to change the team’s behavior. Just one word can make a big difference. Try asking each other:
- What did you complete since we last met?
- What will you complete before we meet again?
- What impediments are keeping you from completing something?
He says, “…I suddenly realized, the conductor of an orchestra doesn’t make a sound. My picture appears on the front of the CD. But the conductor doesn’t make a sound. He depends for his power on his ability to make other people powerful. And that changed everything for me. It was totally life changing. People in my orchestra came up to me and said, ‘Ben, what happened?’ That’s what happened. I realized my job was to awaken possibility in other people.”
And, oh, how he can do it. I can’t recommend his book, The Art of Possibility, strongly enough. I give copies away as fast as I can buy them. Enjoy the video and get your hands on a copy of the book.
Martin Fowler nails it (as he so often does):
My point is that we can’t look at testing mechanistically. Unit testing does not improve quality just by catching errors at the unit level. And, integration testing does not improve quality just by catching errors at the integration level. The truth is more subtle than that. Quality is a function of thought and reflection – precise thought and reflection. That’s the magic. Techniques which reinforce that discipline invariably increase quality.