Becoming Awesome — Creating a Culture of Continuous Improvement

Becoming Awesome — Creating a Culture of Continuous Improvement

Continuous improvement is the very heart of agile development. It’s the culture and the mechanism that allows teams to adapt to changing circumstances. Yet it tends to be the first thing teams abandon when they get complacent in their agile development methodology. It takes work to envision an ideal and constantly strive to be better today than you were yesterday. In the fast-paced and high-pressure world of technology, it’s too easy to get so caught up in the work that we forget about the workflow. I’d like to share with you an exercise that I do with all of my clients, which creates a foundational culture of continuous improvement upon which all of our transformational goals can be successful.

Creating a Culture of Continuous Improvement

Continuous improvement goes well beyond the retrospective. It requires the team to be inspired and motivated to be their best selves. It requires trust and empathy within the team, with other parts of the company, and with your customers. It requires constant reflection and introspection, and always questioning established norms.

Definition of Awesome — If you want to strive for perfection, you must first envision the ideal. In this standalone exercise, we identify the values, principles, and behaviors that embody a peak performing team. This becomes the mirror that we hold up to ourselves constantly to identify ways we need to improve.

Daily Reflection — It’s not enough to pay lip service to continuous improvement for 30 minutes every two weeks. How many times have you shown up for the retrospective and couldn’t remember any meaningful issues that happened in the last sprint? We have to identify issues in the moment. I recommend a five-minute personal retrospective at the end of each day where you think back over the course of the day and take note of anything that went particularly well or poorly.

Accountability — Accountability means taking ownership and responsibility for the performance of not just yourself, but the entire team. When you work with stakeholders, you represent your team. When you work with customers, you represent your entire company. We must create a culture, as well as a system of rewards and incentives, that motivate people to put the common goal over their own self-interests.

Continuous Learning — It’s amazing how quickly we lose objectivity when we spend all of our time in our own bubble. It is critical that we continually search for knowledge outside of our team. Support a culture of continuous learning that includes networking, reading, taking courses, and exploring new technologies. Encourage teammates to share this knowledge with the team and give them time to play with these new tools or ideas.

Challenge the Status Quo — The essence of continuous improvement is always asking yourself “could we do this any better?” Encourage new ideas and ways of working. Reward risk taking and even failure. Support constructive conflict, where the team challenges each other in order to achieve a greater result.

Effective Feedback — In order for teams to rapidly improve, they must be able to trust each other and challenge each other directly. This is impossible if they can’t provide open and honest feedback. Tight feedback loops are the core mechanism of agile development, and the same applies to personal interactions. I will go more into this topic later in this article.

Areas for Improvement

There are many different ways a team can improve. Some ways involve technology and some ways involve people. Keep an eye out for these kinds of issues, make note of them, and look for ways to improve during your retrospective.

Communication

Unclear Direction — I’ve always said there is no less efficient way of working than to be working on the wrong things. So much of the failure our development teams encounter are a result of unclear direction from our leaders and product owners. A lack of vision or product strategy makes us unable to plan ahead. Unclear or ambiguous user stories and acceptance criteria cause us to miss the target. This issue is so critical that it’s become a major focus of my consulting practice.

Lack of Organization / Coordination — Building a product is a difficult, complex process, and is exacerbated by a lack of coordination between individuals and teams. So much waste occurs because information is not adequately shared among the team members. The silo effect is real, and it’s amazing how small of a team in which it can arise.

Personal Conflict — Sartre said, “Hell is other people.” You can build technology and apply process all day long, but there is no substitute for positive working relationships. It’s imperative that we take conflict seriously, and work through issues before they fester and tear the team apart.

Lack of Transparency — Communication goes both ways. While engineers should expect clear direction, they also must communicate clearly how the work is progressing. Too often, development teams do not appreciate the importance of delivering on their commitments, and the impact it has on the rest of the business.

Workflow

Incomplete Hand-Off — Product development is a single process of transforming ideas into usable technology. Every time there is a hand-off, from product management to design, from design to development, or from development to QA, there is an opportunity for failure. In my practice, I look very closely at the transitions of work between teams and often find the interfaces aren’t well aligned.

Dependency Delay — Any time there is a hand-off between teams, there is often a lack of clarity about when the work will be delivered. We all know how bad we are at estimating. Look for delays in transitions between teams. Often simply communicating the delay as early as possible will allow the downstream teams to work on other things and not affect overall productivity.

Requirements Churn — Unclear direction causes repeated rework and delay. Look at how many times a story is updated during a sprint, or how many times it vacillates between states.

Scope Creep — The bane of any developer’s existence, scope creep causes the team to fail at delivering value to the customer. While it’s fine to change software after it’s released, the constant growth of scope during a release cycle delays the delivery of customer value, which is a core tenet of agile development.

Technology

Technical Debt — I’ve written about technical debt in another article, but suffice it to say it plagues every product to some degree and should be consistently managed and worked on.

Lack of Proper Tools — Any time you find yourself doing repetitive, manual, or simple tasks, you could be wasting time. Look for opportunities to write new tools, or find tools on the market that can help streamline your workflow.

Need for Improved Architecture — If you find that your system architecture is holding you back, either with speed of development or scalability, you may need to improve your architecture. With a clear product strategy, the CTO should be able to manage the evolution of architecture on their technology roadmap.

Need for Automation — Test and deployment automation allow for more rapid release cycles, tighter feedback loops, more consistent quality, and fewer fires to fight. You should invest significantly in automating your workflow once it’s established.

Skills

Learning Curve — When leveraging a new language, tool, or framework, expect uncertainty in estimating and executing on your sprint. Plan accordingly, and invest time in bringing the team down the learning curve.

Mentorship — Teams often have more senior and more junior members. It’s critical for the long term success of the team that the senior members mentor and coach the junior members in order to level up the skills of the team. Don’t completely pack the senior members to capacity. Give them time to mentor the junior members when they need help.

Cross-Training — You want to take a vacation at some point right? T-Shaped teams are the most effective at not only delivering consistently, but also flexing where demand changes for different skills. Look for opportunities to pair program and cross-train, even if it may temporarily reduce the team’s velocity.

Skills Gap — Sometimes there is a skill that just isn’t available on the team. Identify these gaps and either invest in training, or get someone on the team who has it.

Two Failure Patterns

I have found two main failure patterns in teams that hold them back from continuous improvement. Keep an eye out for these archetypes and challenge them to be accountable and strive to improve.

The Complainer — This person brings all problems, but no solutions. They point fingers, place blame, and take no responsibility for outcomes. There is no accountability, follow-up, or commitment to improve. This person also tends to drag others down with them, creating a toxic environment that is disastrous for morale.

The Complacent — This person doesn’t want to rock the boat. They’re just going through the motions. They show up to the retrospective, but don’t offer any meaningful feedback. They spend no time outside of the retrospective reflecting on how to improve. They don’t continuously learn or share new ideas with the team. They also have no accountability or commitment to improve. This individual also creates a negative environment which I call “The Funk.”

The Champion

There is a third archetype, which I like to call The Champion. This person embodies all of the principles I constantly espouse. They have the attitude that we can and should be our best possible selves. They meet every day with intention and set clear goals. They reflect on their day and take the time to think about ways to improve. They take personal accountability for the success of the team. They engage with and support their teammates across the company. They are bought into the company mission and believe they are working towards a meaningful cause. As leaders, we want everyone on our team to become this archetype.

Running an Effective Retrospective

With a culture of continuous improvement and a vigilant eye for issues to resolve, the retrospective should be a lively and innovative session where the team challenges each other to become their best selves. The basic structure may be familiar, but the emphasis is on root causes and actionable output. Nothing can be brought to the table without asking the questions: “what was the cause of this success/failure?” and “what should we do to reinforce/improve it?”

What Went Well, and Why?

A lot of times teams will call out some nice thing that happened and leave it at that. Dig deeper and try to understand what lead to that success. There is a lesson in there that should be brought to the surface and possibly shared with other teams. Capture the principle or practice in the team charter.

What Didn’t Go Well, and Why?

Bring up the issues in communication, workflow, technology, and skills. Identify root causes, and don’t be afraid to challenge people directly. The retrospective should be a safe environment where people can speak openly and honestly about the problems they face and collaborate on solutions.

What Should We Do Differently?

Every success or failure brought to the table should have an action associated with it. Discuss how to fix problems or reinforce successes, define actions and owners, and track their progress. Create stories in the backlog and prioritize them to be done in the following sprint. If the issue was personal, gain commitment from both parties to improve the working relationship, and hold them accountable in the future.

Show and Tell

If the team is continuously learning, they will come across relevant content or technology that should be shared with the team. Take a few minutes for a recap or demo, and come up with applications that can be implemented immediately.

Effective Feedback

Now that we’ve got the culture and the mechanisms in place to support continuous improvement, there is one final piece to the puzzle. Challenging ourselves and each other to do better is a delicate issue. We must be able to provide honest and direct feedback to one another without creating negative conflict.

Why We Don’t Give Feedback

Many of us choose not to give feedback because we don’t want to hurt someone’s feelings. We may fear retaliation. We may fear gaining the reputation of a malcontent. Giving feedback requires effort and risk. We may have an individual, self-centered focus (“that’s not my job”). We may have tried giving feedback in the past, but haven’t seen results. This effective feedback model allows people to share their feedback in a way that is constructive, non-threatening, and action-oriented.

Radical Candor

The book Radical Candor describes the principles behind open and honest feedback. I won’t go into elaborate detail, but the goal is to show empathy for our teammates while giving open and honest feedback about behavior that negatively impacts the team. I recommend reviewing this model and discussing it with your team. In my earlier failure patterns, The Complainer aligns with Obnoxious Aggression, and The Complacent aligns with Ruinous Empathy.

Care Personally and Challenge DirectlyThe Effective Feedback Model

The method I use comes straight from couples therapy. The main idea is that when we want to provide feedback, we are following a process, which takes us out of normal conversation and puts us in a mode where we are less likely to take the feedback as a personal attack.

The Trigger — Start by simply saying “Are you open to some feedback?” This engages the other person and lets them know that we are about to start the process. They then know what to expect, and how to behave accordingly.

The Facts — “Do you remember when you did X?” By laying out the facts as accurately as possible, you both agree on the event. You can debate and clarify the facts until you agree on a common view of reality.

The Impact — “When you did X, you impacted me/the team because of Y.” The goal of the feedback is to make the other person understand how their actions impacted you or the team. Do not jump to judgment or solutions. Simply work to gain a mutual understanding of the impact.

The Optional Suggestion — “In the future, I’d appreciate it if you did Z instead.” It is not required to suggest new behavior unless you feel strongly about how they should interact with you. It is enough to simply provide the feedback and let them digest it. As engineers, we tend to jump to providing solutions. Give the person time to reflect on the feedback if possible.

The Acknowledgement — “Thank you for your feedback.” That’s it. Don’t get defensive. Don’t make excuses. They are not required to make any commitment at that moment. It is enough for them to thank you for having the courage to bring this to their attention.

The Follow-Up — In this model, there is an implicit agreement that they are now accountable for the feedback provided. They can take the time to reflect on the feedback and come up with a solution by the next retrospective. If the feedback was related to a personal conflict, they should be mindful of the behavior and not repeat it in the future. If the person does not learn from the feedback, you should bring it up to the team in the next retrospective. If the negative behavior is repeated, the team can hold an intervention. If the person shows no commitment to improve, they can be permanently removed from the team. While not for everyone, this is the pinnacle of self-managing teams.

Conclusion

Truly great teams perform not because of their process, but because of their attitude. With a poor attitude, you can never Scrum your way out of it. With the right attitude and a culture of continuous improvement, regardless of where you begin, you will eventually achieve greatness.

Through this fairly simple and straightforward model, I’ve been able to transform demoralized, poorly performing teams into eager, engaged, high-performing, awesome teams. Start with the Definition of Awesome, define your principles and motivations, create an environment that builds trust and empathy, encourage effective feedback, and give the team the time and autonomy to innovate and try new ideas in the effort to become awesome.

Feeling “The Funk”? I Can Guide You Through This Process!

I’ve built my practice around helping growing tech companies mature their team dynamic and agile development methodology. It may seem daunting, but trust me, I can help you start making small, iterative, meaningful progress in the right direction. If you think your team has the potential to Become Awesome, reach out to me on my website and let’s get you on the right path!

If you’d like to read more of my articles on product development, leadership, and software development process, follow me on Medium. You can also find my conference talks and podcasts on my media page.

You Can Help Spread This Positive Message. If You Made It This Far, Please Click Furiously!

Becoming Awesome — Creating a Culture of Continuous Improvement was originally published in Hacker Noon on Medium, where people are continuing the conversation by highlighting and responding to this story.