Pages

Friday, August 18, 2023

Test Coverage and Fermentation

Measuring test coverage makes sense - but maybe not in the way you think. Here's why:
Test Automation coverage is like fermentation bubbles

1. Seeing it doesn't mean things are going to be fine
- but not seeing it may indicate that the process itself may not yield good results.

2. could see it and still get an unconsumable product:
Coverage only tells you that code was executed by tests, not whether there are quality risks or issues.

3. When you don't see it on new stuff, this most certainly tells you that you'll have problems:
Your testing process and your development are out of sync, and that's a pretty good indicator that your development process itself is low quality.

It also tells you that the team is definitely not practicing TDD - because just like fermentation bubbles, test coverage is a side product, not a goal, of TDD.

If you ran a pickle factory - what do you think would happen if you set a target for amount of fermentation bubbles?

Focus on the pickles - not the bubbles.
But when there are no bubbles (tests) - you need to investigate.

Sunday, August 6, 2023

10 signs your Scrum Master doesn't understand Scrum

As an enterprise Coach, I meet a lot of Scrum teams. Despite its widespread adoption Scrum is rarely done well. Many Scrum Masters, the pivotal role responsible for fostering a high-performing team, aren't even prepared to grasp the essence of their job. Being an advocate for continuous improvement and a firm believer in the power of sarcasm to make a point, I'm not here to cast blame or ridicule anyone, but to tigger a discussion. I genuinely believe that most Scrum Masters who find themselves in these situations came there unwittingly, and want to do better. But they may lack the right understanding or guidance to see what's wrong. So - here goes my Top 10 list of common pitfalls and misconceptions how a Scrum Master could get in their own way of fostering an environment of growth, learning, and continuous improvement:

10 Signs that Your Scrum Master Doesn't Understand Scrum

Are you walking off a cliff?

Customer Focus? Maybe Later - For Now, Let's Get Scrum Straight!

A Scrum Master who prioritizes "getting Scrum straight" over customer focus misunderstands the core value of delivering value to the customer. Scrum emphasizes customer collaboration and responding to their changing needs, ensuring that the team builds products that meet their expectations and bring maximum value.

Team Dynamics? We Had a Team Building Workshop at the Kick-off, So We're Good.

Believing that a one-time team building workshop is sufficient for effective team dynamics disregards the continuous effort needed for building and maintaining a high-performing team. In Scrum, fostering a collaborative and self-organizing team is an ongoing process, requiring consistent support and attention from the Scrum Master.

Transparency and Openness? Nah - Nothing Beats a Great Hidden Agenda!

A Scrum Master who drives a hidden agenda undermines the essence of Scrum's core foundation of trust. Transparency allows for honest visibility into the team's progress, challenges, and achievements, fostering trust among stakeholders. Hidden agendas defer problems caused by misalignment into the future, at which point they may have grown significantly.

Facilitation? Servant Leadership? No, They Need Someone Who Gives Them Clear Direction!

While there are reasons for being directive, that should be a last resort. Facilitating collaborative discussions and informed decisions improves understanding, and thereby reduces risk. By taking a directive stance as a default, the Scrum Master introduces themselves as a dependency into the team and hampers their growth and collaboration.

Focus on the Sprint Goal Now - We'll Talk About Impediments in the Retro!

Let's be clear - it's not an impediment unless it significantly impacts the team's ability to deliver value. What would you think about a car mechanic who told you, "Just ignore your flat tire, go to work and come back, you can always fix the tire later." Most likely, you won't be going anywhere with a flat tire - and even if you will, the price, cost and duration required to fix a broken hub will exceed the cost of the flat tire by orders of magnitude. While this could be necessary for survival, it should be an informed Product Owner choice, and definitely not a default strategy.

You Want Time for Learning? Just Look at All That Unfinished Work in the Product Backlog!

The Product Backlog is infinite, as it gets replenished in line with demand. A team deferring necessary learning in favor of Velocity loses their edge, and will eventually lose both. Learning isn't a luxury that competes with unfinished work, it keeps the effectiveness of the team up, and trades a bit of time in the short term for improvements to quality, scope and risk in the long term.

Releasable Product Increment? Once a Quarter - otherwise, it's Too Much Overhead.

Delaying the delivery of a releasable product increment contradicts Scrum's principle of delivering value with minimal delay. Even in settings where releases are scheduled at a low frequency, a failure to keep the Product in a releaseable condition introduces risk into the process: as long as our product isn't in a releasable state, we neither know how much work it is to bring it into this state - nor whether we will have the capacity to do so when we need to.

We Wouldn't Need Feedback if you Just Learn to Write Better User Stories!

Creating a false dichotomy between writing user stories and collecting feedback is a thorough misunderstanding of Scrum's empirical approach. User stories only inform us what we believe a priori about what users need, whereas feedback validates that we did indeed solve their problem. Just think of the last time you went to a restaurant and didn't like the meal: Would you have liked the waiter to blame you for not correctly specifying what you like?

That's the Standard Process. You Can't Change It Just Because It's Stupid.

Scrum is a vehicle for enabling the team to find the process that allows them to perform at their optimum. A broken or ineffective process leads this ad absurdum. Scrum encourages continuous inspection and adaptation to optimize processes and outcomes, fostering a culture of continuous improvement and innovation.

Definition of Done? Yeah, we have one ... somewhere ... Let me find it.

The DoD is one of Scrum's core commitments, as it defines how the team is committing to work. Lacking transparency, clarity or commitment to the Definition of Done is a common source of poor quality and conflict. A good, transparent Definition of Done builds shared understanding both within the team and with stakeholders.

Conclusion

Having a well-informed and capable Scrum Master is essential for a successful Scrum team. I have deliberately phrased the above signs with some sarcasm and hyperbole. In practice, they're often much more subtle. Recognizing them enables you to take proactive steps to improve the effectiveness of the collaboration between Scrum Master, team and stakeholders.

If you spot any of these signs in your team, maybe ... try raising it in the next Retrospective?

Let's Scrum better!

Saturday, August 5, 2023

10 signs that your Transformation has failed before it started

"Agile transformation" is a popular buzzword these days, and the promises improved efficiency, better collaboration, and increased customer satisfaction are too hard for any enterprise to ignore. However, the transformation journey is not without its pitfalls. Let's take a tongue-in-cheeck snipe at some of the common causes of transformation failure.
Are you walking off a cliff?

You Know That Your Agile Transformation Has Failed Before It Started, If you...

Brought in consultants to prescribe the details of what everyone must do, when and how.

An Agile transformation doesn't come with a one-size-fits-all approach. When consultants define roles and processes without considering the unique challenges and context, we'll get a "square peg, round hole" solution. Successful transformations rely on collaboratively progressing on the Agile journey, letting teams experiment and adapt based on their own understanding and experience with a continuous interplay of opportunity, ideas, execution and feedback.

Spend more time documenting the Future Mode than experimenting or talking to people.

Agile transformation is about establising a habit of growth and learning based on iteration and continuous improvement. An overreliance on assumption-driven documentation without enough actual interactions and experiments achieves the opposite.

Already know the perfect solution, before having made a single change.

Agility is only required because we have to deal with uncertainty. An agile approach needs to acknowledge that perfect solutions rarely exist. Assuming that a "perfect" solution can be found without experimentation, learning or adaptivity will lead to missed opportunities for improvement and won't make the future organizational system any more flexible.

Can show the future on a slide deck, but not in a team.

Agile transformation is built on "individuals and interactions," not on a top-down declaration by some smart folks who know it all. A vision that exists only on a slide deck without any backing of teams who can tell "war stories from the trenches" doesn't instill much trust.

Have defined the correct process that everyone just needs to follow.

Rigidly following predefined processes is what got us into the mess that agility tries to address by fostering adaptability and flexibility. Imposing a "correct" process without degrees of freedom undermines autonomy and the opportunity to take advantage of domain specific benefits, leading to decreased motivation and ultimately, failure to realize any significant improvement potential.

Declare a mandatory universal "Agile Standard" for all teams.

Each team and organization has its own unique challenges, needs and potential. A one-size-fits-all Agile standard that disregards context stops teams from effectively practicing Continuous Improvement. Successful agile organizations treat the diversity of teams as an advantage.

Consider teams deciding their own ways of working to be a problem.

Empowering teams to self-organize and make decisions that impact their work is the means by which organizations reduce risk of failure and coordination overhead. Treating team autonomy as a liability annuls this advantage.

Apply so much rigor that Team Retrospectives don't let people change, experiment, or learn to do it better.

If the rigor and formality tells team members that their ideas aren't welcome, they'll quickly stop highlighting opportunities for improvement. When teams can't figure out how to improve in their context, "Agile" will merely become a new status quo without any sustainable benefits.

Believe that "people are doing it wrong," without giving them any leeway to do it better.

Agile transformations often involve a shift in thinking and culture, not just the mechanics of Agile practices. Blaming individuals without understanding the systemic barriers causes demotivation and resistance. A successful transformation acknowledges that there is no single "one right" approach, and focuses on enabling teams to find what works best - for them.

Your Coaches can recite the doctrine by heart, but don't understand the psychology of change.

Coaches play a crucial role in guiding teams on their transformation journey. Reciting Agile frameworks, values or principles without understanding the human aspect of change and the psychology of team dynamics alienates people and deprives them of the meaningful support and guidance they require. Successful coaches empathize with teams, create a safe space for learning, and tailor their approach to the needs of the individuals and teams they work with.

Closing remarks

Although this list might be slightly humorous, it highlights some serious pitfalls that can seriously derail transformations. Understanding these reasons for failure will help you become more successful on your Agile Journey. Being agile, fostering collaboration, and living agile values and principles is as essential for the teams doing the work as it is for the change towards Agility itself.