What if your team is completely agile minded?

Imagine you are an agile coach. If you are already one, the imagine part is easier. Your goal is to get your team to the top level of agile development. Let’s get back to: ‘What is agile?’ Agility is the ability to adapt to any circumstances. Not just the urge to adapt, or only wanting to adapt, or the ability that you can adapt, but that you are adapting. It’s a process. You are moving to the circumstances. They are leading. And if you are not capable to follow, for any reason, you are not being agile.

But, is this really as tough as I just described it here? 

Are there no excuses? Let’s try to imagine it in real life, in a real company. There is a difference between you and the world around you. Let me explain. If your company isn’t agile, doesn’t always mean that you are not! If the company has a policy to make his software evolve not based on customers but their own intuition, then they are not agile to their environment. Their software solution is probably dying a slow death. Besides the point I’m trying to make here, if their customers are followers and not depend on their own vision, the company does not have to adapt then there is no point of discussion in agility. What I’m trying to say is that if your environment is not changing, you don’t have to. You maybe have the ability to adapt, but it’s not being triggered. The question is, are you agile if you got the ability to adapt when you don’t need to?

How do you know you’re agile? 

Now that’s a good question! How do I know that I’m agile while I’m not given a change to be? Is there some way I might lose my ability to adapt when I’m not challenged? I think you can actually. Fortunately we live in a society which breaths on opinions. So if you are not changing in the way you develop your company’s software, the only possible cause there can be… You’re right, it’s your company! Go ahead, blame them. They are taken away your gift in adapting. (It only complies if you are willing to be agile of course.) 

So if your team is agile minded and you don’t get any step further, what do you do? 

This is the biggest challenge of all. Make the company agile. Now that’s a big task to do. How on earth are you going to do that? You only are an agile coach, or a developer. (With developer, I mean any the people in the development team.)

As a company why do you need to adapt to y

our environment?

What’s the use? What is the problem if you don’t? In what kind of trouble are you getting yourself into? If you’re environment is still in tune with your software, why should you worry for the future when things are going to change? What triggers you to react on changes and how do you prepare yourself for something you haven’t encountered yet?

You have to find out what likely is going to happen in the (near) future. 

1.  The customer waits for a long time to get the functionality they want. (The customer wants it by tomorrow at least.)
2. The customer doesn't get the long-awaited features at all. (Because the company thinks the customer wants something the company came up with.)
3. The quality is not good enough. (The development team didn't quite catch the goal or reproducible examples/scenario.)
4. The features delivered are not intuitive. (The developers do not feel what the customer wants and their idea of functionality, location of buttons, labels or workflows do not correspond the customers ones.)
5. The company is creating a risk by implementing long going software trajectories that runs out of alignment with customers’ expectations. (If you don’t deliver incremental software, you do not get feedback on time but weeks or months later and then the time you spend on that changes can be thrown away.)
6. The customer gets irritated. (When the functionality is not what they expected, they assumable go the next software provider.)
7. The Employee is getting frustrated. (Because of all the bugs, angry customers and atmosphere.)
8. The employee is going to be dumb. (He is not challenged anymore and it’s more like working on an assembly line, instead of his vivid empathy or imagination.)

So, these are good reasons to be as agile as possible, right?

Two feet on the ground (Refining)

This is what we want: we want the user story under control
This is what the PO wants: the PO want the user story in the sprint and finished in it.

Theory vs. reality

There are a few things I need to explain or bring up before we go further.
Most of the pitfalls we encounter are these:

• The user story is bigger than we thought
• The acceptance criteria grew throughout the sprint
• We came across things we didn't think of at first
• We needed more resources than we thought.
• The user story actually became clear in the sprint itself.
• The PO thought different about the finished user story than the developer

All these things happened to me and the teams I worked in. Of course there are uncertainties along the way but most of them can be taken away from the sprint easily.
Why was the user story bigger than we thought, how is it possible that we didn't predict the resources we actually needed? It's all in our own hands. I'll tell you why these things happen. The familiar workflow a feature is taken in and out the sprint is this:

• First, the customer wants something
• The PO takes a look at it and writes the user stories
• The user stories are in the backlog so they eventually are automatically taken into the sprint
• The team predicts/pokers its story points
• The team develops and tests and the user stories are done.

This looks like a logical workflow, I think to all of us, but it's not. It's too static to be applicable in reality. This doesn't work! What you need is more collaboration. This workflow comply if we were robots. But we are human and I'm glad we are. And humans don't act static. They surprise us on every occasion. And there are some hidden features within humans;

Humans and interactions

We all want the people to know that we fully understand the user story cause we are supposed to know everything about the program and we don't want to look stupid. We always tend to act better than we are.
And what is also in our blood: we want to help the customer, and preferably as quickly as possible. We don't want anybody waiting for us.
We don't want to let the PO know that we don't know enough of the current situation in the software. We don't want him (or her) to know that it's pretty hard to understand what the user story fully implies. We don't want to say 'no' to the PO cause we love to say 'yes'! And we do. We always say 'yes' to the PO.
We don't like to look dumb or inexperienced. But when we are not feeling dumb and we are experienced, we lack to see all of the different angles of the story. We don't want to sit next to the tester to understand what he wants to test, because we can do that ourselves good enough. These are the most common human behaviors we encounter.

Use your humanity!

Make sure you discuss a user story before the PO decides it must be picked up in the next sprint. How? Ask questions! Ask a tester if he can test it. When he says 'What the hell' the story is over. If he says 'I think so' try to figure out what he needs to be confident. Define tasks to clear things up for him. If a developer isn't certain about the code, ask him why. Ask until there are no questions that impede the story to be clear. And I really mean the story and not the implementation. The trick to find the doubts is listening. Listen to the conversation that is being held. If you here 'I think' or 'probably' or 'If this' or 'what is' or 'who is' then there's a threshold in the story. All these questions have to be answered first to eventually able you to estimate the amount of story points. Do not try desperately to answer all questions with the purpose to eliminate all of the doubts. There can be questions left unanswered, as long as you all got a good feeling about the story and you know exactly what the PO wants and why the customer wants it. A good thing about fire some questions is that you KNOW that there are questions about it and you take it into account.

The ultimate computer, so far.

Let's take it a step back shall we? If there is a project for example coming up next month, you really need to know what it is. Let the PO present the big picture. It helps him, because he presents it and he never had before, and that helps him to understand it better. But last not least it helps the developer. You know the brain is a beautiful piece of equipment. What we don't realize is that when we are presented and familiarized with the project, our brain is without knowing processing the information in our head. It strikes us with ideas on moments we don't expect it to happen. It is a computer unconsciously rattling on a background process. So if you are planning to sit together again on the project, it feels like you've had a good night sleep on it. You become more alert and ask the right questions and maybe the PO let you break down the project with him or her into features and user stories together.

Summarized 

A developer team needs all the individuals within the team, the team needs the PO and the PO really needs the whole development team.

Finish your sprint in time!

In time, in time, in time (echo, echo, echo).

Yeah right, in time... Which time are you referring to? Your time, our time. Probably the sprint time. And why is it so important to you to finish sprints at all costs. Isn't it more valuable to serve the customers needs? What is it with you all?
First of all, I know what's behind this. We want to be experts at estimating the sprint length, or better: estimate what's going to be build. It's a way to get better at scrum. But what's the importance of speed milestones when your scrum team is developing at the most effective way or still is growing on that? What do you want to accomplish with that kind of stirring up? The only thing you get is incensed team members if they lack finishing the sprint, even if they are one story point in disadvantage.
So stop the frustrations and just focus on getting better. There are more ways to become better than trying to finish the sprint. Like pushing yourself to the limit and know the failures that you will make are guidelines to become just even better!
For a long time people thought that one mile could not be run below 4 minutes. Like the sound barrier in aviation. Those things could not be overcome. But the record of one mile is now at 3:43 and the sound barrier was by far not the end point of speed. We push ourselves cause we want to be better. When we don't: we won't. If you're at peace with your performance, you will not get better. If you are always doing the things you are good at, you will never, ever get better than you are now. You must want to get better and focus on the things you do worst and try over and over again. Then the boundaries will leap further than you ever could imagine.
You are not a failure and you absolutely fail no one if you do not manage to finish the sprint in time, in time, in time...

I'm always right!

Okay, what about these blogs? If you may not know, I'm not writing blogs to let you think that I am always right. I'm surely not pretending to be someone who knows it all. Then what am I writing for?

When I'm not sure about something, I have the tendency to seek for answers elsewhere. When I want to support anything to persuade someone toward my opinions, I seek for a foundation. Now here come the tricky thing: I got the lurch to seek out for my answers on Google. Most of the time I get what I want to sustain in my opinion. Don't get me wrong on this, cause I gotta say, Google helps me with thinking and triggers me with the keywords it presents with the hits I find. I read opinions, counter opinions, evangelism, opinions of doom thinkers and replies in forum post answers.

Searching for what we want to find.

The thing is, I realized, when I'm googeling, I'm searching with keywords which underpin my opinion. In other words, I am looking for the right answer. And that's the answer I wanted to find! Bare with me for a moment: Google's searching the answers I want to know, so Google is not searching for answers I don't want to know. That's mainly because I do a search which is suggestive, so it's calibrating my answers.

Wanna try? My sister posted on Facebook that she put dolls into her fridge. Her daughter suffers from a kind of asthma. So the first thing I could think about is that she puts dolls into the fridge to kill germs and bacteria. I always thought that bacteria could only be killed at high temperature and that is at least above 60 °C (140 °F) and surely above 80 °C (176 °F). So I searched for 'bacteria freezer' and Yesss I knew I was right! Bacteria does survive intensive cold.
You see I was looking for answers I wanted to see. What I didn't know is that it was all about dust termites. And if you look that up in Google you see that dust termites indeed die in the freezer. I was too suggestive and was looking for the things I wanted to find.

So beside the fact that I am the cause of the results in the hits by searching with suggestive keywords, there is an other probability which can inflict my search for knowledge and opinions. Google is a learning search engine. It knows what I am looking for. It may not be as strong as we think, but on the other hand it may. I have a history on searching the net. And when I am fond of Dan North, which I am, I think, Google is maybe providing me with quotes of him or people who are in some way connected with him or exercise the same opinion.

The gurus!

The point is: everyone is looking for answers they lay there confidence in. A good blog with a good story is comforting your mind. The more everyone stops searching after reading a salutary blog, the more counter stories will not show up on the top of the list of hits. So you become to like Kent Beck, Dan North, Martin Fawler or Robert Cecil Martin known as Uncle Bob. And you rely on there knowledge and talks. And yes, Kent Beck has seen a lot of companies and knows a lot about coding, but he has never seen your company and doesn't know your companies code, scope or vision. Eventually you have to decide for yourselves what to do with your code, standards or testing. You have to decide how you want to do things or what tools you want to use. Of course you can seek for knowledge on the internet and try to prevent pitfalls which other happened to fall in. But try to look beyond that and create your own interpretation of everything. If you are only following the rules, you are not being creative. If you see beyond the rules, you may see new things and new equipment, new boundaries, new challenges and new possibilities!

Invent something: be creative!

It's like the inventors of the level tool. They wanted to create something new and evolve their invention. The only level back than was a horizontal level and had two parts, namely a straight bar and a bubble. No one ever felt like they where needing anything else. They where satisfied and did not know any other possible use of it, cause they where in a second person perspective. (They did not know what they didn't know!) A good solution to evolve your product is to break it down into smaller pieces, multiply or devide it and re-assemble it in an other product. What the inventors did is taking all the components apart. Despite there where just two parts, they did take it apart. They looked for all possibilities and created something new: a level with more than one bubble for the different angles! So if you use a tool that has a purpose or was meant to do something, you don't have use it only for that! Maybe you can use it for something no-one came up with. Play with things. Don't let any tool stop you by suggestive borders or boundaries!

Is it about regression testing or is it about BDD?

Let's make one thing clear. Tools are not to redeem you from any harm. They are not the solution to your unbalanced coding process! In fact, you have to make sure your creating software like there are no tools at all. And then think again: is my software up against changes? Am I on the right track for clean code or am I trying to consciously balancing the solution on the edge of the abyss? Don't depend on unit testing as the only world saving tooling! Be smart!

You have to admit, there is a leak in this utopia, cause we provide automation to our customers. Thus if we are specialized to do that, we are fooling ourselves if we denied our nature: we are as lazy as the customer. Maybe lazier than they are. So testing isn't so bad at all. So let's differentiate a bit shall we?

Why do we want to test our software? First of all, you want to make your code transparent to all of your colleagues. They need to know exactly what it is doing and how it is working. If they can't understand it then possibly two things are going on. Either your colleague is not capable of reading code or you have fallen short in writing it well. Second, we are not infallible, as much as we like to think of ourselves. (I know we do: we all like to be liked and we like to pretend to be someone who doesn't make mistakes or less then anyone else. It's like we all are better then the average, which can't be true, because then the average is lifted) And despite our effort and our knowledge, we all do make mistakes. That's not bad. In fact, that's good and its reality. So don't worry about that and don't worry our managers worry. That's the point where tests come in and assist you. They help you when you starting to fail. It's obvious that you can't think about all things at ones. Even the best programmers aren't flawlessly programming and so you are not. So let's move on to something I forgot to mention.

Two steps back!

Before you create good code there must be something done in advance. As a developer we think that we are so good at solving a problem and creating a solution, we forget what we really are. We are ordinary human beings. So erase the image of the superhero you think you are. (Mmm, isn't that the reason we give our teams such graceful names like 'Men in Black' or 'The Avengers'?) What we need to do is acknowledge we can not write clean code on our own and we don't come up with the best solution on our own. We need someone else, or more than someone else. We need our fellow developer to challenge problems. (Off the record, I'm not consistent with the word 'problem'. This is why: you need to put things in perspective! My mind is forecasting a situation. If reality is different, then I experience it as not acceptable and I am creating my own problem. If I adjust my perception, then I accept the effects of the situation more easily. But lets resume this epistle, shall we?) If we collaborate with our colleague developers we earn synergy! And if we let customers (or on-site customers) involve, we know exactly that the ideas we come up with are fruitful and honest. And that's when we talk about BDD.

BDD is not a tool, it's a mindset. BDD forces you to talk to the customer (in any form) and create scenario's to evaluate the solutions we had in mind. And the beautiful thing here is that the scenario's extent the range in clearly thinking. Scenario's point out the real meaning and rule out mistakes. And it helps you to see the right objects through writing variants, like abstractions and loose couplings etc.

Summary

Let's make a summary of BDD and scenario's. Scenario's will help you with:

• extending your thinking range
• earning synergy by discussing them with your colleagues and/or customers
• seeing abstractions and creating maintainable code
• point out the true meaning of the feature
• rule out mistakes, like misinterpretation or bad paths
• behavior documentation
• unit tests

SpecFlow is a little of a side path in this story. It is based on BDD-scenario's but eventually it has nothing to do with BDD at all. Let's not mis interpertate SpecFlow on that. SpecFlow only let your scenarios fit on a unit test. It's an adapter.

This blog originated from a discussion about how to test our software. In the next blog I'll talk about testing UI and web-api's and what you should test about them.