10 Signs You're Facing an Agile Fanatic

As "Agile" popularity rose in recent years, so did fanaticism — a rigid adherence to a fixed set of ideas that doesn't embrace the spirit behind them. In this post, we'll delve into ten signs that may indicate a person's journey into Agile has taken a detour into fanaticism. From dogmatism to denialism, we'll unravel the subtle but impactful shifts that can hinder the true essence of Agile and its intended goal: delivering value to customers.
So here we go -

Denialism

Denying the existence of bad Agile practices "because I've never seen that" hints at a lack of awareness and narrow-mindedness.

See also: "Argument from Ignorance."

Tunnel Vision

Rejecting ideas from anyone who isn't a recognized Agile Thought Leader indicates a narrow perspective and a filter that severely restricts opportunities to grow.

See also: "Ad Hominem Fallacy."

Guru Idolatry

A line of reasoning that depends on quotes from Agile gurus, using the name of the gurus as the primary evidence, may not have a point to begin with.

See also: "Argument from Authority."

Manifesto Memorization

Reciting the Agile Manifesto from memory without flexibility in its application reveals an unhelpful focus on form over function.

See also: "Formal Fallacy."

Dogma Defense

When the first reflex is to reject ideas conflicting with "Agile," without entertaining their possible validity, opportunities for improvement are lost.

See also: "Personal Incredulity."

Framework Fundamentalism

Insistence that a "proper" use of an Agile framework is necessary - shows a misunderstanding on the core Agile concept of adaptivity.

See also: "False Dilemma."

"Not Real Agile"

Labeling deviations from a personal interpretation as not "real" Agile betrays unconstructive dogmatism that doesn't encourage finding better ways of working.

See also: "No true Scotsman."

Purity Over Delivery

Prioritizing the "correct" application of "Agile" practices and methods above the delivery of valuable products to customers necessitates reevaluating one's focus.

See also: "Slippery Slope."

Blaming

Immediately responding to challenges or failure by blaming others for incorrectly following Agile practices destroys trust and the opportunity to address the deeper issues.

See also: "Attribution Error."

Elitist Tribalism

Those who separate the world into the categories "Agilists," "Those who can be converted," and "The irredeemable rest," not treating the latter as equals - are dangerous company.

See also: "Othering."

Conclusion

Always remember that Agile is ultimately about suceeding and helping others succeed. Flexibility, collaboration, and continuous improvement lay the foundation for this success. Embrace the principles, resist the notion of dogmatically following ideas or practices. This paves the way for a more resilient, innovative, and ultimately successful Agile journey.

If you spot signs of fanaticism in yourself, reconsider your position. If you spot some signs in those around you - address them. And if someone gets a full Bingo on the list above - do yourself a favor and steer clear.

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.

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

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!

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.

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.

Addressing some SAFe concerns

Quite often, I encounter concerns with the Scaled Agile Framework. When looking at the Big Picture, and what many companies make out of SAFe, these concerns are valid - and should be taken serious. On the other hand, none of these concerns couldn't be addressed by a capable SPC and a management who cares about making a meaningful difference in their ways of working. In this article, I'm looking at some of them.

SAFe- Blessing or curse?

Typical Concerns with SAFe

Before digging in: I do believe that the skills and experiences of your SAFe Practice Consultants are critical for the success of SAFe. If you rely on people who don't understand the consequences of any advice they give, you're in for a rough ride. An SPCT friend of mine recently said, "Having the wrong SPC's - or skipping the guidance of an SPC altogether - will easily cost you tenfold of what a good SPC would cost you." I agree. Good SPC's are worth their weight in gold. Unfortunately, they don't grow on trees ... but that's a different story.
Now, let's take a look at some of the concerns I typically encounter, and what we need to consider.

SAFe caters to traditional mindset

SAFe acknowledges and respects that many organizations transitioning to agile practices still have a traditional mindset. Therefore, a lot of material in SAFe is written in a way that might be more palatable to people who have a low understanding of agility. This is the idea of "meet people where they are." Yes - that's contentious, but it's by far better than affronting the very people you need in order to make a change. What happens after we met them - that depends a great deal on their motivation to change, and the ability of the SPC to lead change.

Complexity overkill

First things first - if you don't have the problems SAFe addresses, don't use it. With that out of the way, SAFe can't - and usually shouldn't - be applied completely. Much rather, when we spot a problem for which SAFe proposes a solution, we can look at what SAFe says, have a discussion on whether that's worth a try - and if it is, then go for it. That neither means that you need to do things that solve problems you don't have, nor that you have to do things the way SAFe says if that doesn't work for you. For myself, when someone comes to me and says, "We're using SAFe, and have this-or-that problem," I commonly refer to a SAFe article, and the original source pointers SAFe refers to, and take the discussion from there. To me, SAFe is a discussion starter - not the panacea for all ails.

Dependencies everywhere!

SAFe recognizes that dependencies can be a challenge in complex organizations. It provides clear guidance and practices that make dependencies visible, and then offers a way to address these dependencies systematically. In many organizations, dependencies are inevitable - but at least we know which troubles we have because of them, and can start the discussion of what to do about them. I have encountered more than once that teams found their dependencies unworkable and decided to re-organize. A great discussion to have.

Length of planning intervals

SAFe employs a cadence-based planning approach with fixed-length Planning Intervals (PIs) typically spanning 8-12 weeks. Longer planning intervals provide stability and predictability for teams at the expense of flexibility. However, you can adjust the duration of PIs based on your own context. I have seen Agile Release Trains running 3 1-week Sprints plus a 1-week IP Sprint. That even fits Scrum's old slogan of, "Working Software in 30 days or less" - at scale! Try what works for you, and have the discussion.

Top-down planning processes

Maybe we have the wrong picture in our heads, but who can blame us - when we've been conditioned to think in hierarchies? In a SAFe context, we'd like to decentralize that which makes sense - but not everything makes sense to decentralize. For example, the Product Management function in SAFe could be staffed from team Product Owners, if they have the skills and capacity to succeed in that role, so it doesn't need to be hierarchical. What we need is a clear focus on the bigger chunks of value, and align all teams around them. How this happens can vary per organization, but having each team decide by themselves - doesn't bode well. Please be aware that SAFe encourages active involvement and empowerment of teams and individuals in making decisions.

Not proper Scrum

SAFe is not a strict implementation of Scrum, but rather a framework that incorporates agile principles and practices from various sources, including Scrum. Since many teams already run Scrum and are familiar with the core concepts of Scrum, SAFe has taken advantage of that and it retains the fundamental principles of transparency, inspection, and adaptation. When I coach SAFe teams, I quite often refer to the Scrum Guide, and suggest that understanding and practicing Scrum really well helps a lot getting the scaling part right. Unfortunately, what I see quite often is that organizations have already used a highly dysfunctional Scrum for years, and now want to change that. If anything, the SAFe transformation could be an opportunity to fix the Scrum stuff that was always broken and never got addressed.

Teams become Feature Factories

That's already a dysfunction - because SAFe features should focus on value, not on maximizing quantity of work delivered. We should only have a single ART Kanban that's prioritized by value - and teams should collaborate on shared objectives, using common backlogs and cross-team events to ensure a cohesive system solution that maximizes value. While sometimes, we see that individual teams may focus on delivering their own features irrespective of value, SAFe provides mechanisms such as System Demos and Inspect and Adapt events to ensure they don't go off on a tangent and do a large quantity of low-value work.

Fallacious estimation processes

A lot could be said about SAFe's estimation process, and I have my own opinion on the guidance they give. To keep it simple: its guidance is only for people who don't know how to get started. Coaching and empiricism should lead to an approach that meets the needs of those who need the estimates. We should realize that in larger organizations, where quite often multiple stakeholders, other teams and potentially large amounts of money depend on making fairly accurate forecasts for completion, estimation may have implications that don't exist in smaller contexts. My own go-to example is that we need to absolutely know whether the feature will be ready for the Trade Fair, or whether we need to mitigate. But "Well, we might or might not be ready in time for the fair" - could lead to a major PR disaster, and is probably unacceptable.

One Continuous Improvement event every 3 months is too little, too late

While the Inspect and Adapt (I+A) event occurs at the end of each Planning Interval (PI), SAFe encourages continuous improvement throughout the PI, with both the Scrum-of-Scrums (SoS) and Retrospectives being opportunities to surface and address cross-cutting issues. I myself like to give the guidance that teams are expected to make their own changes and improvements independent of the I+A event, and even share learnings with other teams during that event. I expect teams to bring short-term issues to the SoS, and only bring issues to the I+A which require longer preparation and observation periods, and have an impact far beyond the team boundaries. Most of all, we need to consider that the I+A is a point of reflection, where we detach from the daily routine, and come together as a team-of-teams to discuss the things we need to discuss that we never got to discuss before. There's always something. Yes, we could have such events more often - if you feel that it could help, there's nothing in SAFe stopping you. Try it.

Conclusion

I agree that the Scaled Agile Framework (SAFe) has areas of interpretation and concerns. Expecting it to be a silver bullet is completely unrealistic. It does provide a structured approach for larger organizations trying to make sense of this entire "Agile" thing, though - but that only works if they have someone who understands more than just what the material says. When you can address the complexities of large-scale development, cross-team collaboration and overall alignment while continuously improving, you've succeeded with SAFe. To get there, you absolutely must customize SAFe, and use it wisely - otherwise it will become a mess, and that's why you need some folks who know what they're talking about. And I've seen that mess: The shambles take years to clean up. The people who support your change initiative need to be able to address critical concerns based on their own experience and learnings. And the people in your organization who have concerns need a time and place to voice these concerns - because only then can we truly improve.

The Blurb transformation

Recently, there's been a lot of buzz about Blurb being the future of work. According to Blurb thought leaders, the adoption of Blurb makes companies more successful by operating faster, better and cheaper.

Company X wants to give it a try and starts a Blurb transformation. During initial training, Blurb practitioners explain that all the current problems only exist because of the current management paradigm - and how much better everything would be if everything would be moved to Blurb.

Management takes their hands off, lets Blurb practitioners do, and observes.

Blurb practitioners begin to do exactly what management did, ableit very inefficient, ineffective and infantile. To management, it appears that Blurb practitioners neither understand what a manager does, why they do it, nor how to do it properly. But - benefit of doubt: Maybe this Blurb thing really is the future, and managers just need to wait and see how it turns out?

At some point, management begins to question the advantage of doing Blurb - the actual outcomes could be achieved much easier and faster without Blurb? Blurb practitioners say that's management doesn't understand Blurb, because they're stuck in a non-Blurb mindset: you can't be Blurb without Blurb.

Eventually, management calls and asks what benefits has Blurb actually brought? Blurb practitioners explain that they have made a lot of progress doing Blurb and helping others do it. They emphasize that in order to get the benefits, you must be Blurb, not do Blurb. And that the key benefit of Blurb is that you become Blurb.

Management begins to get dizzy. They decide to cut funding for Blurb.

If you were a manager of Company X - what would you have done?

10 Things a Product Owner shouldn't waste time on

There's quite a bit of confusion about the Product Owner role - and a lot of Product Owners spend most of their time on low-value, or even detrimental activity, thus having little or no time to succeed in their role. 

Here are ten timekillers that a Product Owner shouldn't waste time on:

10 - Writing User Stories

Too many Product Owners are caught up in "writing user stories," at worst matching all kinds of templates, such as the Connextra "As a ... I want ... so that ..." and the Gherkin "Given ... When ... Then" templates. Unfortunately, the better the PO gets at doing this, the more understanding they amass in their own head before transferring information to the developers. At best, the developers are degraded to a "feature factory," and at worst, they no longer understand what or why because someone else did the thinking for them. A PO is a single point of failure and bottleneck in Scrum, hence they should try to offload as much of what could go wrong as possible.

9 - Defining Implementations

Especially Product Owners with technical aptitude quickly fall into the trap of spending a lot of time on explicitly defining the "How" of solution implementation. Not only do they thus assume a Scrum Developer role, but also they disempower and disenfranchise their team. In a great Scrum team, the Product Owner should be able to rely on their developers for implementation - the PO can reduce themselves to discovering the relevant problem statements.

8 - Writing Acceptance Criteria

Probably the biggest time sink for Product Owners is detailling out all Acceptance Criteria for all Backlog Items to be "ready" for the Sprint. Where Acceptance Criteria are needed, they should be defined collaboratively, using a Pull mechanism (i.e. developers formulating, and then verifying with the Product Owner). 

7 - Ticket Details

Depending on which ticket system you're using, a lot of details are required to make a ticket "valid." That could include relations to other tickets, due dates, target versions - none of these are required for Product Ownership. They're part of the development process, and belong to the Developers. (Side note: Sometimes, Scrum Masters also do these things - they shouldn't have to do it, either.)

The items 10-7 are all indicators that the Product Owner is misunderstood as an Analyst role - which is a dangerous path to tread. By doing this, the PO risks losing sight of the Big Picture, leading the entire Scrum Team off the wrong tack, potentially to obsolescence.

6 - Obtaining precise Estimates

Estimation in and of itself is a huge topic, and some organizations are so obsessed with their precision of estimates that they completely forgot that there's no such thing as a "precise estimate." As I like to say, "If we knew, they weren't called Estimates, but Knows." - Estimates should take as close to no time at all, and if a Product Owner finds themselves spending significant amounts of time on getting better estimates, something is seriously out of tune. Try probabilistic forecasting.

5 - Planning for the team

Team Planning serves three purposes: Getting a better mutual understanding, increasing clarity, and obtaining commitment on the team's Sprint Goal. Many Product Owners who used to work in project management functions before fall into the trap of building plans for the team to execute. This defeats all purposes of the Sprint Planning Event. The Product Owner's plan is the Backlog, which, combined with whatever sizing information they have, becomes the Product Roadmap. Content-level planning is a Developer responsibility.

4 - Accepting User Stories

A key dysfunction in many teams is that the Product Owner "accepts" User Stories, and is the one person who will mark them as "Done." Worst case scenario, this happens during Sprint Review. Long story short: When the team says, it's "Done," it should be done - otherwise, you have trust issues to discuss. And you might have had the wrong conversation about benefit and content during Planning. Acceptance is something either part of the technical process, i.e. development, or something that relates to the user - that is, developers should negotiate with users. The Product Owner is not a User Proxy.

3 - Tracking Progress

Yet another "Project Manger gone Product Owner" Antipattern is tracking the team's progress. A core premise of Scrum is that developers commit to realistic goals that they want to achieve during a Sprint. The Product Owner should be able to rely that at any time, the most important items are being worked on, and the team is doing their best to deliver value as soon as possible. Anything else would be a trust issue that the Scrum Master should address. At a higher level, we have very detailed progress tracking in Sprint Reviews, where we see goal completion once per Sprint. If teams can reliably do that, this should suffice - otherwise, we have bad goals, and that is the thing the PO should fix.

2 - Generating Reports

Reporting is a traditional management exercise, but most reports are waste. There are three kind of key reports:

• In-Sprint Progress Reports, as mentioned above, they are pretty worthless in a good team
• Product Roadmap Reports - which should be a simple arrangement of known and completed mid-term goals, presented in the Sprint Review for discussion and adjustment.
• Product Value Reports - which can be created by telemetry and should be an (ideally automated) feature of the Product itself.

Question both the utility of reports and time invested into reporting. Reports that provide valuable information with little to no effort are good. Others should be put under scrutiny.

1 - Bridge Communication

The final, biggest and yet most common antipattern, of the Product Owner is what I call "Bridge Communication" - taking information from A and bringing it to B. Product Owners should build decentralized networks, connecting developers and stakeholders, avoiding "Telephone Games" that come with information loss and delay. 

When the Product Owner has their benefit hypothesis straight, developers can take care of the rest. Developers can talk with stakeholders and obtain user information by themselves. A Product Owner shouldn't even be involved into all the details, because if they wanted to, they'll constantly find their calendar crammed, and they become a blocker to the team's flow of value - the opposite of what they should be doing!

The Alternative

(About half of the points in this article describe the SAFe definition of a PO, but that's an entirely different topic in and of itself)

After having clarified what a PO should not do, let's talk really brief about what is a better investment of time:

A Product Owner's key responsibility is to maximize the value of the product at any given point in time. That is, at any time, the Product should have the best Return on Invest - for the amount of work done so far, the Product should be as valuable as possible. That requires the Product Owner to have a keen understanding on what and where the value is. For this, the PO must spend ample time on market research, stakeholder communication and expectation management.

From this, they obtain user stories - which are indeed just stories told by users about problems they'd like to have addressed by the Product. The Product Owner turns stories into benefit hypotheses - that is, the benefit they'd like to obtain, either for the company or the userbase. They then cluster benefit hypotheses into coherent themes: Sprint and Product Goals. These goals then need to be communicated, aligned and verified with stakeholders. By doing this Product Owner successfully, they'll maximize the chances that their Product succeeds - and the impact of their work. 

The Product Owner can free time by minimize the time spent on implementation. Successful Product Owners let their development team take care of all development-related work (including Analysis, Design and Testing) and trust the team's Definition of Done. That is, their only contact with Work in Process needs to be renegotiating priorities when something goes out of whack, a value hypothesis is falsified or new information invalidated the team's plan.

Collaboration Patterns we know from science

Team structures - should be a straightforward enough topic, although in many organizations it isn't. Here are six phenomena you may remember from science class - and how they relate to your organizational structure.

To keep matters simple, this post refers to "entities" - which could either be individuals, teams or entire departments. While the nature of the entity changes, we are concerned with the relationship of the entities with each other. Since some terms have different definitions in different domains, let us refer to the point of origin.

Cohesion

(Origin: Chemistry)

Cohesion is the connection between entities of one substance. Organizational cohesion, thus is the bonding strength between entities of the same category.

Examples

We have organizational cohesion when there is collaboration occurring within one team.

We have poor organizational when team members act as a group of individuals, picking their own work items.

---

Adhesion

(Origin: Chemistry)

Adhesion is the strength with which two different entities stick together. Organizational adhesion, for example, is the amount of effort it would require to separate two different entities.

Examples

We have high organizational adhesion when a process has a complex critical path.

Two business units serve different customer segments independently have low adhesion.

---

Covalence

(Origin: Chemistry)

Covalence happens when two atoms share an electron to form a bond, which molds these two distinct entities into one "complete" entity. Within an organization, covalence occurs when two or more entities share resources.

Examples

Component ownership causes covalence - let's say team A owns the Customer entity, and team B owns the Contract entity. When B needs to access the Customer, they rely on whatever A provides - whereas when A references the Contract, they rely on whatever B provides.

In situations where the Contract relies on a new or modified attribute of the Customer - such as consumer credit score, team B must coordinate with team A on how and when a change can be made, and team A might want to store a "previously rejected" attribute that must be provided by Team B. Covalence thus means that while the inner dealings of A and B become intertwined, an outside change from covalent entities requires that the change works for all covalent entities.

---

Bridge

(Origin: Chemistry)

A bridge connects two entities to turn these into one common, stable structure. Bridges require covalence bonding between two entities plus the presence of a third entity. The bridge is an entity that connects two entities by being the missing part in both.

Organizational bridges are entities equally bound to two or more other organizational entities to form one entity of higher complexity.

Examples

The analyst role is often an organizational bridge - they are close to business from development perspective and close to development from a business perspective: they are neither, but connect the two entities to turn demand into solutions.

---

Coupling

(Origin: Physics)

Capacitative coupling occurs when an energy transfer occurs between two separated conductors. Organizational coupling thus occurs when two structurally separated entities affect the outcomes of one another. We would refer to "tight coupling" when either entity could cause blocking interference to the other, and "loose coupling" if there's a generally uncritical impact. If there is no interference, we would consider the entities uncoupled.

Examples

We see tight organizational coupling when the Maintenance Team decides to shut down the Deployment process, thereby incapacitating the development pipeline.

Loose organizational coupling could be the relationship between Marketing and Sales - while they can technically work with or without the other, they do have a performance effect on each other.

---

Coherence

(Origin: Physics)

Coherence is the ability of a signal to withstand interference. We discriminate between spatial and temporal coherence: Spatial coherence is the ability of a signal to withstand interference over distance, whereas temporal coherence is the ability of the signal to withstand interference over time. In an organization, it's the ability of the information to cross entity boundaries without getting distorted by interfering signals (e.g., from other work items, other projects or line management.) Note that coherence is only relevant in the context of cohesion - incohesive entities who don't work towards a common goal require no coherent signal transmission.

Examples

Low spatial coherence would be a process with a lot of "telephone game," where information is modified in each step.

High spatial coherence would be provided by a synchronization event which ensures that all stakeholders have the same understanding on a subject.

Low temporal coherence are the deviations from a plan over time, usually caused by unanticipated events.

Why test coverage targets backfire

 Most organizations adopt a "Percent-Test-Coverage" metric as part of their Definition of Done. Very often, it's set by managers, and becomes a target which developers have to meet. This approach is often harmful. And here's why:

The good, bad and ugly of Coverage Targets

Setting coverage targets is often intended as both a means of improving the product, as well as improving the process - and getting developers to think about testing.

The good

It's good that developers begin to pay closer attention to the questions, "How do I test this?" as well as, "Where are tests missing?" Unfortunately, that's about it.

The bad

The first problem is that large legacy code bases starting with zero test coverage will put developers into a pickle: If I work on a component with 0% test coverage, then any amount of tests I write will still keep that number close to Zero. Hence, the necessary compromise becomes not setting a baseline number, just ask for the number to increase. The usually envisioned 80+% targets are visions for a distant future rather than something useful today.

Looking into the practice - as long as the organization is set up to reward minimizing the amount of time invested into unit testing, the outcome will be that developers try to meet the test coverage targets with minimum effort. 

Also, when developers have no experience in writing good tests, their tests may not do what they're supposed to do.

The ugly

There are many ways in which we can meet coverage targets that fulfill Goodhart's Law:

Any metric that becomes a target stops being useful.

Often, developers will feel unhappy producing tests that they create only to meet the target, considering the activity a wasteful addition to the process, which provides no benefit.

At worst, developers will spend a lot of time creating tests that provide a false sense of confidence, which is even worse than knowing that you have no tests to rely on.

But how can this happen? Let's see ...

The first antipattern is, of course, to write tests that check nothing.

Assertion-free testing

Let's take a look at this example:

Production code

int divide(int x, int y) { return x/y; }

Test

print divide(6,2);

When looking at our code coverage metrics, we will see a 100% coverage. But: the test will always pass - even when we break the production code. Only if we were to inspect the actual test output (which is manual effort that we probably won't do) - we will what the test does: There is no automated failure detection, and the tests aren't even written in a way that we would detect a failure: Who would detect the problem if suddenly, we got a "2" instead of a "3" - we don't even know which result would have been correct!

Testing in the wrong place

Look at this example:

Class Number {
int x;
void setX(int val) {x=val;}
void getX() {return x;}
void compute() { x=x?x/x^x:x-x*(x+x); }
}

n = new Number();
n.set(5);
assert (N.x == 5);
assert (N.get() == 5);

In this case, we have a code coverage of 75% - we're testing x, we're testing the setter, and we're testing the getter.

The "only" thing we're not testing is the compute function, which is actually the one place where we would expect problems, where other developers might have questions as to "What does that do, and why are we doing it like that?" - or where various inputs could lead to undesirable outcomes.

Testing wrongly

Take a peek at this simple piece of code:

int inverse (int x) { return 1/x; }
void printInverse(int x) { print "inverse(x);" }

assert (inverse(1) == 1);
assert (inverse(5) == 0);
spyOn(print);
printInverse(5);
assert (print.toHaveBeenCalled());

The issues

There are numerous major problems here, all of which in combination make that test more dangeous than helpful:

Data Quality

We may get a null pointer exception if the method is called without initializing x first, but we neither catch nor test this case.

Unpexpected results

If we feed 0 into the function, we get a Divide by Zero. We're not testing for this, and it will lead to undesired outcomes.

Missing the intent

The inverse function returns 0 for every number other than 1 and -1. It probably doesn't do what it's expected to do. How do we know? Is it poorly named, or poorly implemented?

Testing the wrong things

The print function's output is most likely not what we expect, but our tests still pass.

Conclusion

If we rely on coverage metrics, we might assume that we have 100% test coverage, but in practice, we may have very unreliable software that doesn't even work as intended.

In short: this way of testing tests that the code does what it does, not that it does what it should.

Then what?

The situation can be remedied, but not with numerical quotas. Instead, developers need education on what to test, how to test, and how to test well.

While this is a long topic, this article already shows some extremely common pitfalls that developers can - and need to - steer clear from. Coverage metrics leave management none the wiser: the real issue is hidden behind a smoke screen of existing tests.

Why test coverage tagets backfire

Most organizations adopt a "Percent-Test-Coverage" metric as part of their Definition of Done. Very often, it's set by managers, and becomes a target which developers have to meet. This approach is often harmful. And here's why:

The good, bad and ugly of Coverage Targets

Setting coverage targets is often intended as both a means of improving the product, as well as improving the process - and getting developers to think about testing.

The good

It's good that developers begin to pay closer attention to the questions, "How do I test this?" as well as, "Where are tests missing?" Unfortunately, that's about it.

The bad

The first problem is that large legacy code bases starting with zero test coverage will put developers into a pickle: If I work on a component with 0% test coverage, then any amount of tests I write will still keep that number close to Zero. Hence, the necessary compromise becomes not setting a baseline number, just ask for the number to increase. The usually envisioned 80+% targets are visions for a distant future rather than something useful today.

Looking into the practice - as long as the organization is set up to reward minimizing the amount of time invested into unit testing, the outcome will be that developers try to meet the test coverage targets with minimum effort. 

Also, when developers have no experience in writing good tests, their tests may not do what they're supposed to do.

The ugly

There are many ways in which we can meet coverage targets that fulfill Goodhart's Law:

Any metric that becomes a target stops being useful.

Often, developers will feel unhappy producing tests that they create only to meet the target, considering the activity a wasteful addition to the process, which provides no benefit.

At worst, developers will spend a lot of time creating tests that provide a false sense of confidence, which is even worse than knowing that you have no tests to rely on.

But how can this happen? Let's see ...

The first antipattern is, of course, to write tests that check nothing.

Assertion-free testing

Let's take a look at this example:

Production code

int divide(int x, int y) { return x/y; }

Test

print divide(6,2);

When looking at our code coverage metrics, we will see a 100% coverage. But: the test will always pass - even when we break the production code. Only if we were to inspect the actual test output (which is manual effort that we probably won't do) - we will what the test does: There is no automated failure detection, and the tests aren't even written in a way that we would detect a failure: Who would detect the problem if suddenly, we got a "2" instead of a "3" - we don't even know which result would have been correct!

Testing in the wrong place

Look at this example:

Class Number {
int x;
void setX(int val) {x=val;}
void getX() {return x;}
void compute() { x=x?x/x^x:x-x*(x+x); }
}

n = new Number();
n.set(5);
assert (N.x == 5);
assert (N.get() == 5);

In this case, we have a code coverage of 75% - we're testing x, we're testing the setter, and we're testing the getter.

The "only" thing we're not testing is the compute function, which is actually the one place where we would expect problems, where other developers might have questions as to "What does that do, and why are we doing it like that?" - or where various inputs could lead to undesirable outcomes.

Testing wrongly

Take a peek at this simple piece of code:

int inverse (int x) { return 1/x; }
void printInverse(int x) { print "inverse(x);" }

assert (inverse(1) == 1);
assert (inverse(5) == 0);
spyOn(print);
printInverse(5);
assert (print.toHaveBeenCalled());

The issues

There are numerous major problems here, all of which in combination make that test more dangeous than helpful:

Data Quality

We may get a null pointer exception if the method is called without initializing x first, but we neither catch nor test this case.

Unpexpected results

If we feed 0 into the function, we get a Divide by Zero. We're not testing for this, and it will lead to undesired outcomes.

Missing the intent

The inverse function returns 0 for every number other than 1 and -1. It probably doesn't do what it's expected to do. How do we know? Is it poorly named, or poorly implemented?

Testing the wrong things

The print function's output is most likely not what we expect, but our tests still pass.

Conclusion

If we rely on coverage metrics, we might assume that we have 100% test coverage, but in practice, we may have very unreliable software that doesn't even work as intended.

In short: this way of testing tests that the code does what it does, not that it does what it should.

Then what?

The situation can be remedied, but not with numerical quotas. Instead, developers need education on what to test, how to test, and how to test well.

While this is a long topic, this article already shows some extremely common pitfalls that developers can - and need to - steer clear from. Coverage metrics leave management none the wiser: the real issue is hidden behind a smoke screen of existing tests.

Bugfixing team - good or bad idea?

In many organizations struggling with quality, a gut reaction is setting up a "bug fixing team," which has only one purpose: Cleaning up the myriads of known bugs in the software so that other teams can focus on new features.

There's a concept that "developers can go faster if they don't have to worry about the bugs in their code." This concept is a delusion, puts unrealistic expectations on the bugfix team, and will ultimately lead to disappointment.

Why bugfix teams are bad

Bugfix teams are a counterproductive workaround stopping the organization from solving their actual problems:

• Developers don't own their work. They can fire-and-forget, because it's no longer their problem after delivery.
• Developers don't fully understand how their code actually works, hence there's nobody who has deep knowledge of the inner workings of the product.
• Developers don't learn how to write better code, because they don't have to work through bad code.
• Technical debt continues to grow, because the Bugfix team will only work on known problems while others introduce more problems.
• Building a new feature on a buggy baseline doesn't add to low quality - it multiplies.
• The perceived progress of the delivery teams is an illusion, because it doesn't mean that the delivery doesn't contain a time bomb.
• The Continuous Improvement process is subjected to quantity of output, which is the very reason why the problem occurred to begin with.

I have been part of Bugfix teams. It's a frustrating, ungrateful job and an uphill battle unless all other developers also take responsibility for the quality of their own work.

How bugfix teams can succeed

There is a way to set up a successful Bugfix team, however:

•  The "Bugfix" team is a team like any other, but they can fully commit to - and focus on - improving quality and have no commitment on new features. And they get a spotlight in stakeholder reviews to demonstrate their improvements.
•  All other teams practice a rigorous Stop-the-Line process and do everything in their power to not let low quality pass downstream. The policy is, "Bugfix team improves fundamentals, others stop deterioration and improve within the context of delivery."
•  The Bugfix team responsibility rotates.

Technically, that will make the Bugfix team a "legacy rewrite" team rather than a "locate, isolate and fix the bug" team. Their mission shaping the future of the product, not merely dealing with its past.

Conclusion

My stance on the topic is, "no Bugfix team unless you can clearly explain how you're actually going to solve the problem that leads you to needing it."

You can't solve the problem of low quality simply by throwing money at it.

Test Automation Specialists - what a waste!

"Test Automation Engineers require someone who will write the test cases for them, and they can start automating right after the software is deployed onto the test environment."

It's 2022, and I just had this conversation yesterday. Seriously?

Overspecialization leads to Waste

If we work like that, we needlessly create bottlenecks, we test too late, our tests will be of low quality, and we will spend a lot of time on identifying, tracking and reworking defective deliveries. We produce a lot of work, but not quality.

In a well-functioning software organization, there can be no such role as a "test automation engineer" who is fed work by "test designers." 

Although it sounds "resource efficient," that approach generates massive amounts of waste in all categories of Lean Muda: 

Defects

When automated tests aren't written by developers, and only available once a software package is released, we end up with three kinds of defects:

1. Product defects, i.e. things the product should (or shouldn't) do, but that weren't correctly implemented, which require another software update.
2. Automation defects, i.e. things the test automation should (or shouldn't) do, but that weren't correctly implemented. Until clarified, these lead to significant communication overhead.
3. False negatives, i.e. inadequate automation not catching existing defects. This is significantly more likely when automation isn't written close to the code, and might omit dangerous cliffs in the product implementation.

Handover

Whenever actors in a process change, there's a handover. At the point of handover, we induce delay, lose information and risk the introduction of defects. This makes our process slow and error-prone. When test itself becomes a source of error, we should stop and think.

Motion

Handovers also mean that we're moving artifacts: test descriptions, build versions and defects - without need. We also need to coordinate this motion, which means we induce additional meetings into our process, which also slows us down and adds non-value added overhead. Motion also leads to inventory waste.

Inventory

As previously mentioned, un-automated tests will pile up as inventory, as will un-tested deliveries. When tests fail, the defect notifications are made available at a point in time when developers are working on other things. Hence, we are adding three queues to our process. Each queue contains work waiting to be done, and the combined length of all these queues is value delay for our customers.

Waiting

As mentioned in my article on CI/CD industry benchmarks, the time required between when a developer makes a change, and when a developer receives feedback on whether everything is correct shouldn't exceed a few minutes, preferably just a few seconds. If automation begins upon delivery, this period of time is impossible to warrant. The delivered product has to wait a significant amount of time until it can produce customer value, and developers will turn their attention elsewhere.

Overprocessing

Having different people automate tests and write productive code leads to "overprocessing," often called "gold-plating:" As mentioned in my article about the test pyramid, we should try to automate as close to the code as possible. When we're doing high-level tests which could instead be low-level tests, we make our test suite more complex, slower and less reliable than possible.Unit tests are extremely quick both to write and execute. Test automation engineers who automate black box/gray box tests will spend a significantly higher amount of work to write tests with poorer outcomes.

Overproduction

Since the amount of labor to create a product increment in server code and test automation are extremely hard to balance, the strategy of automating after the fact usually leads to developed product features piling up, waiting to be automated. As a consequence, the decision is often to release these without proper test automation coverage to flush the waiting queue. This builds up "technical debt" which deteriorates product sustainability.

Human potential

When developing software with multiple people, we act as a team. We can learn from each other, and we can align: Someone who can automate tests, can also write features. Someone who can write features, can also automate. As a team, we can align during planning "who does what," and fill our information gaps so that those doing the work have full information and don't need anyone else to fill in for them. Techniques like pair programming or code reviews ensure that even if one person makes a mistake, someone else will catch it before a defect even enters the system. It's a limiting belief to think that somehow people can't learn - we all can, if the conditions are favorable. Maybe not everyone will be the greatest developer, but we don't need to: we work within our ability, and grow our capacity a little every day.

To confine a test automation engineer to automating defined test specifications, and to confine coders to write code without understanding how to do that without defects - is an insult to our human intellect, and a very expensive one, at that:  All the above seven wastes cost a lot of money that we could save if we would just improve our collaboration, communication and skillset.

Lean Software Test Automation

Please, let me clarify. I don't believe that test automation expertise is a waste - the waste is actually hidden in the process, and how we use our talent.

A much leaner approach which avoids all of the above eight wastes is to educate and empower - use QA to help developers learn how to define the right tests, how to apply processes like Test-Driven Development and Behaviour-Driven Development, and guide them on their journey to deliver Zero Defect Quality. And in reverse, having developers upskill our test automation experts to help them deliver integrated pieces of value including working software.

The purpose of test automation in such an organization isn't to find defects - it's to maintain the high frequency of delivery of high quality products, and to serve as a living documentation for all behaviours of the product which is maintained as part of the development process without overhead.

Time to discard the "T-Shaping" model!

 A common concept in the "Agile" community is that of T-Shaping. Regardless in which form or fashion it is promoted, the narrative is basically this: People have certain skills, and if they are one-trick ponies or are too generalist, they need to form a so-called "T-Shape." Nonsense!

The concept of the T-Shape

A specialist is a person with a very narrow skillset (making that person an "I"-Shape) while a generalist has a broad skillset (making that person a "dash"-Shape). 

A broad set of skills plus one deep expertise is a "T", multiple deep expertises are "Pi." And then, no model couldn't be "improved" by adding complexity, so we get variations like "M" Shapes, i.e. non-generalists with multiple expertises, and "E" shapes who aren't only experts, who also have "experience, exploration and execution." - although that's clearly buzzword bingo terrain, because what kind of an expert doesn't also have these?

Even I have blogged about T-Shaping, for example, here.

With the model, we were moving the burden onto people: "You must form a T/Pi/E-Shape." Thats nonsense, because it's not like people wouldn't do that on their own volition. In fact, most people who find that they can't use their skills at work will spend their time acquiring off-work skills, such as, for example, learning an instrument: everyone is Pi-Shaped, the only question is if it helps the company.

And now, I announce the time to ditch this model in favor of another model that already predates the Agile Manifesto - "Psychological Flow", by Mihály Csíkszentmihályi.

Psychological Flow

Let's take a look at the model Csíkszentmihályi proposes: He uses the dimensions of "Challenge Level" and "Skill". The very assumption that people have "one" or even a very limited number of skills is already absurd. Consider, for example: breathing. Do you know anyone who doesn't have this skill? Depending on what would qualify as a "skill," people are experts in thousands of them.

Instead of thinking about skills as discrete variables with a discrete set of values (e.g., "none", "basic", "advanced", "expert" ...) - we could think of "skill" as a continuum of different, integrated topics on a continuum spectrum.

Most importantly, the psychological flow proposes a second dimension: the level of challenge, in relation to the skill. For example, asking a Chess Grandmaster to state how a pawn moves is like a relaxation exercise. On the other hand, someone who never cared about Chess won't even take an interest in this question, "why should I care?"

If you'd ask a senior project manager to take care of large, critical programme, that brings out excitement and a sense of, "I am the right person for this job, and I can do it." Their brain would immediately sort through potential approaches and how to make it a success.

A college fresher, on the other hand, might be anxious about where to start and what to do.

That's the basic concept.

Notice that neither the "challenge level" nor the "skill level" are measured on an absolute scale - they can be considered from the perspective of the person who is doing the work: Is this work "low challenge" or "high challenge," does it require "low skills" or "high skills?"

How is Flow related to T-Shapes?

Well, it is - and it isn't. Instead of asserting that a person has a certain skillset required to do the job, we reframe the skilling challenge:

1. Is a task adequate to a person's skill level?
1. We should not under-challenge people, lest they bore out.
2. We should not over-challenge people, lest they become become worried or anxious.
2. How do we ensure that people receive challenges which allow them to use high skill?
1. High challenge, medium-skill tasks get people to become interested in what they do and that's how they grow.
2. High challenge, high skill tasks bring the best out of people.

The challenge, hence, is to identify meaningful, highly challenging work which is at least within grasp of people: medium skills get people excited, high skills get people to perform at their best.

Failure in "T-Shaping" isn't on the individual - it's team management not ensuring people have sufficient challenge to grow and show their performance.

(note based on feedback: in a self-managed team, "team management" isn't top-down - it's what teams decide to do)

T-Shaping ignores Flow

The T-Shaping model makes an implicit assumption: that all the work in the expertise domain is of interest to a person, and that it's a good use of their skills. This isn't always the case. Part of the work may make a very advanced person fall asleep, while being quite challenging for someone new to the domain. Hence, the best way to distribute work in a team isn't based on a certain "T-Shape," but to ensure that people reach a flow state - that is:

A team as a whole performs best not when people exercise a certain "T", but when the work provides everyone with sufficient, yet not overwhelming, challenge.

We shouldn't upskill with the goal of acquiring an abstract "T-Shape" - that's a weird framing already. 

Instead, we should distribute work in a team so that everyone is excited to do what they do, while ensuring nobody is overchallenged and anxious or underchallenged and bored.

Whether the result is something like a "T-Shape," doesn't even matter - because the primary result is a highly qualified team whose members are comfortable taking on slightly bigger challenges every day. 

Let's forget the T-Shape.

Let's refocus on the question, 

"How can we distribute work within our team, so that everyone gets to spend the highest amount of time possible in a flow state?"

The "Planning Tetris" Antipattern

 "We need to utilize all of our Story Points" - that's a common dysfunction in many Scrum teams, and especially in SAFe's Agile Release Trains where teams operate on a Planning horizon of 3-5 Sprints. It results in an antipattern often called "Planning Tetris." It's extremely harmful, and here's why.

Although the above feature plan appears to be perfectly optimized, reality often looks different: all items generate value later than they potentially could - at a higher cost, in longer time and with lower efficiency!

Accumulating Work in Process

Planning Tetris often leads to people starting work on multiple topics in one Sprint, and then finishing it in a later Sprint. It is resource-efficient (i.e. maximizing the utilization of available time), not throughput-efficient (i.e., maximizing the rate at which value is generated.)

That leads to increased Work in Process, which is a problem for multiple reasons:

Value Denial

Just like in the sample diagram above, "Feature 1" and "Feature 2" could each be finished in a single Sprint. And still, Feature 1 doesn't provide any value in Sprint 1, and Feature 2 has no value in Sprint 2. So, we lose 1 Sprint of marketability on Feature 1 (our highest priority) - and on Feature 2 as well:

A perfect example how utilizing the team makes the value come later!

Loss of money

Imagine now that every feature costs less than it's worth (which it should, otherwise it wouldn't be worth developing) - and you see that the "saved" efficiency of having worked on features 3 and 4 before finishing feature 1 costs the company more money than the added benefit .

Efficiency loss

You may argue, "different people are working on the features, so there's no multitasking."

Yes - and no. What is happening?

Sprint Planning for Sprint 1 has to discuss 3 features: 1,3 and 4. This means that the whole team is discussing three different topics, (none of which will be delivered in that Sprint.) The same happens in Dailies and Review. And, potentially at a source code level as well. The feature interference may also bloat up the complexity of technical configuration, deployment processes and the like.

The team becomes slower, hence less efficient.

Adding needless risk

In statistics, there's a phenomenon called "the high probability of low probability events." Let me explain briefly:  There's an infinite amount of almost infinitely-unlikely events, but unfortunately, high infinity divided by low infinitiy is still a number close to one: Something will happen. You just don't know what, and when, so you can't prepare or mitigate. Since you don't know which aspect of your plan will be affected when a risk hits, you'll always be caught by surprise.

How is that a bigger problem in Planning Tetris than in sequentialized delivery?

Massive ripple effect

When you're working on one topic, and an event hits that affects your entire team, you have one problem to communicate. When the same happens as you're working on multiple topics, all of them are impacted, and you're generating a much stronger ripple effect.

Complex mitigation

As multiple topics are in process, you suddenly find yourself mitigating multiple topics. And that means multiplicative mitigation effort - less time to work, and at the same time a higher risk that not all mitigations are successful. You end up with a higher probability of not being able to get back on track!

Chaotic consequences

Both the ripple effect into the organization and the mitigating actions could lead to unpredicted consequences which are even harder to predict than the triggering event. In many cases, the only feasible solution is to surrender and mark all started topics as delayed, and try to clean up the shards from there.

Prepare to Fail

There's Parkinson's Law - "work always extends to fill the amount of time available." That's often used as an argument to start another topic, because it stops gold-plating and keeps people focused.

But there's also the (F)Law of Averages: "Plans based on averages fail half the time."

The latter makes planning tetris a suicidal approach from a business perspective: it starts a vicious circle.

Predictable failure

Because there's no slack built into planned tetris, the mid-term plan will automatically fail as soon as a single feature turns out more complex than planned. The more features are part of our tetris stack, the more likely at least one of them will fail. And the team will usually get blamed for it. Because of that, we end up with

Conservative estimates

Teams must allocate the slack buffers into their feature estimates to reduce the probability of failure. When a Tetris plan spans multiple Sprints, some feature content may not be "Ready" for implementation during the Sprint when slack would be available - so we end up with Parkinson's Law, the buffered estimates don't reduce failure probabilities. 

Declining throughput

At this point, Parkinson's Law tag-teams with the Flaw of Averages to KO the team: Regardless of how conservative the estimates, the team will still end up failing half the time. The consequence is that business throughput continues to decline (there's an interesting bottom: when a Sprint only contains one feature!) 

Strangulating the team

Let's take a look at the psychological impact of Planning Tetris now as well:

No space for Creativity

I have never seen an organization where Product Management was happy that developers would add "creative spaces" into a Tetris Plan. It's all about churning out feature, after feature, after feature, without a pause, without a break. When one feature is done, another is already in progress. There is no room to be creative.

No space for Growth

The only relevant business outcome in Tetris Plans is usually business value delivered. It ignores that developers are the human capital of the organization, and growing them is growing the organization's ability to deliver value. Especially in the rapidly changing tech industry, not growing equals falling back until eventually, the team is no longer competitive.

No space for Improvement

I often advise that developers should take some time to look at "Done" work to reflect how it could have been done better, and turning that better way into action. With Planning Tetris, that opportunity doesn't exist - another feature is waiting, and improving something that exists is always less important than delivering the next big thing. That often ends in terrible products which are no joy to deal with - for developers and customers alike!

Now ... what then?

The point that Planning Tetris is a terrible idea should be blatantly obvious.

"Now what's the better way then?" - you may ask.

It sounds incredibly simplistic, because it is actually that simple.

1.  Reduce the amount of features the team is working on in parallel to an absolute minimum. This minimizes blast radius.
2.  Instead of having people parallelize multiple topics, let "inefficient", "not-skilled" people take easier parts of the work to step up their game. That reduces the impact of low-probability events and gives everyone air to breathe.
3.  Put slack into the Sprints. The gained resilience can absorb impact. It also reduces the need for buffered estimates, countering Parkinson's Law and the Flaw of Averages. It also gives people air to breathe.
4.  Agree on Pull-Forward. When the team feels idle, they can always pull future topics into unused idle time. Nobody complains when a topic is finished ahead of time, everyone complains when something turns late. Pull Forward has no ripple effects or chaotic consequences.

Ok, too many words, so TL;DR:

1. Sequentialize.
2. Slack.
3. Pull.

All problems mentioned in this article = solved.

The wrong professionals

Sometimes, I struggle with teams failing to understand the engineers' responsibility in quality: "I have asked the Product Owner whether we should apply Clean Code practices, and she said, she doesn't need it."

This is already not a conversation that should happen.

Here's a little metaphor I like to use:

 

And that has a number of consequences:

• Professionals do not negotiate the standards of professionalism with their customer. 
• Customers expect that the professional brings and adheres to professional standards, which is why they get hired. 
• Customers are not in a position to judge whether a professional standard is applicable in their context, and asking them to do so shifts responsibility to someone who can't bear it. That itself is un-professional.

So, what does that mean for your Agile team?

• Be as professional as you can, and continuously improve.
• Do not ask the customer to tell you what "professional" is.
• Instead, ask them whether your standards of professionalism satisfy their needs.
• You can't delegate the responsibility for the quality of your work to anyone else.
  The attempt is already un-professional.

The Code Review Department

 Let met tell you the story of a company that had problems with their code quality, and solved it the Corporate way ... well, ehum ... "solved."

Poor Code Quality

When I met that organization, their development process basically looked like this:

Developers took their specifications, completed their coding and passed the code for testing. Simple as that. 

After a major initiative failed, the Lessons Learned revealed out that the root cause for failure was the poor code quality, which basically made code un-maintainable, hard to read and difficult to fix defects without adding more defects elsewhere. 

A problem that would require rules and regulation to fix. So, it was decided that Code Reviews should be done. And - of course, people complained that code reviews took time, and if developers would do the Reviews, they would be even slower in getting their work done.

Stage 1: Introducing: the Code Review Department

What would be the Corporate way, except to introduce a new department of specialists dedicated to the specific task? So, they opened the Code Review Department. Let's call them CRD.

To keep Code Reviews as neutral and objective as possible, the Review Department was strictly separated from the others: physically, functionally and logically. They were not involved in the actual development process, and only reviewed the code that was actually delivered.

With the backing of senior management, the CRD adopted a very strict policy to enforce better code quality and defined their departmental KPI's, most notably:

• Remarks made per reviewer: How many review remarks each reviewer had found, per commit and per month. This allowed the CRD management to see which reviewers were most keen and could best spot problems.

Now, how could this possibly go wrong?

Stage 2: Code Quality improves

Since it's easy to objectively measure this data, the reviewers got busy and lots of review comments were made. Proudly, the CRD management presents statistics to IT leadership, including their own KPI's as well as the obvious metric they can present to measure the software delivered by the Software Development Department (SDD):

• Code Quality per developer: How many review remarks were made, per commit and month, per developer. This allowed the SDD to put a KPI on the quality of code provided by developers. And, conveniently, it would also justify the existence of the CRD.

With the blessings of IT leadership, SDD Management thus adopted the KPI.

So, things were going well ...

Stage 3: Code Review has a problem

Now, developers aren't dumb people. They aopted Linting and basically got their Review remarks down to Zero within in pretty short time. Now, the CRD should be happy, shouldn't they?

Turns out, they weren't. And here was the problem: The Reviews per reviewer metric tanked. Not only didn't reviewers suddenly fail their quota, CRD management figured out they probably weren't looking in the right places.

So what did the CRD reviewers, not being stupid, either, do? When they looked at code, they screened for patterns they considered problematic and introduced a new rule.

The numbers for Review remarks per reviewer rose again, and management was doubly happy: not only were the numbers of the CRD fine again, reviewers were continuously improving their own work.

Great! Things are even getting better!

Stage 4: Developers have a problem

Developers started to get frustrated. Their Lint rules were no longer working in getting them 100% passed reviews. What was worse, that they found whenever their Linting got updated, code was rejected again, and they needed to figure out the new rule to add to their Lint configuration. Not only did this process consume a lot of time, it distracted from actual development work.

Well, developers caught on that meeting the rules wasn't going to get them 100% reviews any more, so they began introducing honeypot infringements: They made obvious mistakes in their code so that reviewers would remark them, and they'd already have the fix in place right when the review came in.

Everyone happy: CRD met their KPI's and developers were no longer forced to constantly adopt new rules. Except ...

Stage 5: Management catches on

CRD reviewers were content, because they had plenty review comments again until the CRD management started to measure policy vialotations by type, and figured out that developers had stopped improving and were making beginner mistakes again. Of course, they reported their findings to higher management. And thus, a new KPI was born:

• Obvious mistakes per developer: How many obvious review infringements were made by team, with a target of Zero and published transparently throughout the SDD.

Well, again, developers aren't stupid people. So, obviously, they would meet their KPI. How?

You might have guessed it: they would hide their, ehum, "mistakes" in the code so they were no longer obvious, and then placed bets who could get most of them past Review without being caught.

Guess who won the game?

Stage 6: Code quality deteriorates

The CRD reviewers got stuck in a game of whack-a-mole with developers, who constantly improved their tricks of hiding more and more insidious coding errors, while updating their Linting rules right away when reviewers added a new rule.

Until that day when a developer hit the jackpot by splipping a Zero-Day exploit past Review. 

The CRD management no longer trusted their own Reviewers, so they added peer review reviews and another KPI:

• Issues slipped past Inspection: Reviews were now a staged process where after review by a Junior Reviewer, a Senior Reviewer would review again to figure out what the first reviewer had missed. Every Reviewer would get a Second-Review Score, and that score would need to be Zero. So, they started looking deeper.

You can guess where this is leading, right?

Stage 6: Code quality goes to hell

Now, with four-eye reviews and a whole set of KPI's, nothing could go wrong any more?

Code Reviewers were doing splendidly. They always had remarks and the department's numbers truly validated that a separate, neutral Code Review Department was absolutely essential. 

So the problem was fixed now.

Well, except one small fly in the ointment. Let's summarize the process from a development perspective:

1. When developers make mistakes, they are reprimanded for doing a poor job.
2. When developers make no mistakes, new rules are introduced, returning to (1).

Developers now felt like they were on a sinking ship. It was easier to simply continue making mistakes on existing rules than to adopt new rules. They came to accept that they couldn't meet their KPI anyways. 

Since they could no longer win, they stopped caring. Eventually, the review department was relabeled to complaints department, and nobody took their remarks seriously any more. Developers would now simply add buffer time to their estimates, and called it the "Review buffer".

By now, the CRD was firmly established, and they were also fighting a losing battle: try whatever they might, they got more and more overloaded, because truly necessary review remarks and more and more horrible code got more and more common. They needed to add staffing, and eventually outnumbered the developers.

The Code Review Department became the last bastion against poor code quality. A bulwark defying the storming seas of bad code. 

So, what's your take ... 

is a Code Review Department a good idea?

How would you do it?