Unfamiliar technology requires an experimental, safe approach.
Unfamiliar Technology With No Safety Net — A Story
I have often fallen prey in my career to jumping into a new technology thinking, “I’ve got this.” My mind would immediately associate the new technology with my past experiences. But as with anything new, old patterns do not hold true and slow you down. I had no chance to control the situation.
Technology is always changing and unfamiliar to teams. As such, the coaching should guide the team to experiment in a safe manner.
A story will best illustrate the importance of safe experimentation with new technology. I will continue the tale of the Eagles team from the prior post.
This team is now starting to build working software for its more certain feature ideas. Real events form the thread of this story, but I have fictionalized it to protect the innocent. Post story, I present a coaching strategy for a team dealing with unfamiliar technology, such as the one described.
Part 1: Chasing Tails
I arrive at the office early Monday morning eager to get a head start prepping for the week. As I exit the elevator I notice David, the Eagles team Scrum Master frustrated at his desk. He is typing numbers into a spreadsheet. His demeanor is anxious. I quickly finish half of the egg & cheese sandwich from the coffee shop.
“Hey, David, you are here early.”
He does not look at me. “I’ve been here for two hours working on this detailed project plan for Paul.” Paul is the primary product stakeholder. “The team and I have spent all weekend breaking down the backlog. We are estimating the remaining release work.”
Wow. That might be a record for encountering an anti-pattern this early on a Monday. Breaking down a backlog and attempting to estimate it is often driven by the need for certainty. A dog has about the same chance of catching its tail as a team has in predicting an end date for product development. Plus, working over the weekend is likely creating an unsustainable team situation.
The Eagles have the complexity of a new product and unfamiliar cloud technology. I consider how to respond. “Why the fire drill?”
“Well, we’re in our fourth sprint and have not met any of our sprint commitments. Paul is not happy, and wants a detailed plan. He feels it will motivate us to have a delivery deadline.”
That word—commitment. It causes dread in teams. Negative reactions to missing commitments results in wasteful investigation, demoralizing blaming, and needless worry. In 2017, Jeff Sutherland and Ken Schwaber replaced the word commitment with forecast in The Scrum Guide. This was for a good reason. Forecast allows for uncertainty while commitment denotes certainty. Product development is rarely certain.
“Why has the team not met their Sprint forecast?” By avoiding the word commitment, I hope I can turn this conversation around.
“Forecast? You mean commitment? Paul will not settle for anything less than an end date for the release and a commitment by our team to meet it. He said he’s tired of us not showing progress.”
So much for a word change helping. “What is the team saying is the reason for the unfinished work?”
“You know, Todd, all they can tell me is how unsure they are of everything. They are reluctant to size anything without a laundry list of requirements and assumptions. Can you come to our estimation session at 9 AM? That should help you understand the situation. If you don’t mind, I need to get back to this plan.” He turns back to the spreadsheet and continues crunching the numbers.
I look at David and start assessing how I can help him. The team is in full contract mode and David is starting to lose trust in them. So much for Customer Collaboration over Contract Negotiation. “Sure, No problem. I’ll see you at 9.”
Part 2: Unfamiliar Territory
I enter the team room at 9. David is already hooked into the projector, displaying the estimation spreadsheet.
The team looks exhausted. They are all on their smart phones attempting to escape the situation. David is asking Tom, the technical lead, to provide effort estimates on each item in the spreadsheet. Team conversation and collaboration are absent.
“Hi, guys. I’m just observing. Carry on,” I say as I sit in the back of the room.
David at one point turns to the team and asks, “Do you guys agree with Tom’s estimate on the Search feature?” There was dead silence as the development team looked up from their phones. Ty said, “If anyone knows the effort with this new Cloud service, it’s Tom. He is the only one on the team with any Cloud expertise.”
Tom said, “I may have cloud experience, but I am as new to these services as you guys.”
This is typical team behavior when uncertainty is high—defer estimation to team members with any form of experience. Believing experience will provide more accurate estimation is flawed. The experience is typically context sensitive and not relevant to the current work. The team inexperience is also not being reflected in the size. The lack of team conversation here is preventing a shared understanding and producing a worthless estimate.
It is obvious that nobody is sure of how the new Cloud service works. In highly complex, uncertain scenarios, it is best to learn through experimentation. Instead of experimenting to learn, the team has fallen back to a bad habit of big planning up front to reduce risk. I make some notes and get up to leave the meeting.
“Hang in there team. I’ll see you in tomorrow’s Daily Scrum,” I say on my way out.
Part 3: No True Version
The Daily Scrum started on time. Everyone seemed anxious.
Ty spoke up first. “I’ll be the first to say it. There is no hope in us making our sprint goal,” he said with a somber glance at his teammates. There were two days left in the sprint. “We all checked in our code yesterday and ran it through our CI tool. It’s broken…broken bad. The entire regression report is red.”
I have seen this anti-pattern many times before. It is common for teams to have all the latest and greatest continuous integration tools. But they fail to use them in a continuous manner. As a result, defects lurk undetected. There is no true, verified working version of the code during the sprint.
“When was the last time you guys had a clean run of your Sprint code through the CI tool?” I ask. I hope they can assess the difference between this bad result and the last successful run.
They all looked back at me. It was complete silence for a beat.
“This was the first time we have run the CI this sprint,” Ty said. He had a forlorn look as he stared at the floor.
Well, there is the problem. The team has been operating with individual development machine branches. This is the first integration attempt in eight days. The only true version of the code was the development main line that started the sprint. I make a mental note for the Retrospective.
“There’s nothing else we need to discuss,” Gwen said. “Let’s start trying to unwind this red CI report.”
Part 4: It Can Wait Until Tomorrow
I stayed with the team after the standup. I tried to lift their spirits. I say, “The good thing is that we’ve identified an area for improvement.”
“Ha. That’s the understatement of the year,” Ty said. “This isn’t an area for improvement, it’s a wasteland.”
Gwen pulled Ty over to her desk. “I found one of the defects causing the build to break. I made this change to the signature of this method to calculate the sum of the costs. Your feature is calling that method,” she said.
“You are right, Gwen. Put it on our defect wall. I will get to it tomorrow after I go through the rest of the errors from the CI report.”
Gwen walked over to a wall full of sticky notes. The title on the wall read: This Sprint’s Defects.
I felt that uneasy sensation in the pit of my stomach. This team is not treating defects as a “stop the line” priority. Even the ones they detect early are being deferred.
“What happens to defects that you find in the sprint but are unable to fix before the sprint ends?” I ask. I know the answer before Ty responds.
“We put those in the defect tracking tool. We plan on taking a look at all the defects during the hardening sprint before we deploy to production. I’m sure most of these defects will not be a priority to fix before launch.”
Defect deferral. Hardening sprints. Defect Prioritization. These are the hallmarks of an unclean codebase. Even if a team is integrating often, defect tolerance creates clutter. And it makes the code brittle. Defects have a way of spreading disarray the longer they exist. Without a daily focus on keeping the code clean, the defects pile up and slow the team’s progress. This slowing continues on an exponential path until the team stalls and morale sinks.
“Guys, what day and time is your Retrospective this sprint?” I ask, smiling to hide my concern.
“It’s on the last day at 2 PM after the Sprint Review. With the way things are looking, we’re going to have to cancel both though,” Gwen says. She is talking with her back to me as she studies code on her monitor.
“It is never good to cancel the Sprint Review and the Retrospective. We need to reflect and adjust…especially when the going gets tough,” I say. “I’ll catch up with you guys later.”
I head off to speak with David to ensure we keep the Sprint Review and Retrospective on the calendar. We will have much to discuss in those ceremonies. Namely, we need to discuss the desire for certainty in the midst of uncertainty and the lack of clean code practices.
When You Don’t Know, Try Something
When faced with new, unfamiliar technology uncertainty is high. Uncertainty makes teams and stakeholders uncomfortable. In the desire for certainty many teams and stakeholders turn incorrectly to:
- Setting a date to motivate teams to deliver
- Creating detailed plans and estimates to create a sense of control
- Spending time designing in an attempt to create certainty
- Asking team leads with more experience to provide estimates for the team
- Over reliance on past experience in other technologies
Thinking, planning, and designing does not increase knowledge in a new technology.
Instead, the team should try to use the new technology. Trying an experiment with the new technology will result in rapid learning. This learning will begin to steady the team and build their confidence in the new technology. Experiments are an investment worth making due to the knowledge gained.
Small, rapid experiments are critical in the midst of high uncertainty. The small experiment reduces costly impacts when the experiment does not work. It also promotes a high learning velocity. Small experiments increase safety.
Do not have a team waste time creating a plan and detailed estimates. Instead, support team in learning by trying. Encourage the team to identify uncertainties fast and execute small experiments to learn.
The Quest for Daily Clean Code
The pattern for Daily Clean Code1 preserves sanity amidst new, uncertain technology. In fact, it is a solid pattern to strive towards for any product development team.
Figure A depicts the essence of the Daily Clean Code pattern.
Daily Clean Code Pattern Facts
The pattern centers around three facts or truths.
Fact 1: Disorder Breeds Disorder
When the code is not clean, it invites further disorder. Defects breed defects. Unclear code invites unclear code. Sloppy adherence to coding standards invites further non-standard coding practices. Duplicate code invites duplicate code. I could continue, but you get the point.
To illustrate this concept, consider your garden shed. Imagine you finished using a hammer for a household task, and you go to the shed to put it away. What are you likely to do with your hammer in the following two scenarios?
- A clean shed with all tools and equipment in their place.
- A shed with tools scattered on the work table and used yard equipment blocking your path to the tools.
Consider a shed in disorder as in the second scenario. If you are like me you will throw the hammer towards the work table and get out of there as quick as possible.
But if the shed is clean and everything in its proper place, there is strong pressure to keep the order. You and I are much more likely to put the hammer where it goes when faced with a clean shed.
I also find it interesting that if only one tool is not in its place, it will invite your tool to join it.
Fact 2: Disorder Slows You Down
When the code has disorder, it slows you down. New features become harder to develop as you have to work around the disorder. It takes you longer to understand the code when maintaining it. You may build an existing defect by mistake into your new feature and make the situation worse.
The unresolved defects accumulate over time. At some point, they become a huge roadblock, requiring extensive effort and time to remove. The roadblock becomes so large and uninviting that the team avoids it. It will continue growing until it impedes rapid response to change. Then, you have no choice but to address it. In this situation, nobody is happy.
Let me explain by continuing with the shed analogy. If your house needs a repair and your shed is in disorder, the tools you need are not easy to find and ready for you.
Once you find the tool and start the repair, if you are like me, it is likely the wrong tool. When you go back to the shed, you will likely throw the wrong tool back in the pile. And then you will take great pains to search for the necessary tool.
In this situation, taking time to clean up the mess is not considered. Cleaning the shed gets in the way of making the repair. Each new job adds new used tools to the pile.
Before long you can’t even enter the shed due to the mess. At this point, you have no option but to clean the shed before you can even address your latest repair need. This is an unhappy moment.
But with a clean shed, making your repair becomes a joy. All tools are in their place and ready for use in the repair job. The clean shed encourages you to keep it clean as you trade one wrong tool for the right tool. This will compel you to put your tools in their place at the end of the job. Your clean shed prevents a big mess from accumulating. And no one wants to clean up a big mess.
Fact 3: Being “Done” Includes a Clean House
Often when a team talks about being “Done,” it is about the code. But the environment in which the team works is also important. It is so important that it is part of being “Done.”
A clean environment includes updating information radiators, checking in code, and staying in sync with team members. You could argue that tidying up your team area could be part of this mindset. Imagine how nice your morning routine goes when everything is ready to support the work of the day.
Once more, the shed analogy can help. Imagine you finish your repair job. If you neglected to clean your shed as you work, can you consider the repair done? How does it feel to finish your repair but know you did not put your tools back and clean your work area?
The feeling is neither one of satisfaction nor of a job well done . The repair is not done unless the tools are back in their proper place and the work area is tidy. To achieve a state of ”Done,” the work area should be ready for the next repair job.
Daily Clean Code Pattern Actions
These actions may seem daunting if your team is not practicing Daily Clean Code today. Do not worry. You should not attack all these actions at once. Practicing Daily Clean Code is not about staying at work all night until the code is clean.
Instead, understand your current state against the challenge of attaining Daily Clean Code. List out reasons you cannot perform these actions today. Treat the gaps like impediments. Use your retrospective to identify a key improvement each sprint. Then, experiment to make the improvement a reality. This process will make incremental improvements and get you closer to Daily Clean Code.
There are three pattern actions for pursuing Daily Clean Code.
Action 1: Clean Workspace Daily
This act seems easy but requires forming new habits. You must place everything in your environment in order before you leave for the day. Keep your desk clean. Update your Story board. Talk to your teammates about what you achieved and where you struggled. Check in your clean code (I will discuss this more in the next section).
This will keep everything in order. So when you and the team arrive the next morning, everything is in its place and ready for the day’s work to begin. This one step will add sanity and help every day start and move better.
Action 2: Get the Product to a “Done” State Daily
“Done” means production shippable code that is working. Your team has resolved all detected defects. Does this sound simple? It is not. It takes discipline. Adding in “daily” increases the challenge.
Getting here requires automation for builds, deploys, and testing. The overhead of manual activities will take too much time if we aim for clean code at the end of every day.
Small batches are key. Keeping a story or task open for many days is no longer an option. New work must be small and contained.
Swarming as a cross-functional feature team on the small batch of work will also help. Couple swarming with a “Stop the Line” mentality for defects to achieve a “Done” state daily. For more on cross functional feature teams, see this prior post. For more on swarming and the “Stop the Line” mentality, see this prior post.
True continuous integration is not as simple as using the latest toolset. The goal is to always have one true, verified version of the code after each commit to the source repository. Figure B illustrates this concept.
When beginning a change, you get a copy of the mainline and then make your changes.
Once you make your changes and all regression tests pass, you get another copy of the mainline and ensure all tests still pass.
Then, you attempt to commit to the mainline. If all tests do not pass, roll back your commit and fix the issues. Then, and go back through the commit cycle.
When all tests pass, consider the commit done. All other developers can now update their local machines to use the new true version of the source code.
Action 3: Apply the Boy Scout Rule
This last action is simple but powerful. Boy Scouts have a rule that states they should always leave a campground cleaner than the way they found it. If they find a mess on the ground when they arrive at camp, they clean it up even though they did not make the mess.
A developer should have the same mentality when they begin a modification of the code. If a developer finds something awry when making their change, they should fix the problem.
There should be no discussion of ownership. The developer will take ownership of fixing the problem as if they had introduced it.
Also, the developer should clean any mess that they make in the code. The code “campground” should be cleaner than the way they left it.
This is a great pattern for refactoring technical debt as it accumulates in the code.
Story Analysis and Coaching Strategy
In the story above, the Eagles team is experiencing two primary issues. First, in an attempt to remove uncertainty, they turn to planning. In doing so, they forego the power of Learning by Doing. Second, they are not practicing Daily Clean Code.
The Eagles team requires coaching to intervene before these habits harden.
Coaching Game Plan
The Toyota Improvement Kata2 is an effective, targeted improvement technique. Teams can use it to meet a challenge, such Learning More By Doing or achieving Daily Clean Code.
In the case of the Eagles, this technique would first train the team on Learning More By Doing and Daily Clean Code. The learning focus will define the concepts of these two patterns. A key takeaway will be why the patterns are more effective than their current state behavior.
Then, the coach will co-create a improvement approach with the team and management. The approach will aim to achieve the challenge of Daily Clean Code. The first target condition will be to Learn More By Doing. The team will meet the challenge through a scientific method of incremental improvement. Figure C shows this method applied to the Eagles team.
Improvement Kata Formation and Coaching
First, the coach asks the team if they want to set the challenge. If the team does not agree, the coach stops the process. A team must desire to take on a challenge; imposing it does no good. Yet, if they agree to set the challenge, the process continues.
Second, the coach asks the team to self-reflect where they currently stand. It is key to engage the team in reflecting on their current condition. This will allow the team to self-assess their primary needs. Resist the urge as a coach to provide your own observations.
Third, the coach and team set the first target state towards the challenge. For example, the first step for the eagles team on its journey to Daily Clean Code is to Learn More by Doing versus planning and estimating.
Fourth, the coach collaborates with the team to outline the first experiment. The team provides their own ideas. The coach suggests options from his or her experience. It is important for the team to select the experiment they will try first. In our example, the team decides to select its most uncertain technical challenge for its “try” experiment.
With a team starting on its journey, the coach needs to have a high touch approach. This allows the coach to correct the team during experiment execution. By correcting in the moment, the coach helps the team avoid the seep-in of old habits. The coach is able to provide expert guidance on the correct implementation of the new habit. This results in faster formation of the correct new behavior habits.
The co-creation of an improvement strategy produces buy-in. The experimental approach introduces small changes, which allows learning patterns time and space to form. This approach helps the team achieve tough challenges and to practice using the scientific method.
Wrap up
The context of a team’s technology state is key to the coaching strategy you select. It is tempting to treat every team the same and start applying standardized patterns. Yet, the more prudent approach customizes coaching to the team’s technology context.
Learning More by Doing and Daily Clean Code are two patterns that can help a team with uncertain technology contexts. How will you and your team embrace these patterns to gain control of your technology uncertainty?
This post concludes the series on Customizing Agile Coaching to a Team’s Context.
Other Posts in the Series
- Customizing Agile Coaching to a Team’s Context—An Introduction
- Customizing Agile Coaching to a Team’s Social Context – New Teams
- Customizing Coaching to a Team’s Product Context—The New Product
Related Posts
- Remove Date Driven Behavior to Achieve Agility—Learn More By Doing
- Gain Control By Breaking Dependencies: Task Level Part 1
- Gain Control By Breaking Dependencies: Task Level Pt. 2b
References
- Good Housekeeping aka Daily Clean Code, Scrum Published Library of Patterns
- The Toyota Kata by Mike Rother (2010)
Todd Lankford unlocks Lean Leverage in organizations to cultivate powerful, engaged product teams who maximize outcomes and impact.
His articles share his experiences and learnings along the way. Join the mailing list to get them in your inbox.