Reasons for not scaling Scrum

Ever since Scrum has become a staple "best practice" in software development, people have asked this same question: "How can we scale Scrum in our organization?"

Yes, Scrum can be successfully scaled. Yes, there are frameworks out there like Scrum-of-Scrums, SaFE,  LeSS. And there are companies which built up their very own framework, like Spotify.

Some work better, some not so well. But which one works for you?

Let me be a party pooper: None will - if you implement them as a prescriptive set of rules to deal with your organization.

Without being preposterous, I dare say that many organizations looking for a "Scaled Scrum solution" are asking for a solution without understanding what their problem actually is. And they become susceptible to the old adage, "A fool with a tool is still a fool".

 Here are some reasons why you should not scale Scrum in the first place:

Scrum Ceremonies break

• The Backlog grooming is an opportunity for the team to clarify what they need to know in order to implement a story. But how does the team clarify things where they are partially responsible - do they clarify together with those who are responsible for other parts? It is better to suffer the waste of receiving unnecessary information or to suffer potential lack of disinformation. So, you induce mandatory waste into the process.
• The Sprint Planning is the point where the team decides what they will work on during the next iteration. But since everything on the top of the backlog is high value high priority, scaling organizations also need to answer the "Which team does what - and why that team and not another?". It is an entirely new level of Sprint planning which is non-existant in a small scale implementation - and it is also inherent waste.

• After the Daily Scrum, you still have no idea what is going on and where the real problems are ... the main purposes: synchronizing and focussing, are not met - because you need to synchronize with people outside your team and others may focus on things you don't even care about! But how do you know - without yet another meeting where no working software is produced?
• The Sprint Review may not be between teams and customers - it often becomes an internal festival where developers show results to each other: Customer centricity becomes a tech talk. Maybe you need an "IT review" and a "Customer Review"?

• The Sprint Retrospective is specifically intended a place for the team to be amongst themselves. But what if the problem is bigger than one team? Who solves problems that are inherent to the organization, but not visible to any team? Who will address the elephant in the room?

Scrum Roles break

• The Product Owner should be steering the team to deliver maximum value. Once this turns into multiple teams, the availability of the PO to the team becomes an issue.  Antipatterns like the "absent PO" or "disempowered PO" become commonplace.  Manytimes, PO Consortiums or a PO line hierarchy arise. The problems between separating accountability and responsibility are obvious - they lead to bureaucracy and CYA - both dangerous to the product and the organization itself!
• The Scrum Master can't work like before.  All of a sudden, it's not about a team's impediments, but about the teams' impediments, so the conflict of interest "Our team vs. Greater Good", which the role was intended to resolve, actually becomes their main problem.

•  The Developers also can't work like before. In the past, they were empowered to do whatever they needed to do in order to make a better product, as long as the team approves. Well - that ends when other teams are working on the same product. They need to align not only within the team, but also across team boundaries, losing the essential freedom to maximize value while minimizing cost and risk.

Scrum artefacts break

•  The Product Backlog contains enough stories for the team to work on. However, it should always stay at a manageable size. Is 50 a manageable size? How about 100 or 200? Well, probably not. However, if you want properly sliced stories for 5 teams and each team can do 10 stories per sprint, you'll be ending up with the need to have roughly 150 properly sliced high priority stories in the backlog. Tell me what is important when you have 100 "high priority" items on the radar!
• The Scrum Board breaks, because one team's doesn't really tell us what is going on. You need to look at all teams' Scrum boards to get a grip. Unfortunately, the boards only tell a rudimentary tale. The real story is told in the Daily - and since you're not attending all the dailies, you can't understand what the boards are meant to convey.

•  The Velocity breaks, because each team has their own velocity. Either, teams will align estimates across teams or teams will have individual estimates on their own stories. In the prior case, teams have to abandon their former way of estimating. Previous estimates become an invalid basis for comparison.

• Release Planning breaks if velocity is broken because teams use individual estimates, the  PO will get completely confused because all of a sudden, Story Points  become team-dependent and not a valid capacity metric.

Communication breaks

Yeah, I know for many organizations, the Agile Manifesto is just a boring mandatory Power-Point slide at the beginning of the Scrum Training. But remember the first value? People and interactions over processes and tools.

• Bigger organizations sooner or later become so big that you don't know who knows or does what.

• When developers don't know who can help them on a specific issue, they are likely to implement a sub-optimal solution.   

• More people always means more communication. More communication means less time for implementing solutions.
  
  
• Chances are when communication time exceeds coding time, you would be more effective with less people.
• Reducing communication is not a solution: Keeping people ignorant or introducing Chinese Whispers will not make your product better.

Product Vision breaks

• As single Product Owner, you must be a superior, exceptional leader to align a scaling amount of stakeholders who all have their own objectives on your vision. If you are up to the task, maybe Presidency of a government would be more suitable than scaling a Scrum organization?

• If you work with a Product Owner Consortium, please take a minute and have every Product Owner explain their main objective to a neutral observer, then ask the neutral observer to describe the Product. Be prepared for a surprise!

Continuous Improvement breaks

• It's already not easy to fix something broken you have full control over.
• Now, try fixing something which is broken for you, but works for another team!
• Next, try fixing something which is broken for someone else, that affects what you do, but has been established by yet another team - without making anything worse for anyone!

Team autonomy breaks

• When teams lose the flexibility to fix their own problems, they slow down, morale and output drops.
• When teams lose control over their own work, being dragged into processes they do not want or need but that others want or need, they slow down, morale and output drops.
• When new people get onboarded, how will you deal with the team structure? You can't simply add new people to teams all the time, because a team of 20 doesn't work. 9 is already an overweight. You also can't rip teams apart, that will devastate productivity and morale. You also can't just put new people into a new team, because they don't get familiar with the existing Working Agreements unless they work in an existing team. So, any new person you add results in un-answered organizational questions.
   

Summary

I am not saying you can't scale Scrum. However, you should resist the temptation of scaling just because you think you should - chances are, you can't and don't know it yet. The consequences of scaling are severe and the cost of scaling may far outweigh the benefits.

It may be necessary to scale, but it is significantly better to avoid and postpone scaling as long as you can. Once it becomes inevitable, you need to be aware of the detrimental impacts - and deal with them before they destroy your scaled organization!

A LeSS course is a good way to get input how to solve the most common problems of scaling. But you can't take LeSS blindly and hope it will solve your problems for you. You still need to find out what works for you!

Agile defect management strategy

"We don't have any defects, so we don't need a defect management strategy".

If you are in that situation, you're fooling yourself. Good teams are not those who don't make any mistakes (that's an illusion!) - they catch their mistakes before any harm is done.

And for that, they have a defect management strategy in place. And that strategy must be continuously inspected and adapted.

The following is a high level outline for an initial agile defect management strategy:

Define: What is a defect?

There's nothing more cumbersome than the discussion whether something is a defect, "Works as designed" or a Change Request. And that discussion does not solve the problem at hand. It's a red herring. You do not want to decide this on a case-by-case basis.

  Align the team and all stakeholders on what you call a "defect" and how to define it. You are free to inspect+adapt the identification criteria frequently. But don't make ad-hoc decisions after getting enraged about individual reports.

How will you track defects?

It doesn't really matter whether you decide to use Post-It's, your Backlog tracking tool or a dedicated application lifecycle management suite. What matters is that you use appropriate means and everyone agrees on the approach.

Issues to consider are: Who needs the information, what will they do with it?

Separate: What is not a defect?

At least as important as the definition of defects is a clear definition of what will not be handled as a defect. This doesn't need to be very formal, specification by example does the job quite nicely.  Typically, issues that are not defects become stories in the Product Backlog and are at the whim of the Product Owner.    

 Some product owners will claim that "as long as it doesn't affect revenue, it's not a defect". We will not discuss here whether that is a good approach. It is merely one of many possible decisions in a project.

 Again, align the team and all stakeholders on what is not a defect and where the dividing line is.

Handle: How will you deal with defects?

It may be obvious to some, but it's not bad to have an open discussion. Depending on the formality and scope of the project, you may want to discuss topics such as severity, priority, SLA's etc. 

Furthermore, you should discuss how you will ensure that the issue is gone once and for all.

Improve: How will you deal with non-defects?

Just because it's a bug doesn't mean the software is doing great. Some "non-defects" are actually improvement suggestions. Others are distractions from the product vision. Yet others are simply a waste of time. While you will need to decide the next steps on a case-by-case basis, you should have a clear strategy on the next steps. After all, your purpose is not to clear the defect list, but to provide a great product that excites customers.

Flakiness: What if you don't know?

Bugs may also be flaky. You may need specific approaches for dealing with the "Bugfoot" (someone is adamant to have seen it, but there is no proof) or the "Heisenbug" (the nature of the bug changes by observing it). The worst thing you can do is sink near-infinite effort into analysis, but you also don't want to disappoint your customers. Claim the common ground.

Conclusion

Invest a bit of time to create a clear defect management strategy. Inspect and adapt your approach whenever necessary. Stay lean and pragmatic. Align.

This will make your agile project much more successful.

True Collaboration over Daily Standups

Daily Standups go a great length in synchronizing and building teams on a day-to-day basis. Often, they make the difference between a loosely coupled group of developers working on related topics and actually working towards common goals.

Yet, there are numerous problems habitually associated with them.

The nature of the Daily Standup

Following textbook definition, we would have all team members huddle in front of the Scrum Board, then each team member shares "What have I done yesterday, what will I do today, what impedits me?". The main purpose is to synchronize one another, but also to build mutual accountability.

Any stakeholder who is interested may participate in Daily Standups as a silent bystander to get a feeling of what is going on: "Status Meetings" and "Status Reports" are a thing of the past.

Of course, this is also part of their value. However, their biggest value is barely hinted: Finding opportunities for improving the collaboration.

What happens when you don't have Daily Standups

Without daily standups, there is a huge risk that team members run into different directions, providing code that does not turn into a maximum value solution at the end of the sprint. One worst-case scenario: people work in parallel on incompatible solutions to the same problem - and find out when the customer complains.
You can't be a team unless you share troubles, solutions, failures and success.

Dealing with Problems

It's natural to face challenges in the implementation of software. This-or-that framework doesn't behave as expected, here or there a configuration item is causing trouble, an infrastructure component is required - and whatever. Technical experts are keen on solving their own problems, because after all, that's what makes them experts.

Oftentimes, there is someone else on the team who has experienced the same type of problem before. Becoming aware of someone else's problem, they would gladly extend a helping hand. But how do they become aware unless someone is sharing their troubles?

Tangents

The Sprint defines a clear scope and time box. Sometimes, it is very interesting - or academically challenging - to not only work on the task at hand, but to derive a related task. For example - we need to do a site index. Because it's both related and my personal favourite, I also implement a fuzzy search. Cool, but it will cost me 5 days of the Sprint - and nobody asked for that.

The shared accountability in the Daily Standup encourages the team to focus on the common objectives and provides an opportunity for team members to say "That's good, but we need you to do something else."

Status Reports

Transparency makes agile implementations strong. Lack of transparency causes problems. Managament's first reaction when they don't know what is going on: Forced status reporting. The first stage is boring, hour-long status meetings that become a mixture of sleeping pill and justification rally. In the second stage, they become written, formal and tracked - merely to satisfy the internal need of being informed. Usually, both methods are implemented simultaneously, in cumulation burning a good 20 hours of productivity per week.

Not many developers like writing formal status reports, so daily standups actually increase morale.

Why having Daily Standups is bad

After the previously mentioned topics, who could argue that Daily standups are actually bad?

Let's look in detail what Daily Standups actually are. They are a predefined standard process executed in a rhythm. As such, they induce waste.

No meaningful update

"Yesterday, I was working on the search engine. Today, I will continue working on the search engine. Nothing impedits me." - great. Now, how much did that help my team? The good news: Like this, the standup only takes 5 minutes. The bad news: We're actually wasting 5 minutes of each team member each day.

Numerous approaches, such as "Improving the 3 questions", have been implemented in different organizations. None of these solve the fundamental problem, they merely try to expose the symptom.

If it's something that takes more than 1 day, why has it not been sliced further - why is nobody else involved, what has actually changed since yesterday - and is there a way for other team members to join me so that we can deliver faster, a better solution etc.?

I might bring up even more questions: If I've been working on it for a full day already and plan to work more - who has done the testing? Is anyone doing code reviews? I should be rallying support for my topic rather than just informing what I do. Or is my task not important enough for the team to contribute?

Hiding the Elephant in the Room

Have you ever seen how everyone focuses on their stories, their responsibilities in a Daily? Yes, everyone can align that on the Sprint Goal. But is that sufficient? There is probably a prioritization issue when 3 or more stories are Work in Progress, because nobody seems to ask the intrinsic question "Which one is really the most important of these?" - probably the team is more focused on delivering quantity than getting the top priority done!

Many teams justify this behaviour by stating: "But Tim is the only Database expert, so he's the only one who can do that story!". A measly excuse, really - because they have a bottleneck and aren't even working to resolve that. In fact, the team subconsciously knows they have a sustainability and quality issue: If Tim gets sick or goes on vacation, the team may be completely blocked. All the stress is on one shoulder!

So, the real question we should be asking is not: "Which is the next story for Tim?", but "How can we collaborate on this one, so that the next Database story doesn't rely solely on Tim?"

Value Delay

Why should I wait for the Daily Standup to rally collaborators? I should do it immediately. If I need to get some exploratory testing done - why should I wait until the next stand-up to find a team member who has some time? 

Again, this may come down to priorities. If I am doing is the most valuable thing the team can do at this time - why am I the only one? If I am not doing that - why am I not working on the most valuable thing? Why should I wait until the next Daily to deliver most value?

Restating the obvious

The worst stand-up I have ever participated in was actually in the most efficient team. We did something called "Mob Programming". The team was great, we were flying through the backlog at a rapid pace. Everyone was constantly and intensely involved. But our daily standups were terrible: "Yesterday, we completed the stories A,B,C. Today, we will work on the top priorities in the following order..." Only one person spoke, because - everyone already knew what we were doing, why we were doing it and how they would contribute! Everyone was highly focused. Nobody was doing anything outside the agenda.
The stand-up wasn't adding any value because everyone knew everything before we huddled!

Is this inherent to the Stand-Up?

All of the above can be solved by actually improving the nature of the stand-up. But many times, standups are not like that. Why? Because people are not looking for collaboration, they are merely fulfilling their responsibility. Let's be frank: If you aren't looking to collaborate, your Daily Standup is a farce!

Summary

Daily Standups are great. If people are working on different tasks, the Standup provides an opportunity to resynchronize, harness synergy and refocus.
You should improve your Daily Standup to the point where they become a magnet for collaboration and a catalyst for value creation. Once they fit that purpose, you should look for different places to improve.
Daily Standups are an artifact in themselves and provide no bottom line value. They assist in obtaining value - no more, no less. As the level of collaboration among teams improves, the amount of actually new and relevant information would decrease.  In an ideal team, collaboration would be an ongoing, permanent condition and the Daily Standup would only interrupt the ongoing collaboration to fulfil a non-value adding ceremony.
At that time, Daily Standups turn into waste. Few teams ever reach this state.

Improve your standup to be valuable, but remember that the vision is great collaboration, not great Standups!

Continuous Flow over Sprint Planning

The biggest gripe agilists have with "traditional Waterfall" projects is "Big Upfront Design", or, in short: BUFD. Many detailed design documents are full of feature requests that were just put in "in case we might need it". When the specification goes into development, there's too many trees to see the forest and people lose perspective of what is really important because a contract has been agreed to deliver everything. As a consequence, when time runs short, the customer oftentimes ends up with a half-baked software that has lots of fluff but lacks essential features. As the Standish Group Chaos Report states, the consequence is often colossal failure.

The value of Sprint Planning

Sprint Planning is an important discipline of Scrum. The main outcome of Sprint Planning is setting a short-term objective for the next sprint. The team and stakeholders agree on what will be covered, why - and in which order. On the positive side, the information gap between development and business is minimized. On the negative side, unrealistic expectations and bad ideas are weeded out before any effort is wasted.

Many teams use "Planning Poker" and "Story Points" to determine how much they are capable of delivering. 

What happens when you don't do Sprint Planning

Maybe 100 years ago it was possible to go to Klondike with nothing but a pickaxe and make a fortune. However, that was unreliable and many found their demise rather than wealth and glory. Those who want to succeed lay out a plan, stake the best claims - and replan early when their assumptions turn out wrong. And this is what we should be doing in agile as well.

We use the Sprint Planning to determine where the value lies and where it's worth to lay a claim and mine the gold. Continuing in this figure, we determine how rough the terrain will be, how deep we will dig and what tools we'll use to bring forth the wealth.

Sprint plannings are sometimes considered a waste by both developers and stakeholders. Yes, they do consume time. However, as the old adage goes, "Failing to plan is planning to fail". We can make this short: If you don't have a plan, you'll just deliver some garbage. Customer unhappy, developers unhappy, project ends.

Everyone wants to deliver high quality working software with maximum value. It makes developers proud for a job well done, customers happy to work with the product - and business happy because money is received.

Why having Sprint Planning is bad

Disclaimer: This is about "Sprint Planning", not about planning.

Commitment versus Intention

Many immature organizations consider Sprint Planning as a way of retaining some illusion of control. Developers are asked to commit to completing the Sprint's stories and held accountable to meeting their quota. Note that this is a misinterpretation of the intention: The team commits to what they will be working on in terms of direction and focus, not in terms of quantity!

Committing to a plan

The Agile Manifesto is quite clear on valuing "Responding to change over following a plan". CSM courses teach that the Sprint Plan is iron-clad: Within the time box, we do not tolerate change. To weasel out of this corset, we create back doors. The most prominent are buffers and a sprint termination process.
It's easy for the team - or Scrum Master - to stand up and say "You want a change? We can make a change. But we'll terminate the sprint, discard the efforts up until today and restart." This creates an atmosphere of fear. Stakeholders become afraid and developers unwilling to make "just in time" changes.

A sample perhaps? At the beginning of the Sprint, we said we need a button "More details" on the product display. While implementing it, we realize it won't deliver value: We need a "Buy Me" button instead!
Who will muster up the courage to terminate the entire Sprint for a useless button? Nobody. And so, we let the developers waste time to build a worthless feature and put another story into the product backlog so that in maybe 3 week's time we get a valuable feature that could be available in a day's work.

And what happens next? In the Review, developers proudly demo the worthless function to a disgruntled marketing department who aren't even interested any more and end users who ask "Why would I want this?"
 
Wouldn't it be significantly better to have a mechanism "I realize we don't need X, let's just discard it and do Y instead"?

Yelling "Scope Creep!"

Sprint planning has the intention of determining the scope of development in a sense that developers are aware what defines "success" for this sprint. Many teams will - unfortunately - go as far as to deliver exactly the committed Acceptance Criteria and nothing else.
They may not account that users, just like they themselves, are often uncertain on what the final product should look like. Yes, it's good to have a clear picture of the outcome before starting.

Let's be picturesque again.

When you go to an interior architect, they often create a fully explorable 3d model of your future living room before ordering a single tile and let you review and adjust the placement of every single object in real time.
What you may just be doing is asking the customer to come up with a fully explorable 3d model of their future living room - not giving them the opportunity to review and adjust the placement of any single object for a full sprint. And much less would you give them the opportunity to ask "While we're putting up this deco fountain, would an ivy plant would look nice here?". And even less would you suggest it by yourself, because hey, that's Scope Creep!

Again, this is not a flaw of Scrum or Sprint Planning. It is a flaw of how Planning is oftentimes practiced.

Even if planning not used to keep the customer out of the development process, it is better to make just-in-time adjustments than to defer the delivery of visible value.

Boredom

Sprint plannings are bulk sessions. All topics relevant in the sprint are bundled up together and in a meeting marathon that may well take a couple hours, one topic after the other is covered.

The worst part of this is that as the meeting progresses, interest wanes. Obviously, a well groomed backlog would put the lower-valued topics later in the plan. However, even the last item of the backlog is still the most valuable item the team can work on from all topics to follow.

Team members and stakeholders will not be discussing and estimating the 7th user story in a row with the same level of attention and fervour as they discussed the 1st story. As such, the risk of lapsing ideas increases as planning progresses.

It is good to have a clear plan for the sprint, but it is better to not overburden anyone and keep the discussion fresh and vital.

Hiding behind a curtain

We planned 4 stories, we delivered 4 stories. Everything is good.

Is it? One story was 2 man-days, another was 15. It should have been an Epic, sliced into multiple bite-sized portions. The timebox may become a curtain veiling the true complexity of individual stories. Stakeholders may lose the valuable opportunity to refine the "MVP" of a story as it starts to become unexpectedly complex during a sprint. 

Planning provides a direction. It should not replace the opportunity to re-negotiate every single story during the implementation phase. The value of software development can be multiplied by a magnitude when during the development of each line of code, Inspect+Adapt is applied. This may well include scrapping and reworking committed Acceptance Criteria mid-implementation.

It is good to make a plan with the stakeholders before getting to work. It is better to refine this plan every single day even while completing the work.

Overproduction

Two of the Seven Deadly Wastes identified in Lean is "Overproduction" and "Storage". This is what planning often does.

The team does not know for certain how much they can deliver, but they don't want to be idle, either.

So, sprint planning typically covers 1-2 stories more than the team will actually scope. This may be "pull forward". Given the nature of agile projects, not only the pull-forward, but also the planned scope may not be reached. By the time the sprint ends, objectives may have changed and none of the unfinished stories become part of the next sprint's plan.

Congratulations, you've created a storehouse for undone work and have produced plans that may never come to fruition. Not very Lean.

It is good to have enough items in the backlog to optimize value delivery. It is better to have a mindset in the team that not everything we plan is a commitment.

But it is even yet better to not plan anything that you won't be doing.

By producing a continuous flow of stories "just in time", we prevent the terrible waste of planning and storing story details we will never use.

Summary

There is a reason why "Responding to Change" is considered more valuable than "Following a plan".

Not making a plan is a terrible idea and will devastate the product. But it is better to defer any detailed planning to the latest point in time where it makes sense. The best point in time is "When we are doing it". This will not only be within the sprint - it may be even after we started realizing the story!

Do not use Sprint Planning to lock out the golden opportunity to deliver maximum value.

Use a continuous flow of stories to inspect and adapt whenever it makes sense.

Continuous Deployment over Sprint Reviews

Waterfall required a big leap of faith (and often, a suicide leap) for business stakeholders: Open your wallet, wait a couple years and pray that you find the results useful. In Scrum, we make things more tangible: Every couple weeks,  stakeholders and developers gather and look at working software, discussing the good, bad and the ugly. The best part? Everything that is "Done" is already an asset, even long before the project's delivery date.

The value of Reviews

Truth be told, stakeholders often don't know what they really need unless they have something they can look at and fiddle with. Let's humour for one second the thought that a comprehensive specification and UML diagrams exist. 

Once the first couple lines of code are written, maybe just a GUI without any functionality - maybe just a few algorithms without a database connection ... the relevant users can take a look and decide whether that's workable, where the weak spots are and what could be done to make the construct more useful.

None of this is possible by looking at complex specification documents, because everything a document review does is add more levels of detail, not innovating new, efficient ways of doing things better.

What happens when you don't have Reviews

Or, alternatively, "What happens when stakeholders don't attend reviews, don't give feedback during reviews - or developers show funny powerpoint slides instead of working software".

In the Review, developers and business stakeholders re-sync mutual expectations and understanding. The next sprint can be planned more efficiently with the knowledge where the most value lies - from here.

Not having frequent, good reviews means that developers continue working with assumptions rather than with users. It also means that the most powerful Inspect+Adapt mechanism is taken from the team. Obvious faults in concepts will not be discovered until someone fiddles with the software or validates the system against their understanding of business.

Why having Reviews is bad

There is nothing intrinsically bad about Reviews. But there is something bad about having a set date, maybe once every 2 weeks, where Reviews are conducted.

Slow Feedback

Reviews are definitely an improvement towards simply "throwing stuff over the fence" because they enable feedback. Unfortunately, they encourage developers to move stories into "Done" without checking whether users actually like the result. Just asking you personally: Are you proud to call something "done" without knowing whether the person you're doing it for will like it? Ideally, we receive feedback even while developing the feature, ideally so fast that we can actually respond to change. Maybe there's no need to continue developing after a certain point, maybe we need to do things completely differently than we initially assumed.

Batch processing

The biggest problem of Reviews is the batch processing. If you got 5 Stories are on the sprint, 4 will be done long before the Review, and stakeholders can't see them until the timebox is over. This turns sour when these stories build upon one another and the first story already had a fundamental flaw: The entire sprint may need to be discarded.

Induced waste

This means we have an interval of a couple days where developers already start forgetting the "Why" and "How" before they have to recoup everything to produce a demo. Sometimes, they counter this by writing presentation notes upfront, which do not provide any value to the customer.

Worse than this - if different stakeholders attend in order to review different stories, their time is wasted. Marketing doesn't care about this fancy new form for sales - and sales doesn't care about the new campaign algorithm. But both patiently sit through the non-value adding time.

Lost value

The first item in the sprint backlog is the most valuable item of the sprint. So, it gets done first. That's common sense. However, many teams don't deploy to Production until the PO accepted the sprint's "Done" items in the Review. 

This means that from the time the most valuable item is done until the Sprint Review is completed, we have the most valuable deliverable rotting in the repo, producing zero value!

Summary

It is definitely good to have Reviews and a serious improvement over not having them. Reserving (half) an hour every 2 weeks to ensure you deliver high value, remain on the right track and have happy stakeholders is definitely a good idea.

But it is better to receive instant feedback on every work item completed. 

Continuous Deployment is a rigorous, highly disciplined approach to move completed features directly to where you receive this feedback - to the real users. You won't need to wait for a specific future date, you will instantly know how users respond. And from a business perspective: you don't keep the dollars on the shelf, you reap them!

Continuous Improvement over Retrospectives

The Retrospective is Scrum's most powerful tool for sustaining and improving productivity. After each sprint, the team gathers the most critical pain points and agrees on a few specific ones that should be dealt with during the next sprint. Success is tracked from sprint to sprint.

The value of Retrospectives

Harnessing the power of retrospectives, the organization gains transparency on why developers are impedited and through the improvement activity, productivity is brought to whole new levels. 

In organizations strongly embracing change, it is not rare for newly formed Scrum teams to see a productivity boost of well over 200% within a couple of months.

Yes, you read right: Retrospectives are the key to hyperproductivity.

What happens when you don't have Retrospectives?

Well, that one is easy to answer. The team gets into a treadmill of delivering feature after feature, sprint after sprint, release after release, year after year. The same old problems linger, get persistently ignored and nothing changes until someone and disrupts the process.

The most common kind of disruption here is that developers simply get fed up and leave. The next type of disruption is that the next "powerful methodology" comes up and because it promises so much better results, Scrum gets abandoned. Those are still okay. But what if the disruption is that a competitor throws out a much better product, delivering much faster and cheaper - and takes over your customers?

In Waterfall projects, people conducted either "Lessons Learned" after each major Release - or "Post Mortem" after each failed project (to the point that Post Mortem became the Standard project closure process). But hardly ever was anything done about it.

Retrospectives try to change this behaviour by frequently inspecting and adapting the process. You fix what's broken rather than cleaning up the shambles.

So - why should ne not have can anyone say Retrospectives are bad? Well, they are not "bad". But they are a suboptimal state. Consider the following a stimulation of thought rather than bashing.

Why having Retrospectives is bad

Deferral of thought

Oftentimes, team members purposefully do not think about improvement until the Retro, because the Retro is the time to bring up issues. This is not an inherent problem of Retros, but of mindset. It is absolutely false to consider that we should not think about Continuous Improvement when we are outside the Retro meeting.

Deferral of solution

In each Retrospective, the team will agree on the most pressing 1-3 issues, so that productivity is not replaced with internal improvement. Unfortunately, this kind of thinking is absurd: If the team has too many issues, it may simply be better to solve them all at once before loading up yet more technical debt.

If there are pressing issues that damage productivity more than their resolution costs, why should you defer the solution for a couple sprints?

Absolution for suboptimal work

One of the major outcomes of Retrospectives are adjustments to the Definition of Done. On the flip side, the DoD is immutable for the duration of a sprint. However, if team members are already aware that their DoD is suboptimal, they should not adhere to inefficient standards but rather do what common sense dictates: Huddle, resolve, continue efficiently.

Thinking within the box

Retrospectives are team-centered. Purposefully, external stakeholders are NOT invited, as the Scrum Primer states. Is it right to consider all problems to be local when everyone knows they are not? Maybe, the team can't even see a problem until an external stakeholder escalates and then there's an emergency: Sprint termination, crisis meetings and general panic. Is this necessary?

Why would you give the team a forum to speak their entire mind - but not to the customer? Is their opinion worth less than that of the developers? Especially if they could help with the solution! So - how will the team harness the improvement potential that others could offer?

Problem thinking

A key element of Continuous Improvement is problem solving. But it isn't the only element. This is not intrinsic to Retros, but to the practice implemented in many teams. When do they have time to think about mastering their expertise, turning Good to Great? As long as there are pressing issues, solving a problem may defer the strife for excellence. However, it may be better at becoming exceptional in one area than becoming okay in all areas.

Summary

It is good to have Retrospectives. If your reason for not conducting Retrospectives is that "We don't find anything to improve" or "We can't accomplish anything anyways" - that's your #1 pressing problem and reason to call an emergency Retrospective.

On the other hand, Retrospectives are on the same line as any other Scrum event: It is good to have them, but it is better to work in flow: As soon as something comes up, harness it. Do not batch up, do not defer. Involve stakeholders, engage customers. 

Everyone should be on a continuous watch for improvement potential and should jump at every opportunity to produce a positive bottom line for the team, the company, the product - and the customer.

Taking Initiative over dedicated Scrum Masters

The second value of the Post-Scrum Manifesto states "Taking Initiative over dedicated Scrum Masters".

To understand what this means, we must briefly glance at why we even have Scrum Masters in Scrum.

 

The role of the Scrum Master

Who is the Scrum Master anyways and what do they do? A small (yet in Scrum trainings, most emphasized) portion of their responsibility is keeping the rigour of Scrum, reminding stakeholders and team members of their role, facilitating the events and getting impediments solved.

Probably the biggest responsibility is moulding the developers into a team, creating a powerful workforce able to cooperatively turn user stories into valuable, working software - by any means necessary.

And with that, the Scrum Master's main responsibility is: to become superfluous.

What happens when you don't have a Scrum Master

For example, teams who are not aware of the Tuckman model may never reach a superior performance: Being busy fighting fires day-in, day-out may prevent progression. A Scrum Master should be aware of this situation and free the team to pass through the Storm.

Initial teams often abandon "pure Scrum" very quickly: Daily Standups turn into detail discussions or get skipped altogether, Review Meetings become Tech Talks, Retrospectives become venting sessions. The Scrum Master guides teams to be more effective, but also coaches members on why these events are important and what their intended outcome is - and when they are missing the mark.

For many organizations transitioning to Scrum this statement is (should be) applicable: The Scrum Master is empowered to resolve impediments outside the team's sphere of control. They may freely move beyond team boundaries to make the team more effective. Most of all, not being a developer, they have time to do this.

And, let's not forget the most important aspect of becoming agile: It does not suffice - or, to put it more bluntly: It does not work - to have "a bunch of nerds in IT doing Scrum". It may help a bit when things are in utter chaos. To be effective, the organization must embrace agility. The Scrum Master should evangelize management, stakeholders on the benefits and responsibilities of working in an agile context and win other developers who are currently working in less effective structures for the new, improved approach.

Why having a Scrum Master on the team is bad

Let us start with the most important responsibility of the Scrum Master:

Orchestrated Agile transformation

Disclaimer: There is nothing, absolutely nothing wrong with bringing experience on board.  When everybody looks to one person "So, how should we do Scrum?" - that's a terminal disease: Failure and success of Scrum would hinge on one person. However, Scrum is a team discipline, so that's counterproductive. Deming realized a good 30 years ago in his 14 Principles that "the transformation is everybody's job!".  As such, everybody should be leading the Agile transformation.

Lack of impediment resolution

It is good if there is someone on the team who can assist developers in removing their impediments. However, there is already an organizational issue when people are impedited and unable to resolve this by themselves. Having a mindset of "I can not resolve this by myself" is a killer to motivation and productivity. As such, every team member should feel both responsible and empowered to remove their own impediments.

Ineffective Events

Events, such as the standup are not for Scrum. Much less are they for the Scrum Master. As long as team members rely on the Scrum Master to facilitate events - at worst: reporting to the SM -  they do not reap the full benefit. Each event serves a team purpose, so it should not even be necessary for the SM to organize or attend these: The team should drive every events that is valuable to them! 

For this, every team member should understand the value they obtain from a event - the SM can't do that for them!

Fixing symptoms, not causes

Each time the SM intervenes against outside interference to keep the team uninterrupted, that is a fix to the symptom. The root cause is that someone doesn't understand what they are doing. It is good to have a pitbull biting anyone who unknowingly damages productivity. It is better if there is nobody who does that.

Wrong source of improvement

The team members may justified have trust in the SM's ability to improve, but every activity introduced by the SM does not originate from the team, which means that they did not have the mindset to identify the problem or come up with the solution. The very fact that the SM adds value to the team is a shortcoming of the team. In a truly self-sufficient team, an SM can not add value.

Driven evangelization

It is good when the SM can evangelize others in the agile agenda. It would be better if the team's results would inspire others to participate. As the old adage goes "Preach by any means necessary. If inevitable, use words." - the SM can assist as an information radiator, ideally the team is already a shining beacon. The SM can (should) not be busy establishing disciplines like software craftsmanship, refining backlogs etc. in stead of the team. The more they involve in these activities, the less mature the team is.

Summary

Anything that the SM does for the team indicates a dysfunction in the team. There is no excuse for anyone on the team to not be doing what the SM does. A good SM is the key ingredient of a highly successful team. A great SM will make themselves superfluous.

Becoming great at answering the wrong questions

"The right answer depends on the question"

This proverb has long guided me and I always strive to ask better questions.

This week, I evaluated some devops tools and felt oddly reminded on how similar the effectiveness of DevOps is to a product owner's story writing.

The wrong user story doesn't deliver the business value you're looking for.
Here are some of the highlights for poorly written user stories that I encountered while evaluating tools. Marketing makes these stories look like they are what you'd really want in your DevOps stack. But let's take a closer look.

As a DevOps, I want to see way back in time when certain error messages occurred so that I know how long it has been going on.

Yikes! If there are unknown error messages in the logs which nobody has been taking care of for months on end and nobody realizes - or cares - then either it's not important or your organization is in a mess. You don't need a tool that permits you to discover errors a year back in time, you need a strategy to effectively deal with problems as soon as they occur!
Let me rephrase that story for you: "As a DevOps, I want to be notified immediately when something abnormal happens so I can analyze and resolve the problem before it hits the customer!"

As a DevOps, I want to have a one-click solution which connects stack traces in log files with the corresponding source code segment so that I can analyze the effect on the user easily.

Good luck on that. I personally prefer to have robust, well-tested software, If your software is throwing significant amounts of stacktraces, then the effect on the user isn't your primary problem.
Let me slice this one for you: "As Sysop, I don't want any stack traces in production logs, because I don't want to operate a system that doesn't do what it's supposed to do." - and - "As a Developer, I want a software test that has sufficient path coverage so that I won't run afoul of undefined behaviours during refactoring." - and - "As application user, I expect the software to behave as intended in each and every circumstance so that my business outcome is predictable."

As a Security expert, I want to be notified in real time when user data is compromized.

Sounds great. But what are we really talking about here?  Why do you even care to know that in real time? There are predictable, controllable ways in which user data can be compromized. In this case, your strategy shouldn't be to introduce realtime notification, but prevention. Any minute you're investing in data theft detection would be significantly better invested in hardening your systems.
Let me rephrase that one: "As a data security officer, I want all known security loopholes closed so that we don't even have data security incidents!"

As a DevOps, I need data for every possible failure scenario so that in case of incidents, I have enough data.

Tools will give you a false sense of control when you ask the wrong question. Your question is not to have data for everything, but to eliminate root causes - so that you won't need data.

Your job as a DevOps is not to hoard a boatload of data that can't be humanly understood, your job is to eliminate operative risks within the software so that the essential monitoring data can be reduced to a manageable and comprehensible level.

Conclusion

Tools are not solutions unless you first define the problem.
Your DevOps Strategy will fail unless you first learn to ask the right questions.

Shared Vision over dedicated Product Owners

The first value of the Post-Scrum Manifesto states "Shared Vision over dedicated Product Owners".

To understand what this means, we must briefly glance at why we even have Product Owners in Scrum.

The role of the Product Owner

The primary role of the PO is to communicate the product vision with all stakeholders and maximize product value. When there is a misunderstanding or dispute, the PO facilitates the dialog. Moreover, the PO owns the Product Backlog. They decide what will be part of the product - and what won't. They set the priority and are accountable for making the right calls. Customer facing, the PO is responsible for what the team delivers. Team facing, the PO is responsible for what the customer wants.

What happens when you don't have a Product Owner

Let's just assume we have a textbook Scrum team, but the PO is missing. The first thing that will practically always happen is that stakeholders start bombarding the team with feature requests, everyone considering their own requirements top priority. The team now has the job of juggling all those requests while delivering working software. 

If the team is lacking a person who is capable of calling shots on either-or options, they run a great danger of implementing inferior solutions, dissatisfying the customer. 

On a more positive note, the responsibilities of the PO will typically be picked up somewhere, either through the customer side or the team. Unfortunately, there is no guarantee this will happen before the product failed.

Why having a dedicated Product Owner is bad

Having a dedicated PO communicate stakeholders on the product vision and making tough calls on value choices is good, but it's still a bottleneck. Since being agile is all about never ever maneuvering yourself into a corner, it simply doesn't make sense to enforce a bottleneck.

The need for a dedicated PO actually indicates symptoms for a number of problems:

Different levels of understanding

It's good if someone can explain the product vision to others, it's better if everyone shares it and product vision communication should never be a unidirectional process. 

Single Point of failure 

When someone needs to call shots, it means that this person is can singlehandedly cause an otherwise successful product to go awry. A good PO will never be a dictator, but since the PO will always filter information through their personal viewpoint, unsound decisions may be made. The more decisions PO doesn't need to make because the team has the knowledge and ability to make them, the lower the risk of having a SPOF actually failing.

Also, developers may become paralyzed or make wrong decisions if the PO is unavailable for clarification.

Stakeholders management over consensus

When someone needs to call shots, it means that different stakeholders set different priorities. This may always happen, but is a situation where one person has the final say really better than being able to come to consensus? 

Translate: Business-Developer, Developer-Business

The PO facilitates the dialog between team and customer, especially in situations where business expectations are technically unsound. In theory, this sounds good. In practice, we have an agile value "Customer collaboration over contract negotiation". Nowhere does it say customer collaboration is limited to the PO. If every developer collaborates with customers on a daily basis, the mutual understanding will be there without having a facilitator in the middle.

Assumption of incompetence or apathy

We get taught in Scrum classes that PO's understand the business value and know which increment is best to advance the product's value. Superficially, and in an immature organization, that is true: Oftentimes, developers have no understanding of business value. But that shouldn't be considered a given law of the universe. In Programmer Anarchy, there is a radical shift: Developers not only understand what is the best value for the customer, they are so closely interlinked with customers that they drive: They deliver working software and let the customer decide whether they're getting their money's worth. Sounds odd? Making developers business savvy, instilling them with a keen sense of where the money lies is sure better than simply assuming they're either idiots who know squat or who frankly don't care how their living is earned.

Just consider yourself as a developer: Which would you prefer? Having someone tell you that you have no sense of business - or having someone bring you to the point where you can do everything they can?

It is good if the team has a product navigator - it is better if everyone can read the compass to the pot of gold.

Summary

It is not wrong to have a PO. But don't focus on establishing and strengthening the role of the PO- Raise up the entire team to fulfill the responsibilities of the PO, and the dedicated PO will be superfluous.

The Post-Scrum Manifesto

Is Scrum too heavy for you? Only if you're truly agile!

We are still uncovering better ways of developing software by doing it and helping others do it.
Through this work we have come to value:

Shared Vision over dedicated Product Owners

Taking Initiative over dedicated Scrum Masters

Continuous Improvement over Retrospectives

Continuous Deployment over Sprint Reviews

Continuous Flow over Sprint Planning

True collaboration over Daily Standups

That is, as long as you don't have the items on the left, 

you probably need to work on the items on the right.

Now, please go ahead and flame me :-)

Agile process models, Six Sigma and Cynefin

Back in my days as Six Sigma Master Black Belt, I learned and taught that every process can be modelled as a function. We write, on an abstract level, "y=f(x)". We use tools like SIPOC and Ishikawa Diagrams ("Fishbone") to model the relationship between inputs and outputs.

Since most processes have some variation, we accept that in practice, the function really implies "y=f(x+e)", where e is an error term within certain tolerance limits, typically impacting the accuracy of the model by no more than 5%. Because e is so small and we can't control it anyways, we ignore it in the model.

But what do you do when y=f(x) is simply an invalid assumption?

That's where agility comes into play.

Simple

The first difference between product manufacturing and software development is that product manufacturing is reproducible and repeatable. You know the exact process to apply to certain inputs to get the predetermined output. This is the "simple" world based on the Cynefin Framework.

But nobody in their right mind would build the same software the same way twice. Rather, if you have it, you'd use it. Or, you make some changes. Regardless. The output is not identical.

Complicated

What typically happens is that once a customer (user) sees a piece of software, they get ideas of what else they need. In this case, it's more like "y=f(x,y)": Given a result, the customer defines the new result. The process isn't reproducible anymore, because the output of each stage is input again. As a Six Sigma practitioner, I already had some issues with outputs that were process inputs: SIPOC becomes confusing, but it was workable.

At this point, it makes sense to work incrementally, because you can't know the final output until you have seen intermediate output. This is why agile frameworks typically apply backlogs rather than finalized requirement specification documents. We accept that the user may need to gain some understanding of the system to decide what has value and what doesn't. We also accept that the user may change their opinion on anything that has only been a vague idea yet.

Failure to implement checks and balances will move the team into the Complex domain within a couple weeks. Validation is not a onetime initial activity but must actually become stricter throughout the project lest errors accumulate and disorder leads straight into a Chaotic environment.
There is no way to reach the Simple domain, lest you acquire a good crystal ball that lets you accurately predict the future. (If you got that, you probably shouldn't develop software but play the stock market.)

Complex

You get into a mess when you only assume that the customer likes the result, but can't know for certain whether they do. The definition of quality may be unavailable until after the result is available to users. This scenario is fairly typical in web development, so as developers we have to guess what customers will accept. When users don't like something, we made an error. And there's no way of knowing that it was an error until we deployed the feature. We have to live with the fact that "y=f(x,y,e)" We can't eliminate the error term from our model, much rather, we have to accomodate towards the ever-present risk. We can only try to minimize risk by getting frequent feedback. The more time between two deployments and the more content within a single deployment, the more likely we made some critical error in the user experience.

Processes like A-B testing and continuous delivery become critical success factors. 

While you cannot completely eliminate the randomness, creating a high speed feedback mechanism, such as actively involving users in every minor detail produced, minimizes the effect of errors and effectively permits working similar to a Complicated environment.
The absence of control processes which deal with randomness may cause disorder to quickly shift the team into the Chaotic domain.

Chaotic

The worst thing that can happen is that yesterday's truth may be today's error. Customers may change their preferences on a whim. Imagine you work in a project where yesterday, you were requested to build a web portal for e-commerce, today the customer wants a document management system instead. Any plan is invalidated when you can't rely on your requirements, user stories or feature requests - or whatever you call them. Your model becomes a form of "y=f(e)", where neither x, you input, nor y, your previous output, are relevant indicators of success or failure.

This is where Waterfall projects with long planning phases may drift: By the time the plan is realized, demand shifted due to factors outside the project's sphere of control. An example would be a Waterfall team building a well-defined, perfectly fine php platform over the past 2 years meeting all business requirements, only to find out the newly hired CTO has just announced that all newly launched systems must be implemented in pure Java.

The only good news about the Chaotic domain is: You don't have to be afraid that it gets worse. Everything the team does may be waste.

The best way to deal with the Chaotic domain is moving away from it by delivering iteratively to minimize the effect of uncontrollable random on results. Frequent releases, no more than a couple years, provide the opportunity to move into the Complex domain.

Conclusion

The nicest statistical process model doesn't help when there is no feasible way to keep error terms under control or any model you come up with has relevant variables which can not be controlled. Six Sigma techniques for statistically modelling processes is useful when the process is repeatable and reproducible (good AR+R), but it won't get you far in a domain where R+R is neither given nor desired.

Let's talk about DevOps!

Imagine you're a sysop. Your systems are up and running, so you sit back and chill. 

Yeah, I said, "Imagine". Now, I mean, seriously. Not like you'd have time for that. Every platform requires frequent maintenance, you wouldn't want any service to deteriorate. While you're juggling security updates, intrusion alerts, overflowing storage, network load and whatnotever could possibly go wrong on the average working day, those nasty Scrum teams come around and ask for a configuration change, giving you only a couple days to implement.

They can't even formulate a proper Request for Change including a detailed risk assessment and simply want you to "install that one module" and because you think that the new storage module is more important, they request "just give us the root password and we'll do it ourselves".

Anyways. That's beyond reasonable. Someone will compromise the server in one way or another and everyone will point fingers at you. Worst case, you'll get the sack. No chance in hell freezing over!

Ok, that was "Why are admins always so slow" for all of you developers out there. 

Now, let's imagine you're the developer. You've got your story backlog, you've got the code lined up and are ready to deploy. Inside your Scrum team, you can simply prioritize the issue, and everyone will swarm to solve it within the business day. Unfortunately, this time you need a change to the system configuration, a certain module needs to be installed. And that means you have to go into the lion's den of sysadmin. And probably they'll ask to have everything written up formally, only to shove it into some tracking tool where it will rot until a date far beyond sprint review. Chances are, your story won't make it, because they'll be too slow.

That is the flip side of the coin. Now, who is wrong?

Trick question!

This dilemma exists in many companies and the result is neverending fingerpointing and blame-games. But - that's not how our story needs to end.

How can you synchronize Development and Operations without infringing on either, while satisfying both? What can Development offer to Operations to make their life easier, how can the mutual pain be eased? 

In small startups, you can simply move the admin role inside the sphere of responsibility for the Scrum team, but as soon as the organization grows, difficult questions will arise: How do we keep servers secure across teams, how do we maintain dozens of individual systems which can go berserk every minute, etc?

Some people go as far as claiming "#NoOps: Developers can do everything!", but let's be honest. You're not very likely to find someone who can do the highly specialized fulltime job of a developer and still be a highly specialized fulltime admin, while at the same time having time to keep up with new business requirements and user activity on the platform - and still working on an affordable payscale. On the other hand, distributing administration within the team may simply not be feasible, because too many half-competent (no offense) developers run a risk of making a dangerous modification towards the servers.

The main result I have seen so far coming out of #NoOps claims is servers that are hardly maintained, with configurations that are insecure, incomprehensible and run a tremendous risk of falling apart any minute. Many developers don't even understand why they shouldn't simply log in as root. And that's just the tip of the iceberg. It goes further over using telnet login, creating tablespaces with "autoextend" and more. (I apologize to all the admins out there for the head bruises incurred by facepalming too hard and to all the developers out there who don't understand where the problem is).

Development must understand the pain of Operations rather than pointing fingers - and Operations must understand the pain of Development. 

DevOps are the solution: Let's just admit that administration is necessary and that developers are developers. And then work out solutions from there. Rather than usurping admin activity into the dev team, let's facilitate a positive information exchange, foster mutual understanding and simplify the interaction.

For instance, you can automate the configuration management with CI, or you can go as far fully automate deployment and eliminate the risks that always come with major releases. Development can relieve Operations of any activity that really no admin wants to do (i.e. working through tedious, poorly written instruction manuals) , and in turn, Operations can provide platforms where change is smooth to implement and easy to track. 

Refactoring running rampant

The purpose of refactoring is: Increase the quality of code without changing the functionality of the code. Unfortunately, we too often forget that "quality" is in the eye of the beholder.

Let me give you one example. This is pseudo Java code snippets, but you can see where it leads.


Originally, there were 2 classes which contained code like this:

class A
int X;
int Y;
public int compute ()
{
   return this.X + this.Y;
}
class B
int E;
int F;
public int compute()
{
  return this.E - this.F;
}

Well, those are highly similar methods, so "obviously", this calls for refactoring.

Let's start refactoring to a common level:

class A
int X;
int Y;
private int _compute ()
{
   return this.X + this.Y;
}
public int compute ()
{
   return this.compute();
}

class B
int E;
int F;
private int _compute()
{
  return this.E - this.F;
}
public int compute()
{
   return this.compute();
}

We have some duplicate code now, so we want to eliminate it by moving the method into a new class:

abstract class operatorClass
public int compute ()
{
   return _compute;
}
class A extends operatorClass
private int _compute ()
{
   return this.X + this.Y;
}
class B extends operatorClass
private int _compute ()
{
   return this.E - this.F;
}

At least, now there is a common level, but there is still highly similar code. Let's do something about it.

class A extends operatorClass
A()
{
  setOperator ("+");
}
class B extends operatorClass
B()
{
  setOperator ("-");
}

abstract class operatorClass
int X;
int Y;
String operator;
public int compute()
{
   switch(operator)
   {
      case "-" : return X-Y; break;
      case "+" : return X+Y; break;
      default: throw new InvalidOperationException (operator); break;
   }
}
protected void setOperator(String operator)
{
   this.operator=operator;
}

Yay! We eliminated the "nearly duplicate" method in 2 different classes and reduced the amount of code in both of them.

Unfortunately, there is a small fly in the ointment here:

• Case-Statements are poor code. Reason? They are more difficult to unit-test. Path coverage comes to mind. It's also a violation of the Single Purpose Principle.
• The "operatorClass" is now doing stuff it shouldn't be doing, that is: making a decision that should be made on a more abstract level, i.e. on the level when the object is created - a violation of the Dependency Inversion Principle!
• We actually introduced the possibility for error into the operatorClass' "compute" method. Trying to call "compute" with invalid operators was not possible before!
• Oh, and that, of course means, we need additional Exception Handling. We didn't even go into the new "InvalidOperatorException" class that we must create.
• Each time we implement a new class that implements a new "compute" method, we must modify the "operatorClass", so we just violated the Open/Closed Principle!
• Not to mention the application's performance has just deteriorated. It will now be slower, because of the "case" statement that must be evaluated. It will also consume more memory, because an additional variable must be initialized

Summary:
While the clode looks cleaner when you only look at the level of A and B, we merely "shoved dirt under the rug", but we didn't help at all!

Lesson learned

Refactoring is not a purpose in itself.
Not every refactoring is actually a positive change.
When refactoring, you must set a clear purpose of what you want to accomplish - and why. Even when you do not break (unit) tests and the code becomes shorter, you may be doing something tremendously harmful.
I strongly advise doing Code Katas occasionally to get a grip on how to refactor beneficially.

Software Development Lifecycle - Testing

The Software Development Lifecycle: Testing

What you see above is the "Test Cycle" as I learned and practiced in Waterfall environment, for years.
Now, I don't even want to go into how in theory, you can add significantly more test phases in here.Neither how in practice, smoke, integration and regression tests are usually neglected.

The simple fact that developers hand over software they consider "works as designed" to test is ingrained into the mind of waterfall software project specialists.

As I mentioned in another post about test coverage, defects occur even when developers consider that their software is defect free.

Let us consider for a minute that each test costs time.
While a piece of code is in test, developers continue to produce more working software. Yeah, I know that the Waterfall theory says that once development is finished, the product is handed off to test. But seriously - has this ever been reality? Do developers really sit there twiddling thumbs until testers report defects? Do companies really pay developers to sit idle while testers are busy?
If you are seriously working in such an environment, I would have a great optimization suggestion for your management.


So, developers build on code they consider to be working while test time passes. If a defect is then found in a component they are building on - yet, given the defect, the new component did "work as designed", the defect fix may cause rework not only in the defective component, but also in the current work-in-progress: Fix efforts may already be twice as high -or even higher- as if the defect was discovered before the developer started a new topic.

The problem is intensified when developers don't induce defects into new components, but into components that have already been accepted in the past. Ignoring the fact that oftentimes, when schedules are tight, regression testing is the first activity to be descoped, it's always the last thing testers do. This approach actually designed to maximize the amount of time that a defect can stay in the software - and therefore, maximizes the amount of damage a defect can do!

Is this smart? No!

You will never deliver cost effective high quality products unless you un-learn this model!
Forget everything you learned about Design-Develop-Test. It's the wrong philosophy. You can't improve it. It doesn't even get better when you increase the amount of time for regression tests or put regression testing in front of functional testing.

The Solution

A paradigm shift is needed.
Here is a non-exhaustive list of changes you must make, preferably in this order:

1. Introduce mechanisms that let your developers know whether they introduced defects before they pick up a new task.
2. Don't even let developers start on a new topic until there is confidence that their last piece of work didn't introduce defects.
3. Automate testing. Enable developers to run any test they need or want to run at any given point in time, as often as they need to. Don't make them wait days - or weeks - for test results!
4. Eliminate the "tester role" (but not the testers). In Scrum, we speak of a "Developer" even when we mean "the test expert" because everyone is accountable for high quality. Make programmers cowork with test experts before actually starting to write code.
5. Create test awareness. Make sure developers know exactly which tests must pass before they create code.
6. Introduce test driven development (TDD). Give developers access to the tests before they actually start coding.
7. Change your process: Create quality awareness and accountability. We utilize "pre-commit hooks". Developers cannot even commit defective code unless they specifically override, but even then, the defect will be tracked on every single commit until resolved.
8. Implement Continuous Integration. Let developers know immediately if their component damaged the product build. A wait time of 10 minutes is already tough, days simply aren't acceptible!
9. Implement Continuous Delivery: Developers should never be working on their own environment or an individual branch for many days without merging back to the master. They should be working in small increments that can be delivered fast. This minimizes the risk that days of work need to be scrapped because of a wrong premise.

Your future process should be fully integrated, eliminating time gaps between design, development and testing. Testing should be an activity that starts before development, should go on in parallel to development and should be completed by the time the programmer moves a story, feature or task to "Done".

If you still need a "test phase", always think that any single day that a defect is within the software, you increase the cost of poor quality. Think different!