Failing Fast

Failing fast leads to one thing, Success

It is important that your code base, continuous integration, tools and even your processes are able to fail fast. Human’s are a different consideration.

Why should a given process fail fast? What value is there in failing quickly?

Failing Fast

The greatest value in failing quickly is perhaps the ability to react to changes quickly.

Why fail fast? Failing quickly helps to resolve issues quicker since they are surfaced sooner. Let’s have a look at some of them:

Bug Cost

The earlier a bug is caught, the cheaper it is to fix

Wait, what does that mean? Cheaper in what sense, money, time, fingers?

Depending on the stage at which a bug is captured, the cheaper or quicker it may be to fix. It is therefore in your interest to fail quickly.

Let’s assume that a developer is working on a feature branch which is yet to be ‘merged’ into the master code base. Assume that a bug was found on the branch before the code was merged. Now let’s assume the same bug was found sometime after the code was merged.

In the above scenario, would the bug be easier and potentially quicker to fix before or after the merge? Does it even matter?

You can bet your bottom that it absolutely matters!

The sooner a bug is found between planning and deployment, the quicker it is to fix. Having to fix a bug with less code and less overhead makes it easier and quicker to fix.

Failing quickly directly impacts bug cost

Test Pyramid

What is the Test Pyramid?

The Test Pyramid is the principle of rationally dividing up the number of ‘types of tests’ one may write for an application. This is what the pyramid looks like:
testing pyramid

The length of each slice in the pyramid represents the number of tests you would write.

In short, the principle here is to write many unit tests, some integration and very few UI tests. Enough theory, how does this help to capture failures quickly?

The lower the test form, the quicker it runs!

Unit tests run faster than integration tests, integration tests are quicker than UI tests and UI tests are the slowest horse in the race. Let’s not get into the why or how, just take my word for it.

If we accept this concept, then this directly can help us to fail quickly. For instance, if we capture a bug on the unit test level, it would be quicker to fix since we found it quicker.

In conclusion, if a bug is not capture in a unit test and instead a UI test, it may be more expensive to fix.

Learn Quickly, Make New Mistakes

Failing quickly provides an opportunity to learn quickly

If you are able to fail quickly, this helps to promote learning.

As a result, the probability of repeating the same mistake should decrease. Consequently, this also means the probability of making new mistakes should increase.

In Agile, this is an important concept. This effectively means to quickly translate an issue into a learning outcome.

Failing Quickly, Any Real Benefits?

It should be clear that failing quickly does hold a lot of benefits, the biggest perhaps being able to adapt to changes.

We should absolutely leverage existing concepts such as the Test Pyramid to quickly capture bugs and reduce the cost of fixing them.

Some of the greatest inventions have come out of failures, it should be in your interest to fail quickly. Your future self may thank you.

Stand Up, Are You Doing it Right

A Stand Up is powerful, only when done right

Most of us have experienced taking part in one, have you had bad one?

The Traditional Stand Up

Let’s quickly establish the fundamental rules:

  • For starters, you must physical stand up at a set time every day
  • You must answer the following three questions:

    • 1. What you did yesterday?
    • 2. What you plan on doing today?
    • 3. Are you blocked on anything?
  • Your answer to the above three questions must be relevant to everyone
  • Finally, you refer to a board which helps to reflect the progress of tasks and / or stories

The above are all hallmarks of a quick, clean and valuable Stand Up. However, some bad habits can pollute the form.

Here are some interesting behaviors that I have observed over my career:

Virtual Stand Ups

Part of the philosophy of physically standing up in close proximity to your peers is to help encourage quick discussion.

A Stand Up is not designed to help people get comfortable. When conducting a virtual Stand Up, this almost goes against the thinking behind it.

Now, let me be clear. I am not knocking the idea of virtual Stand Ups. Sometimes you are simply not able to physically make the Stand Up in person and as such need to sign or log in virtually.

It is however important to mention that virtual Stand Up’s may encourage taking more time than needed.

Sit Downs

Sit Downs is a trend that I have seen, sadly.

In this instance, everyone is encouraged to sit down as opposed to standing up (assuming you are physically able to Stand Up). When a number of people get together and sit down, can it be considered a Stand Up?

I think physically Standing Up is vital to the theory of taking part in a Stand Up. It is not supposed to be a place where you get comfortable and relaxed. It is a format in which you deliver very quick and precise information whilst also being conscious of the time.

20 Minute Marathons

This is perhaps the worst that I have seen. In this instance, the Scrum Master appears to take turns talking to each member. As opposed to letting everyone quickly go through their updates, instead small discussions take place. The Stand Up is not a forum where you should have long running discussion.

What’s worst, anyone who actually wants to simply get away to their desk is not able to since everyone who is taking part is yet to speak.

Planks

This is a little new, perhaps very radical.

The approach here is to hold a plank whilst giving your updates. I came across this method in a particular place and it was a very interesting approach.

The idea behind it was to encourage everyone taking part to only contribute words and sentences which answered the above three questions. This approach certainly made it a lot quicker and cleaner. However, this also made it more difficult. If not for all, then certainly for some.

The downside to this was the fact that contributers were sometimes more concerned with out-planking each other instead of listening and making contributions.

Is it worth making something more difficult in favor of getting it done quicker?

Clean Stand Up Benefits

The traditional approach of the Stand Up is great. It works very well, really helps to deliver vital information in a quick, small time frame and also provides the opportunity to quickly plan for change. It seems the traditional approach works for the most part.

If the traditional approach works, why change it, why break it?

Agile Pairing Power

Agile pairing, takes two to tango!

Once upon a time, I too did not see the benefits of pair programming. I saw work duplication, invasion of privacy and moments of broken concentration. And then something happened, I saw the light!

Why did I suddenly change my mind?

Benefits of Agile Pairing

Let me tell you about my sudden ‘Change of Heart’.

Is Team Work Better?

Why have two developers working on a task when one would get it done faster? This is how I used to think.

I had just joined a new company and was ‘encouraged’ to speak to developers instead of reading introductory documents. Being the new guy, I did not have much choice. I decided to sit down and ask questions.

I thought this would hamper the developer, to my surprise it did not. In fact, anyone that I spoke to or pair programmed with was more than happy to help. Going further, without realizing it at first I was actually introdusing myself to the entire team in a more ‘intimate’ fashion.

I found that I was picking up things a lot quicker, having my worries and doubts resolved quicker but more importantly I felt part of the team on day one! Why have two developers working on a task when one would get it done faster? Not sure how valid this statement was anymore.

Clearly this was taking time, I may have slowed others down. However, was my introduction to the team a really big time impact? I felt it was quicker for me to be a productive part of the team by pairing. I started to see Pair Programming as a way of on-boarding.

Are Code Reviews faster?

My way of programming as always worked. Books, blogs and conferences helped influence how I once programmed. I suddenly found myself speaking to developers and writing code with them, in the process learning a great deal more than books and blogs. This wasn’t entirely surprising but I did find myself asking why I had considered books and blogs a ‘better source of learning’ when compared to a fellow colleague.

Going further, I started to revisit ‘my way of writing code’. I started to write code which felt easier to read, to understand and to manage. The interesting thing about this particular evolution of my coding standards was that it was not imposed on me. In fact I saw the change and a need to ‘upgrade’ my standards.

Did I self improve because I started to talk to others?

Is Velocity impacted?

Going back to when I was not the biggest fan of pair programming, my biggest concern was the impact on team Velocity. This goes back to the notion of one task by one developer vs one task by two developers.

Let’s assume that a developer is stuck, what do they do? The developer can’t ask another developers since everybody is in the ‘one person one task’ mindframe. Most likely if your stuck, you go and get a coffee, take a walk, come back the next day and tackle it again. Failing this you ask someone else.

Now let’s assume a pair were working on the same task. The probability of one developer getting stuck is significantly less since there are two developers. Pair programming in this instance can help to solve problems quicker.

Before I adopted pair programming, I searched online for solutions every time I got stuck. I tended to ask colleagues as a last resort. I guess I did not ask, I thought it would slow down someone else. Not sure why, it toke me some time to realize that being stuck is the same as not adding towards the velocity.

In a very round about way I discovered that pairing actually increased velocity.

Is it worth it?

The big question, is it worth Pair Programming?

Let’s list the possible disadvantages of Pair Programming:

  • More man hours to get a task done
  • Ego and attitude play a part – this can result in enforced code vs quality code
  • The idea of a ‘driver’ and ‘passenger’ does not breed creativity

And now the advantages:

  • Better learning
  • Higher code quality
  • Problems resolved quicker

What do you think, do the advantages outweigh the disadvantages?

I thought so!

Agile Is Just Waterfall

Agile is just Waterfall, really?

Waterfall is a wonderful concept. It allows managers to ‘plan’ for problems. Also allows Developers to fix issues before testing has began and testers to possible approve products with bugs. In a nutshell, Waterfall is a little ‘stick to the deadline’ intensive. So, how does Agile relate to Waterfall? Does it relate to Waterfall at all?

Is Agile Waterfall

Waterfall is a form of ‘delivery plan’. The biggest disadvantage to Waterfall is the strict deadline and delivery requirements. Agile tries to remove some of that burden, but how? Well, let’s take a look at the process for Waterfall:

agile is just waterfall

In general, Waterfall consists of Planning, Development and Testing. However, due to the nature of Waterfall, it is more like a cascading effect:

agile is just waterfall

Agile has a number of similar methodologies. The similarity they share with Waterfall include planning, development and testing. Unlike Waterfall, Agile allows you to revisit previous phases. This mean that Agile is just many sets of mini Waterfalls (like so):

agile is just waterfall

Does Agile Share Waterfall’s Pitfalls?

In short, no. You are given the luxury to repeat any phase, re-test, re-deploy in quick cycles. Methods such as Kanban and Scrum inherit the principle development flow of Waterfall but not the strict ‘stick to the time line’ thinking.

Agile Is Mini Waterfall

We can establish that Agile is a set of mini Waterfalls. Every time you pick a task, it requires planning, development and testing. The same process is then repeated for other tasks. Two stories which are picked up can have the same process running. The same processes may run in parallel or sequentially and may or may not impact each other.

Agile is in fact Waterfall, but due to it’s design it does not inherit the ‘fluff’ of Waterfall.

Is Agile Fragile

Is Agile fragile? In Software Development, Agile is a way of developing code. It is essentially an unspoken promise of new functions, fixed bugs, automated tests etc delivered in a short period of time. Agile is pictured to be a framework which helps to ‘get things done’ quickly. Agile is a framework, hold that thought.

Just What is Agile?

Firstly, let’s take a second to quick summarize Agile. Agile is a set of methodologies and techniques which can help teams to break down big problems into small manageable ones. These processes can help to increase visibility of who is doing what, identify blockers and plan ahead. With all of this said it sounds like having these processes is a good thing, right?

Agile Processes

We briefly touched on Agile processes, just what are these? The world of Agile is broken into a number of similar methodologies such as XP, Scrum and Kanban. They are different in practice yet similar as well. We then share some common processes between these methodologies such as Stand Ups, Retrospective, Planning and Story Grooming. The purpose of each of these processes is outlined with clear purpose yet we do tend to divert away from that. For instance, we aim to have Stand Ups performed as quick as possible yet at times we tend to have Super Stand Ups. In other words, Stand Ups which turn into discussions.

We try to estimate stories in our Planning session but sometimes estimating stories becomes more of a business requirement as opposed to actually trying to predict what we can achieve. In layman’s terms we try to take an existing system, change it and try our best to adopt it to our needs. Again, this also sounds like a good thing.

Is Agile Fragile?

If all of the above is ‘good’ then what is so fragile about Agile? Let’s take an existing technique such as Stand Ups and discuss. Firstly, what is a Stand Up? A Stand Up is a very scheduled daily adhoc meeting where every member of a team gives their updates in three key points i.e. what they did yesterday, what they plan on doing today and if there are any blockers. Seems easy enough, right. But have you noticed that in Stand Ups this flow is not always followed. Sometimes people are interrupted, sometimes the ‘what they did yesterday’ becomes a topic of discussion that not everyone in the team needs to know. Or worse the topic almost hijacks the entire Stand Up.

In this event the Stand Up almost goes against its core purpose i.e. to provide a super quick update to the entire team. So, why does this happen? Why do Agile processes start to differ from their original intention. I think this happens due to two key factors, a lack of understanding and discipline.

Discipline in Agile

When we take an existing method and change it, as long as it works and generates results then this makes people happy. However, if two people take the same method and adopt it to their own needs and at some point converge, this can create issues. In short, an adopted method which works for one may not for someone else. One reason why Agile can be fragile is due to the way people adopt methods. Trying to maintain a degree of discipline does help to reduce this but change in an Agile environment is inevitable.

So, is Agile Fragile?

Yes it can be, especially if new forms of an existing methods are created by people. In my years of working in many Agile teams across many organisations, I have seen the same method (such as Stand Ups) used in very different ways. Ultimately if it works then there are no complaints but in the Software Industry we appear to have a very overloaded approach to Agile. What do I mean by this? An Agile process such as Scrum may be followed slightly differently between two companies even though the way Scrum should be followed is outlined clearly.

At the beginning of this post I mentioned that Agile is a Framework. The concept of a framework is to allow someone to take something and use it to ‘get stuff done’. But when you take this framework and change it to an endless number of variations then it becomes difficult to keep track of how it is used.

In final, Agile is not fragile as the whole concept of it is to allow change, to allow quick change. Doing things differently does not mean that it is wrong or right but it does mean that people need to adopt to changes quickly.

What do you think? Is Agile fragile?