McDonald’s Theory

Couldn't have said it better myself. All teams needs someone to break open productive meetings. I apply the same tactic: https://medium.com/what-i-learned-building/9216e1c9da7d

Finger pointing

In the Agile dev world, there is a rule saying 'no finger pointing'. This means not rubbing people's nose in something when they made a mistake. This to assure people don't become afraid of touching some code or making mistakes. I think it's also a way of being professional. Now here's the thing. Most people want to know when they made a mistake. So you need to tell them. It's about how you tell them of course. Polite and calm is the manner it should be. This works for most people, but the rule has a couple of disadvantages: What do you do when someone really doesn't give a f*ck? You already told him 10 times to run the tests before check in and he still doesn't do it. What do you do then? I say finger point away! Finger point till he cries :)

Existing principles interestingly explained

Here's an interesting video from Gojko Adzic stating that software quality is everyone's problem. Nothing revolutionairy, but I especially like the way he talks about removing team bottlenecks and the importance of job titles.

http://gojko.net/2012/02/17/sleeping-with-the-enemy-video/

Work to the rule

I want to share a piece of text that fascinates me in the exellent book 'Pragmatic Thinking and Learning - Refactor Your Wetware'. It fascinates me because it is a general piece of text, which imo can be applied to a lot of big Agile teams on projects that take some years to finish.

[Start quote from the book]
In industries or situations where one is not allowed a fullblown strike, a work slowdown is often used as a means of demonstration. Often this is called work to rule or malicious obedience, and the idea is that the employees do exactly what their job description calls for —no more, no less— and follow the rule book to the letter. The result is massive delays and confusion—and an effective labor demonstration. No one with expertise in the real world follows the rules to the letter; doing so is demonstrably inefficient. According to Benner (in From Novice to Expert: Excellence and Power in Clinical Nursing Practice [Ben01]), “Practices can never be completely objectified or formalized because they must ever be worked out anew in particular relationships and in real time.”
[End quote from the book]

Often, when the velocity of big teams is not good, the teams itself propose a number of rules to improve their velocity. Sometimes these rules deal with check-in procedures, refactoring unfamiliar domains should be reviewed by persons familiar with that domain, adhering to certain conventions and so on... That's all needed and all fine. But if the project takes a few years to finish, it can happen that the number of rules can grow a lot, or that the people who invented certain rules, and more importantly, that knew WHY the rule was needed, are gone.

When your project has an entire wiki full of rules, and not all of these rules are clear for the whole team, there is a danger of overregulation. This can lead to 'malicious obedience'.

Testers being the fat kid up front

In the Certified ScrumMaster course, Jeff Sutherland said something that keeps running through my mind. The Agile principle is based on quick feedback cycles and quality of code (xP). A story is not finished until after a 'proxy customer' check. A 'mini acceptance' of the analist representing the customer, if you will. Later on, maybe after the sprint, the story is tested again in some form of integration environment.

To get that feedback in different phases early, he told us to treat the the proxy customers as fat boyscouts. If someone during a boyscout hiking trip can't keep up, it slows down the whole group. You should therefore walk beside them to motivate them. If they still can't follow, you take their backpack. If it's still going too fast, put them in front of the whole group. Make them determine the paste.

I think he's right. We should aid and guide our testers as much as we can. If during the daily scrum stand-up, you hear that someone is blocked from testing, this should deserve your immediate attention.

Let's conversate about the essence of Agile

It was bound to happen for me to have a post on Agile, and now here it is...

Many people have many different opinions on this hyped topic full of
buzz words and passionated feelings. I've spend some years on different kind of Agile projects. 'Different' in the way they adhered to the Agile principles. And this allows me to distill the essence. For me it's not about a complete set of 'rules', although they help if you still need to grow as a developer (see my first of two points).

In my first Agile project, there was a strict following of all the sub methodolies defining Agile (like burn down, TDD, stories, scrum, pairing, the manifesto, ...). The projects after that, were also Agile, but less strict, or less compliant to the rules if you will. They for instance did not adapt all of the principles such as burn down or pair programming.
Each project had valid reasons for their level of compliance. For instance, one of the goals of the strictest project was that half of the developers (junior Java developers) needed to be trained to later perform maintenance on the project, after the senior developers left the project. Pairing serves this need perfectly. The other projects had more senior members, which has an impact on my first essential point.

Colleagues who have never worked according to the methodology often ask me - while barely hiding their scepticism - what 'Agile' exactly is. According to me there are two essential things that all Agile projects have in common:

1. First of all, you need a team of *disciplined* and *courageous* developers. Seriously. Disciplined enough to test and doubt everything, even themselves. Courageous enough to refactor that complicated piece of code or to say 'no' to your boss (refuse to harm the code cfr Uncle Bob).

2. Second of all, the way the development team interacts with the team that determines the requirements. This can be the analists, proxy customers or customers.
I read an excellent Martin Fowler blog post which explains this way short, clear and to the point: Conversational stories.

In the post you can see that Agile, deals with requirements in conversation, sometimes even negociation. The early developer feedback can lead to changing, adding or dropping some requirements.

In the waterfall approach, the analists are super human creatures, who can never fail. They will never be wrong, nor forget the big picture and always
use the proper level of detail. Surely, they must be, since a developer never sees them but needs to implement what's described in their documents.

There are always questions about details that only pop up when you start the implementation. Even if the use case accurately described 90 percent of the cases, how do you handle the other 10%? If there are 3 steps described, what does the software need to do when step 2 fails? And so on.

As explained in the post, conversation is the answer.