Asier's thoughts

Blogging about software development



I got to the conclusion that the successful delivery of software is all down to care.

If you have developers who care they will write clean code, with unit test and follow TDD approach. The code will be easy to change, enabling the business to make quick decisions against the market so they can beat their competitors.

If you have product owners (or project managers) who care they will try to bring the best features to their products. They will speak to developers and testers and define together the best possible solutions and refine their features in the process.

If you have testers who care they will try to understand the features that are being request to be developed. They will stablish conversations with business people and developers so they will know which tests to write in order to verify the product is working as expected.

If you have operations people who care they will enable their systems for easy deployments. They will talk with developers and give them the power to easily change their code in production while giving technical advise.

In general, if you have people who care they will try to do their best while looking for ways to improve.

If you are one of that many companies struggling with your software delivery my advise is simple: hire people who care! That would be the first step, after that everything will come together slowly.

Leave a comment

Giving estimates

Why do we estimate?

We, the delivery team, estimate so we can predict the time is going to take us to finish a task. It could be a new feature, a bug fix or whatever. This way business people can have a rough idea of how long is going to take to have a code change in place.

But this is just an estimation. Not a commitment. We can’t say it’s going to take us 3 days and then rate success or failure depending if we met that estimate or not.

We are humans and we are not good making predictions. We are optimistic. Even if we could predict exactly how long a task will take many things could happen in between that we weren’t expecting.

Making predictions for long projects it’s even worse. If we are bad estimating for small tasks imagine adding up all those deviations.. Estimating a whole project it’s wrong. And that’s why we have agile or things like #norprojects. Even #noestimates.

So what do we do?

First, we are aware. Estimates are going to be wrong. So we will tell the business that our estimates are just predictions and tell them we are giving just a guess.

They are going to be wrong specially in the long term. So we will give estimates to the business within a sprint, one week or two weeks should be the longest. If they ask for a feature that it’s not within the scope of the current sprint we will say “Sorry, I don’t know”. If somebody comes and ask “when do you think the project will be finished?” we will say “Sorry, we don’t know. I could give you a day to make you happy but that would be just lying and I don’t want to.”

So we will be honest. We will be professionals and don’t tell lies to our managers or business people just to make them happy for the time being. Managers want to know when things are going to be finished so they can put in place all their figures and budgets and all of that, but using estimates for that it’s just lying. Also if we are working in a feature and we find an impediment which is going to slow us down, we will say it as soon as possible.

We will build trust.

Leave a comment

Iterative waterfall

A new software project starts in your company. Budget has been approved and a (soft) deadline set.

Hey.. You are lucky this time! One of the managers “knows” about agile, he has read a book about Scrum. So we are going to do Agile this time! 🙂

The project manager gets renamed to product owner and starts writing stories for the whole project and adds them to the backlog.

Yes. All of them!  She already knows what we need for the whole project.

We will work in iterations. 2 weeks. Let’s call them sprints! 🙂

We will estimate the stories. We will check how many stories we are able to finish per sprint and based on that and the estimation we will know how many we will be able to do in the next sprint.

Let’s call this thing velocity. The velocity tells us how many stories we are able to get done per sprint based in the estimates.

Heyyy!! And look at that! If we have EVERYTHING we need in the backlog, and EVERYTHING estimated.. we can find out when we will finish the project and be able to deploy our code to production!!

OMG! We are sooo Agile! 🙂


Does this sound familiar??

The story I just told you it’s real. And I have seen it many times. And no, sorry to disappoint you, but that’s NOT agile, it’s iterative waterfall. It’s the same as doing waterfall but iteratively. All the requirements are set up front as user stories in the backlog and then work is done through sprints. This plan is rigid and bound to fail. Isn’t the goal of Agile to embrace change?

I have met so many people who think they work in an agile environment. Who think they are doing scrum because they work in iterations and know all those buzzwords: sprint, stand up, retrospective, velocity, etc. These people are just following the book but miss the whole picture. Following the practices because that’s how it has to be done.

Forget the practices and look deeper into what they mean. Which are the values? Why they exists? Why should I follow them? Should I follow them?

Is this what we do really agile?

Leave a comment

Specification by example

Last week me and my colleague  Jorge went to Agilia conference in Brno, Czech Republic. The conference was on average good, but what we really enjoyed was the Specification by Example workshop we attended after the conference.

It was a 2-days course given by the great Gojko Adzic. He went through it with explanations of what Specification by Example is, how we should apply it at work and which are the benefits of it. We alternated that with several team exercises and many coffee breaks 🙂 We also learnt how to write good and bad specs. At the end of it he told us about the real software quality and even gave us an introduction to Impact mapping!


So what’s Specification by example?

Specification by example is a technique which brings together the requirements gathering and QA testing processes in the software development cycle. It is also knows as ATDD or even BDD, but I don’t really agree with the last terminology..

Basically it is a way of writing specifications collaboratively  which are then converted to automated  acceptance tests.

How does it work?

Testers, developers and business people will get together in one room and will write specifications for the new features that they want to implement. In order to do that they will get separated into different teams, get a white board each and write examples of how the system should be working after the new features have been implemented. Once all the teams are done they will get together and compare the examples, look for differences and agree in some common ones.

Spec in Gherkin format

Spec in Gherkin format

After the team workshop is over, testers will take those examples and automate them with a tool like cucumber or fitness. Developers will implement the features and will know they are finished when these tests pass. These tests will run against the actual system frequently. If tests got automated before the development work starts this is know as Acceptance Test Driven Development, the same as TDD but from a ‘higher’ point of view 🙂

It is not really necessary to do the whole team workshop, but it is the most effective way. However, sometimes it won’t be easy to get all those people at the same room and just bringing together one tester, one developer and somebody from business will do it – the three amigos way. At other occasions the team will be distributed, one person writing the spec and the another one or two reviewing it may work.

Which are the benefits?

The two main benefits brought by specification by example are having a single source of truth and getting a quicker feedback.

The examples are requirements and also tests. What is written in the requirements is automated as tests and run against the actual system. If a requirement changes the test will change and the system will have to, if we add a new requirement there will be a new test and the system will have to change to make it pass. Basically, what is specified in the requirements it is what the system does! No more requirements document and qa test that differ. The examples are the single source and we know they say the truth because they are automated and run against the system frequently. This is known as the Living documentation.

The good thing of bringing together business people, developers and testers is that we will spot things much earlier in the process. Instead of waiting to solve misunderstandings once the development work has been finished we can bring forward this feedback to the point were requirements are gathered. Handing over documents from Business Analyst to developers and then to testers is not the good way to do it, many times things will get lost and won’t be spotted till the testing phase or sometimes even production! Put everybody together before the development work starts and many communication issues will get solved in no time, rather than waiting till the end of the iteration.

Another key benefit of the workshops is that they will bring a better understanding of the actual system to everybody and will help modelling it. When writing the specs collaboratively everybody will get to a common language which then can be used when developing the system, documenting it or at any further discussions later on so there are no terminology misunderstandings – this is known as the Ubiquitous Language.


I kind of knew about specification by example before the course and we were already doing in it a certain way at work with the three amigos way, but not properly. I hadn’t heard about the team workshop and I find it quite interesting to be honest. I would like to try it. I just need to convince business people 🙂

As a feedback about the course I would say it was awesome! It was presented in a quite entertaining way. Challenging and fun team exercises in between engaging talks from Gojko with real life cases from his work as consultant. At the end we got a about 10-page document that summarizes everything. I am planning to get the book and learn more about it.

Maybe the one about Impact mapping too.. sounds quite interesting!


Leave a comment


Some years ago I went to university and did the computers engineering degree. I remember we had one of those subjects related with business management that you wouldn’t expect to have in such a degree. We learnt the basics of manufacturing processes. Among other things we went through things like mass production, Fordism, Taylorism and Lean manufacturing. Even if it was kind of interesting I thought all of that was pointless for a guy like me who wanted to learn just things about computers.  How wrong I was!!

Let me explain you why..

Toyota_logo 2

Lean manufacturing or just-in-time production is a manufacturing process developed by Toyota in the 80s. Focused on eliminating waste and adding value, lean brings an improvement to the models  based on mass production created at the beginning of the century.

These processes created by Ford and Taylor had as main goal to produce as much as possible – the more products we create the more money we make. So these processes were centred on splitting in little tasks the whole process of manufacturing a product and then trying to improve each single task as much as possible. Little improvements can make a big difference. If we can improve the whole production chain we can create products faster and cheaper than our competitors.

What Toyota realised is that producing as much as possible is not always the most efficient thing to do. Mass production creates big inventories for products with the purpose of creating a good availability of products for the customer.  The problem with this is that the storage of products has a cost, a cost of money and resources. This is know as waste. Also this products will have no value until they get to the customer.

So Toyota thought “What if we just create only the minimum quantity of products required for the customer needs?” “What if we could predict the customer needs and  deliver products just-in-time? We won’t need all that inventory!”. So Lean was born. Lean identifies different type of wastes in a manufacturing system and tries to eliminate them while adding more value to the processes – preserves value with less work.

This just-in-time production approach brings great flexibility and responsiveness to change. Which is basically what all these new software methodologies – a.k.a agile – try to tackle nowadays.

Based in iterative and incremental development agile methodologies aim to deliver software quick and often with a close customer collaboration and putting people first. The consequence of this are a shorter feedback and a bigger adaptiveness.  These methodologies are a significant shift from the previous waterfall models where everything is design up front with little or none response to change. Agile has been seen as the way to go in nowadays world where everything is constantly changing and almost every company tries to adapt it.


Lean has many similarities with agile. Mary Poppendieck and Tom Poppendieck saw this and wrote a book about it which I just read: Lean Software Development: An Agile Toolkit.  The book takes the lean manufacturing principles and adapts them to the software environment.  As I read it  I could see how everything I knew about lean manufacturing was fitting with the agile methodologies perfectly!

The funny thing about the whole thing is that I finished university without hearing a word about agile! Yes, don’t ask me why… I learnt agile by my own at my first jobs and reading books. One day, I bumped into lean software development and I thought “shit! This rings a bell..” and suddenly all my memories from the first years of uni came back to me! Everything started to fit together! 🙂