Incremental Design at it's worst

Is this a representation of your system architecture?

What does Incremental Design actually mean, how does it come into being and what are the consequences?
In the most positive world, an incremental design has not only been tailored to the practical need of business, but constantly adapts and evolves, so that the system architecture smoothly covers every need.

In practice, oftentimes unenlightened teams consider incremental design as absolution for failing to plan the long term.

Let us look at the example of the power supply of Ho Chi Minh City you see above:
Whenever someone needs a new electricity line or a current line is broken, the city workers quickly lay out a new cable and the need is met. Just drop the city a call and you will have a working solution within a couple hours! No waiting, no queuing slot, no formalities - just fast, working solutions!
That's agile, isn't it?

Practiced agility

What we see is an organization applying some agile values and principles, delivering results at a high pace for many years already: It's great!

Let's look at the team of electricity workers applying agile values here:

• Working software (power supply) over comprehensive documentation
• Customer collaboration over contract negotiation
• Responding to change over following a plan

Results first: forget about complex planning - you know which line is needed, so just lay it.
Get the customer supplied with electicity comes first and foremost. The Definition of Done clearly contains "Customer can use electricity", management, bureaucracy and quotas are secondary.
If a line malfunctions, the location of the source doesn't permit for more cables, no problem: No job will be left undone. Just lay another line!

Now, let's look at the Agile Principles applied:
Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.

• Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.
• Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
• Business people and developers must work together daily throughout the project.
• Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
• The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
• Working software (power supply) is the primary measure of progress.

Yeah, there are a few Agile principles not so well applied, but we'll get to that later.

The Not-So-Agile part

As in any agile team, there is improvement potential. You just need to look at the picture above and you will see some potential.

The first thing that will spring to mind: How do they locate a defective line?
Short answer: You don't need to, when laying another line is cheaper than fixing the old line.

This is something you will also often see in software development.
It is a truism that adding a new, miniscule element to the architecture which fulfil the business need is oftentimes significantly faster than analyzing the fitting place, then designing and implementing only the minimal possible change.
We call this "local optimization".

Why is local optimization a problem?
Because in the long term, there will be nobody in your organization who is capable of telling exactly what each element is doing, and because in the end, the same thing will have been done hundreds of times - in nearly identical fashion!

Each newly laid electricity line not only fulfils it's job, but also keeps the existing lines stable: How can this be bad?
Well, first you have to think that probably 90% of the cables you see in this picture could be joined into one cable. Not only would the cityscape look more beautiful (are you really a developer who doesn't care if your code looks terrible?) but there is a problem at scale:
Yes: 10 parallel lines work. 50 parallel lines also work.
But once you hit 1000+ lines, good luck controlling the Electric Fields ...

The same happens in software design: Growing complexity is no problem until you end up with interferences which stem from an uncontrollable amount of sources. This is typically the point where "emergent design" turns into "emergent chaos" and business comes up with a good case for system decommissioning!

The solution

There is an Agile Practice which is sorely needed to prevent this kind of disaster: Refactoring.

If you do not want your system design to resemble Ho Chi Minh City's power cable design, here is what you need to do:

Yes, it is sometimes OK to implement "quick and dirty" fixes to supply the business with the needed solution. But you should never consider a job "done" when business can work. You should consider it "done" when you cleaned up the mess.
Refactoring, ideally, should come either instead of "quick and dirty" or in the timespan between the first passing of acceptance tests and delivering the solution to business ("Red-Green-Refactor").

There are some situations where business criticality (for instance, human life depends on it) prohibits turning "quick and dirty" into a more beautiful design.
However, this should be noted in the backlog and scoped for cleanup at the nearest possible point in time.

Let's go back to our power cable example:
A second cable is totally fine and does not warrant refactoring, it's actually more failsafe!
A third doesn't either.
But when I come to a place where there are already five or more lines in place, I should come back to the office and put a mark in the backlog "Too many lines here", so that the next time, I move out, I don't only lay one new cable - but I lay 1 new cable in a fashion that I can decommission 4 cables, so the total amount of cables will be 2!
We call this technique "Optimize the Whole", and it comes from the Lean set of practices.

Do this in your software design, too:
Once you encounter a piece of code which looks like a tangled mess already, choose the closest feasible point in time (ideally: now!) to untangle the mess and decommission superfluous code elements.

The "Project Manager" Game

Project managers are important contributors in Waterfall projects and there is an incredible weight on their shoulders. Good project managers will go a great length to make their projects successful.

Then again, in Agile we don't have Project Managers. And we don't miss them. No offense.

So, how can we be successful in Agile without a Project Manager?

Truth is - everything that is needed still somehow gets done.

I learned the "Project Manager" game from Jeff Sutherland's CSM course.

It's a fun pastime and takes only about 15 minutes. You may even throw this into a retrospective to lighten up the mood and dig for some insights!

Here's the rules:

Round 1: Everyone on the team brainstorms responsibilities of a Project Manager(5 Minutes)

Do not add things which a Project Manager should probably be doing but doesn't do.

This is not a test of whether the team qualifies for PMI certification.

Round 2: Assign to each responsibility at least one of the labels (5 Minutes)

1.  "Team Member" (T)
2. "Product Owner" (P)
3. "Scrum Master" (S)
4. If you think that the activity is not needed in Agile, label it: "Waste" (W) 

There is no "right" or "wrong" in this game. It's about the team's perception!

This is an example of what the result may look like:

Here are some things you should look out for in the results:

•  "Every responsibility goes to the PO / SM": you have a vested Project Manager and are probably missing serious collaboration benefits.
• Process relevant topics solely within the SM domain: your Continous Improvement project may be impedited.
• The team can quote the PMBOK by heart and can't find a single activity that is "Waste": there are probably severe organizational impediments towards agility in the organization
• Planning related topics (scope, budget, objectives, timelines) aren't even on the agenda: Dig deeper to find out how the team conducts planning in the agile implementation!
• There is an excessive focus on non-value adding activity such as listing myriads of different reports, and these are all assigned to the Scrum Master: Maybe the team's level of self-organization should be increased?

Seven deadly sins of Agile

In theology, a deadly sin is believed to destroy the life of grace and charity within a person and thus creates the threat of eternal damnation. The "seven deadly sins" are not discrete from other sins, but are considered to be the origin of others.

There are a lot of things you can do wrong as an agile organization.
Many impediments are easy to resolve once you are aware. Some, however, may brickwall your team and will sooner or later kill your project - or maybe even your company!

Here is a list of seven potential agile "deadly sins" which can become the root cause of an insurmountable pile of impediments:

1 - Not having any problems

Every organization has problems. In fact, every person has problems: Nobody is perfect.
Not having a keen view for improvement potential will cause the team's velocity to stagnate. Once you stagnate, the first big hitter will devastate your output capacity.
Hyperproductive teams don't get to this stage because they are able to avoid all problems, but because they spot them early and deal with them effectively.

2 - Not tolerting failure

It is nice to work in an environment where everything can be anticipated well in advance. In this case, agile really isn't the best way to go. Reality usually looks different: work includes uncertainty and there is always a looming risk of missing vital information.
Catching such failures fast makes adjustment easy. Hiding small failures will result in big failures.

3 - Lack of trust

If I make a mistake, I can be sure that you will not use it to report my weakness to management, but you will simply correct it - preferably with feedback, so that I may learn for the future.
Unless we are a mutual safety net, catching each other fast and smooth, failure will be painful. And unless we can rely on painless failure, we can't take the risks we must take in order to deliver high value at high velocity.

4 - Pride

Agile thrives when every team member contributes to the best of their ability.
It is OK to have someone who has more ability than the rest, but it should be made that person's primary responsibility to get the rest of the team up to speed. Tolerating any form of primadonna antics will stifle the growth of the team. It will also pose the project at tremendous risk if this person becomes unavailable.

5 - Lack of automation

Doing simple things is often quicker manually than automated.  Unfortunately, a million simple things are still a lot.
Time saved by not automating often comes at the price of decreasing sustainability and future velocity!

6 - Lack of ownership

Agile products become great when everyone on the team cares. A team developing a product "for the product owner" with a low level of engagement will damage or even kill the product in the long term!

7 - Lack of focus

Agile projects become legends when the entire team is focused on delivering one product with maximum value.
It is very easy to lose this focus, for example by diluting the product vision, by overemphasizing internal practices, by having too much turnover in the team. In any case, the result will be a dissatisfied customer.

Agile Cargoism

In the South Seas there is a cargo cult of people. During the war, they saw airplanes land with lots of good materials, and they want the same thing to happen now. So they've arranged to imitate things like runways, to put fires along the sides of the runways, to make a wooden hut for a man to sit in, with two wooden pieces on his head like headphones and bars of bamboo sticking out like antennas--he's the controller--and they wait for the airplanes to land. They're doing everything right. The form is perfect. It looks exactly the way it looked before. But it doesn't work. No airplanes land.

From a Westerner's perspective, the actions of the Cargo Cult are ludicrous, but ask the practitioners - they feel entirely different about the matter!


But - what is Cargoism?
Cargoism is the firm belief that by imitating hard enough, you will produce the same results as other practitioners. If you're not successful, it's because you didn't imitate well enough. A cargoist doesn't realize that they are missing something, that the big picture is different from their perception.

James Shore wrote a good article on Agile Cargo Cult teams back in 2008. It's worth the read.
But an entire organization can become an Agile Cargo Cult!
I've heard many times when people said "Google is successful with Agile, Spotify is successful ... so we can also be!". Then, they spend big money to send their Managers to CSPO or CSM training and establish Scrum. Of course, the executives hope that projects will run faster and more successful once practices are adopted.
They hear about Agile, they see all those successful projects and they firmly believe: "Let's do Agile, and we'll be much more competitive."
So, team managers are renamed to Scrum Masters, project managers become Product Owners - the Releases are renamed to "Sprints", each of which is started with a Sprint Planning Meeting. Every day there's a Standup. At the end of a Sprint, there's a Review and a Retrospective.
Now, we're set up. The world is just waiting for our greatness to become manifest! We'll be a successful Agile Organization in no time - and our stock will skyrocket far beyond Apple, Google and Microsoft!

Oh wait - I've described the typical organization that will stop "Agile" after maybe 2 or 3 years, shelving the concept for good. Disillusioned employees will say "Agile is just a different name for the same old wine" and managers will say "We've tried Agile. It doesn't work, it's just a fad".

Blinded by the promise of easy success, fast, high quality results at a low cost, thy adopt the practice in hopes of valuable returns: Cargoism at it's finest! Someone did make a good sale to them, probably earning good money on all the training and coaching. Ask deeper.

1. Do managers loosen the reigns?
   Agile means giving power to those who need the power to succeed. A Command+Control structure is not only inherently inefficient, but it prohibits success. Maybe people can't do what is right because they still need management approval. In this case, management may proclaim a million times "We're Agile" - but at the same time, they're agility's biggest impediment!
2. Do people understand that Agile methods like Scrum don't solve any problems?
   Scrum, for instance, just makes problems visible. Did a real, genuine problem solving process get established? Are fundamental organizational issues resolved - or accepted?
3. Who really owns the products?
   Are people aware that Product Owners champion the product - but that the product really belongs to the team? Do developers take personal ownership of their work, are they proud of their contribution to the product, or are they delivering products just because it's their job? Do the teams even have what it takes to own their product, or do they rely on external patronage to deliver anything?
4. Who defines the development process?
   Do developers follow corporate governance or are they empowered to do what is right? Do they really care to do what is right - or do they prefer to have someone tell them? Do they not only care to do their job, but to do it well? Do they improve their working process because they see the need - or because the Scrum Master pushes them?
5. Do people realize Scrum Ceremonies are actually the wrong idea? Do they realize teams should not have to have:
1. Standups, as mentioned by Jame Shore. If everyone knows what we're doing, and the PO is continuously involved - the Standup will add no value.
2. Reviews. If the team were directly engaged with the customer either with direct collaboration or techniques like A/B testing, they wouldn't need to batch up for a week or two before getting things signed off. 
3. Retrospectives. If something is going wrong, why wait until the end of the sprint before bringing the issue up for improvement? That's insane! When you see that something is wrong, go fix it!

If you hold the firm belief that by rigorously applying the practices, you will become more Agile, you have already failed. Behind Agile, there is a spirit. This spirit is not visible, but it may be manifest in agile teams. If you do not lay hold of this spirit, all your efforts are doomed. You will not be successful.
"Copy the spirit, not the form", said Yoji Akao - and that is as true for Agile as it is for Quality Function Deployment.

Without the agile spirit, you'll be weaving Agile landing strips and donning Agile coconut headsets until your organization falters, but you won't receive the precious agile cargo, no matter how devotedly you worship Agile Cargoism.

Power to the Product Owner

We call the Product Owner "single wringable neck" of any agile project.
It's a good thing to have one person who is responsible for leading the product to success.

But what happens when you don't let the Product Owner lead the product to success?

The situation has been explored by many agilists, such as in this blog or in this presentation.

My team was tasked to deliver B2B Interface platform.
The team did the coding and got the solution tested. Then, we hit a brick wall: IT Operations.
The department was making issues with topics like firewall clearance, hardware, maintenance windows, capacity management and ... don't even ask. It wouldn't even be right to say that they were wrong with their reservations.
Anyways - we had a delivery date, we had potentially shippable software, but no server connected to the other side.

Long story short, when the CTO realized that this was endangering the product launch, he simply declared "Use whatever resources you need, you have complete control over the department's processes and priorities".
It didn't even take 2 days and the server was up and running!

Lesson Learned

It's not enough to have a PO who understands the product and grooms the backlog. The PO needs to have the full power to make the product successful.
If your organization brickwalls the success of the product with politics, structures or anything else, then don't strangle the PO for not delivering. You need to have a PO who can make the calls whenever necessary, whereever necessary.

Waterfall Kanban

Kanban is a very lean, efficient process for getting work done.
Since Kanban minimized Work in Progress and makes bottlenecks visible, I thought it would be a great way to increase the flexibility of our software development.
Years back in 2008, when I just went through Lean Six Sigma training, I saw Kanban and the first thing that came to my mind, "Let's try this!"

Setting up a Kanban board is easy.
Explaining the concept of Kanban is also easy.
So, we started.

Initially, we did really well:

• Breaking down the work into bite-sized portions made analysis, development and test significantly easier.
• The high visibility of which topic was currently at which stage of the development process made managing the product easier as well.
• Working on a pull principle significantly reduced the stress associated with large projects.
• Seeing multiple cards fly through the board from left to right, getting things done at a rapid pace, significantly improved team morale

So, Kanban was a big success.

However, a couple weeks down the line, problems did start to set in.

What went wrong?

We did Kanban in a classical Waterfall approach.

The swimlanes we had were no "toDo, Doing, Done", but rather:

"Open, Analysis, Development, Test, Done"

Intitially, this approach was fine. Until the stories got more complicated. Then, test simply bounced back defective stories to Development. Some stories even came back to Analysis, because underlying assumptions were disproven in test.

We ended up with a whole mumbojumbo where the Development swimlane was plastered with post-it's and analysis and test were idling.

Lesson Learned

You can only prevent a clutter of stories in an unfinished position if people don't have to idle while other stories are being processed by other people. If anyone needs to wait for someone else to finish, your Kanban setup is doomed!

If you want to be successful with Kanban, you must make sure that you have "T-Shaped People", so that the team can support each other as backlog items move through.

Ideally, you do Pair Programming and the same pair is responsible for the story end-to-end, eliminating unnecessary handovers. Make sure that everything required to successfully complete the story is available in the team: skills, tools, information, ownership.

Just get it done quickly - whatever "done" means ...

Imagine the following:

You go to a restaurant, order a Chicken Wings with fries ... and then wait.
When you finally ask the waiter, he says "Oh, your meal is ready. The cook already went home".

Bewildered, you go into the kitchen to find out that yes, indeed, your order has been processed. Somewhat. There are unspiced, half-baked chicken wings without spices in the oven - and some mash potatoes in the pot.

Which brings me to topic.

I was working for a client who had one developer working offshore. Because he wasn't part of the core team, he only had specific tasks assigned that could be completed stand-alone.

So, this one glorious Friday, he dropped an E-mail "Done. I'm off for 2 weeks of vacation" - and boarded an airplane right away to a different continent.
He had an assignment with customer impact and a clear deadline.
To our dismay, we discovered that there was no code commit. Maybe his mind was already on vacation, but still: we had an issue.
So, we called him as soon as his plane landed to discover he had simply forgotten to commit his code to the central repository.
He had to call a friend to come over to his house who, with detailed phone instructions, managed to commit the code after many hours.
And that's when things started to get funny. We couldn't even build the software successfully: He had taken the liberty of adjusting the core engine to suit his implementation of the solution!

Needless to say, there went the deadline.

Lessons Learned

There were so many things that went wrong here, I don't even know where to start.
And don't even get me started about hiring a single developer offshore to assist an onsite team: that was a business decision made by someone else.

First things first, it is a mindset thing: "Commit early, commit often". It should be habitual for every developer to commit more often than drinking coffee. We sometimes commit as often as 100 times per day in a small team of 3. If you see that someone isn't even committing daily, seriously - you have a process problem and risk losing work!

We didn't have any automated test coverage, so he thought he was doing fine. Especially when working in distributed teams, it is essential to have good unit and regression coverage, it creates a safety net for developers. We didn't have that, so we essentially created the environment where his mistake was possible!

Of course, offshore communication is difficult, but the problem here wasn't that he forgot to commit. The problem was that although we had some form of CI, he considered it "nothing out of the ordinary" to build the software locally to verify his implementation. Especially offshore teams, but every team, is well advised to have one single central Integration system, as the single point of truth by everyone on the team: If it doesn't integrate, it's not done. Regardless of how nicely it works on your own machine!

Wrong assumptions - Take nothing for granted!

As a Product Owner, my primary responsibility is for the "What" of the team, not for the "How".

This week, we had a completely new product and so we formed a new team and did what we always did in projects ...

Communicate the product vision, set up the backlog, define Working Agreements - and get the action on!

We're doing 1-week sprints, because they work very well for our company and those weekly Retrospectives are really valuable.

Anyway. So, we had our Review and the team had done a good job, completed 14 Story Points and done a lot of work that will help them reach a higher velocity later on.

Or, so I thought.

After the Review was over, I casually asked "So, how many unit tests did you write this week?"

... deafening silence ...


Guess what?

The team hadn't had an explicit Working Agreement to write unit tests - and so they didn't!
It's a good thing we have weekly sprints: The Retro will take care of this.

Lesson Learned

Never, ever take anything for granted - you never know who interprets things how!
Better be explicit about the Engineering Practices that will be employed in the project than accumulating technical debt.

Continuous Integration that isn't

I have seen people who run Jenkins and claim that they have realized CI.

Actually, one of those people was me, a couple years down the line.
Before you ask, no, it wasn't in an agile team.

Configuring a Jenkins is easy, and getting the Jenkins to pull a repo, create a build and deploy it on a server also is. But that is not Continuous Integration!

So, here is my story:
We were in a customer project and pretty much nobody had heard of CI, only one guy had an idea "Why should we manually deliver software to the testers? There are tools out there, let's do CI"

And so we did.
The Jenkins was up and running. Whenever the team manager pressed the button, the software got deployed to the Test Environment and the downtime for a new deployment was reduced from a couple hours to less than 5 minutes. As the testers knew when the "Deploy" button was being pressed, usually Friday EOB, test was absolutely not affected by any downtimes.
A big benefit!

However, usually the first thing happening after the deployment - something didn't work.
Like, for instance, the web server. Or the Messaging Queue. Or the database. Or the business processes. Or anything else that used to work in the past.

Lesson learned

Continuous Integration is so much more than automating the build/deployment chain and reducing outages to a couple minutes.

CI shouldn't result in outages in the first place. You can use techniques like Parallel Deployment to attain Zero Downtime for patches.

Also, you haven't understood CI until you have tons of other techniques in place.

CI that works on a button press is missing the point: CI should be continuous, not scheduled and manual.

• If you are delivering dozens of new features with each build, your CI has a very slim chance of locating the error source. Make sure your CI is integrated in a way that each feature has at least 1 build on it's own.
• If you don't have unit test coverage, CI isn't even worth being called such. Move towards high unit test coverage before bothering with CI.
• If you don't have automated regression and smoke tests, CI is more likely to cause harm than help. Invest into test coverage and link the automated tests to the CI server. 
• If you don't have a rapid feedback cycle into your development process, CI has no benefit. Make sure the developer who committed the failing build gets informed and acts within minutes.
• If you aren't acting immediately on failed builds or errors in the deployment, that's not CI, it's a mess!
  STOP and fix if the tests fail. Don't proceed to code further based on harmful code!
• If you are spending a full week on manual integration tests, you may have a CI tool, but you don't have CI!
  Create automated integration tests that can be run as part of the CI process. If you can't eliminate manual components, rethink your approach!

CI isn't about having a tool - it's about having the processes and engineering practices that allow you to deliver rapidly and often!
Real CI comes with a mindset "Let's rather have one too many than one too few deployments".

Done undone

As a Product Owner, it is my key responsibility is ensuring that the customer is satisfied with the product.

As the SCRUM Team, it is our key responsibility that we get the story "Done" in a way that the customer will also accept.

Recently, I had a bad surprise when running a new team.

We all work for the same company, but we usually don't work together in the same constellation.

So, we dug head in, at the beginning of the sprint, we defined the backlog.

As PO, I defined the stories and priorities. Then, my team did the Work Breakdown and defined the tasks required for each story.

During the Sprint Review, I couldn't accept a single story as "Done", despite the fact that the team assumed the story was done.

What had happened?

The tasks all got done, but nobody paid attention to the story itself! After all tasks were executed, the story was so complicated that even the developers had to ask each other how to use it - UX was terrible!

A customer was present in the Review and he simply asked "How do you expect me to do this?"

Sorry for the team, I couldn't accept it as "Done", because I personally understood "Done" as "We are not going touch this again. We can tear up the story card because everything is finished".

The failure?

I assumed that the team's Definition of Done was the same as mine, but the team had a DoD for themselves which considered a story "Done" if all tasks were completed - not when the results are usable by the customer!

Lesson Learned

Make sure that the Definition of Done is not subjective.

Take your time in the first sprint. Remove all subjectivity and unspoken expectation from the DoD.

Everybody must be on the same boat. The team, the PO and the Customer should all have the same understanding of the team's DoD.

Make certain that before the first story gets implemented, everyone knows and understands the team's DoD in the same way.

The worst possible Performance metric

Developer performance is not easy to measure.
Why is this? Because a developer's primary objective should be to find the overall simplest feasible solution towards unsolved problems (or at least, "un-implemented").
However, time and again, there are non-technical project managers who try to do it.

There is an infamous telltale project where allegedly one million lines of code had to be written within one month, but the developers overperformed - producing even one and a half million lines!
Wow, what a great result!*

Refactoring is a technique primarily focused on eliminating code complexity, therefore increasing readability, maintainability and improving overall design.

Story time:

One of these days, my team was challenged with automating a business process.
Occasionally, the customer would ask how we were doing. So, one glorious day, they asked very specifically, "How many lines of code did you write today?"
It was probably the worst possible day to ask this question.
The entire team had written maybe 10 additional lines of code - but deleted roughly 200!
So, at the end of the day, the "lines of code" metric was 190 in the negative!

It actually took a while to explain to our customer why they should still be paying for this ...

The refactored code eliminated a performance problem.
It also implemented 2 different user stories from our backlog.
And in all that, we increased the flexibility of the current code base way beyond the customer's need - with no extra effort!

Lesson Learned

Never, ever let anyone measure developer performance in "lines of code". It is not a success metric.
Don't even go for "tasks done" or "amount of user stories completed", these are all deceptive!

The only metric that should be applied to software development is "outcome".
And that one is incredibly tough to quantify.
In the end, all it means "How much better is the software fit for it's intended purpose now?"

Mocked loophole: Failure to test unit integration!

We recently had a project where we had to experiment with Unit Testing in a Procedural Environment.
Being familiar only with tests in an Object Oriented environment, it was quite tough to figure out how to properly conduct unit tests.

For testing a function, we did what we usually do: mock every external function call.

So, our code effectively looked like this:

function X
  {
   if Y($1) is "true" then echo "Yes"
   else echo "No"
  }

X.test
mock function Y { return "true" }
assertEquals "X in good case" "Yes" X(1)
mock function Y { return "false" }
assertEquals "X in bad case" "No" X(2)

Y.test
assertEquals "Y with good result" "true" Y(1)
assertEquals "Y with bad result" "false" Y(2)

Extra credit to those who already sit back laughing, "You fools, this obviously had to go wrong!" ...

Guessed what happened?

We had done some refactoring to Y in the meantime, and in the end, the unit tests for Y looked like this:

Y.test
assertEquals "Y with good result" "Yes" Y(1)
assertEquals "Y with bad result" "No" Y(2)

Yes, we had changed "Y" from returning "true"/"false" to returning "yes" / "no"!
Of course, the refactoring and TDD made sure that Y was doing what it should be, and we simply assumed that regression tests would catch the error on X - guess what: they didn't!
Because we had always mocked the behaviour of Y in X, there was no such test "Does X do what it's supposed to do in real circumstances?"

Lesson Learned:
If the function works in context, it does what it's supposed to do - but if the function works in isolation, there is no guarantee that it works in context!

We changed the way of writing unit tests as follows: "Rather than use the most isolated scope to test a function, prefer to use the most global scope possible without relying on external resources".

Work Done doesn't matter

It was a small company which just decided to transition towards SCRUM.

The team I coached was highly competent, they actually did a good job. I was serving them as a SCRUM Master and I actively engaged in daily business, conducting story-related admin activity as well.

SCRUM was really good for the team: Impediments surfaced left and right, we started resolving year-old stuff and really tuned up the velocity quickly.

In the first Review, I took the liberty of inviting all the relevant stakeholders.

Here is how the Review went:
Everyone just gathered in front of the SCRUM board and reported which tasks were "Done".
Nobody sat at a computer, and withing 5 minutes, the first attendants were already fiddling with their watches and phones.

The team was not capable of producing "visible results", and even if the results were visible, they were only talking about them rather than demonstrating them.

My lesson:
A team is still focused around Tasks and Work may be applying SCRUM, but is focused on the wrong deliverable.
In traditional management, reporting the "Work Done" is very important. We neither report about how hard and/or much we worked, nor do we deliver "work".

Our result is working stuff. For developers, that's the new software product. For server admins, it may be a piece of hardware where the developers can now install the product. For a marketing team, it may be the new product's homepage.
But for nobody, it's a bunch of completed task cards.

Versioning Failure

It was many years ago, when I first was introduced to the marvels of a Version Control System when working as a developer for an Enterprise Support Platform.
My customer was using the PVCS for release management - I had never heard of automated versioning before.

I love automation, and I loved the things the PVCS could do for me.
However, I quickly grew weary that after pretty much every couple lines of code, I had to do the following:

1. Add modified files to the repo
2. Do a diff to verify the changes
3. Commit the changes
4. Publish to baseline

Whenever I run a manual activity multiple times, my first thought is "Automate this". So this is what I did.
It was very easy to automate. Always the same commands, always in the same sequence - so I just scripted it!

Then came this glorious Friday. It was my last day of work before vacation.
Everyone else had already left the office.
I wanted to complete this one last task. It was trivial, one single line of code.
So I implemented the change, did my tests, ran my script and took off.

On Monday morning, I got a phone call "What did you do to our baseline? EVERYTHING is gone!"
What?

Took a while to figure out my "push script" went rampant and committed every single item in the project as zero-byte file.
While I was on vacation, it took the rest of the team half a day's work to clean out the entire mess I had unwittingly created.

Probably I took this one harder than the team, but here's
My lesson:
I now understand why version control software does not provide "one-step push" for changes. No automation can understand what the intention of your change was.

Not everything that can be automated should be automated.
Keeping the "brain-in-the-loop" is often the only way to eliminate accidents.

And this is why I no longer believe in "full automation".

Are you smart or stupid?

Everyone wants to appear "smart", nobody wants to appear "stupid".
In this blog, the author describes why we should actually dare to be stupid.

Creativity actually requires sometimes doing things which have a high risk of failure.
working in a domain which is planned to the very last detail, where every process is stiffly defined and formalized, there is no more room for creativity.

But only by breaking out of known habits do you have the chance to make marvelous discoveries.

Did you know that Penicillin was only discovered because Alexander Fleming was so stupid as to forget closing his Petri dish full of bacteria samples?

An accident saved millions of lives!