The minimum to know to work in an Agile team

Why this article

Now, working in an “Agile team” is a standard. So, if you are a developer, a manager, a UX, a QA, a SRE, (…), and of course a PM or a PO, you certainly work in an Agile team. And “Agile” means things about your organisation, how you are supposed to work with your colleagues, how you can be efficient as a team. That’s why you need to have knowledge about it, in order to be able to work with your teammates.

However, understanding what “Agile” means is not always a reality for all of us. And that’s normal. The organisation of teams is not your main activity, your passion. So, when you read articles, you don’t read about that. Except today :-) because you just want the minimum to know, and it’s the purpose of this article.

I hope also this article will help you to see if you understand well the Agile framework you are applying, like Scrum.

Agile = empirical approach

As a lot of Agile coach/Scrum Master, I’m a big fan of what the Spotify coaches shared about their organisation some years ago. One of their sharing is “Agile = iterative + incremental”.

http://www.barryovereem.com/wp-content/uploads/Agile-is-Iterative-and-Incremental.jpg

Ok, so, that’s all? We have the answer about the minimum to know about Agile? Yes, almost. But, we have to understand it now.

Because this article prefers to give the minimum, more than the truth, you can remind you just one idea about this complicated addition above. Behind Agile, we stop to believe only in our rationality to build softwares. Agile means we prefer the “empirical approach”.

Agile = iterative + incremental = empirical approach

When we accept the fact we work in a complex world, we accept to doubt and have unknowns. In other words, even you could take months to think about everything before starting, you accept the idea your result will not be the good one. And it’s a too big risk for your team/your company.

So, in opposition of our “rational” approach (we think about everything before starting), we need another way to build software, to achieve our goals. It’s the empirical approach. We think, we make hypothesis, we do the dev of the hypothesis, we test the hypothesis and we adapte ourselves to the results. And we do it often. It’s not a new thing. Other sciences have been doing it for centuries.

That’s why, in your team you demonstrate a software the user can use (= an increment) and you do it regularly (the iterative way).

Agile team = dream team

The second and last idea of the minimal to know about Agile is you work in a very great team.

How you can see it? An Agile team is supposed to be a self-organized team which does whatever she can to improve herself continuously. It looks like the definition of a great team to me.

But, self-organized for what? To achieve a common goal: deliver the next increment with the good level of quality, at the end of the current iteration (because Agile = iterative + incremental, you remember?). And because, you are in a very great team, the team will think and make actions to do it better in the next increment.

If it’s not always easy to follow the empirical approach, this idea that Agile means also to work in a very great team, it’s clearly one of the main difficulties your team can have. But, we’ll certainly discuss about it in another article.

Do you already apply these ideas in Scrum?

If you are reading this article, it’s because you want to have the minimum of information in quantity but the most important in quality we could say. But because a lot of teams use Scrum, you certainly want a little help to see when, in Scrum, you apply this idea of empirical approach and when you are a great team?

Empirical approach: for that, you’ll use at least the sprint review. During this ceremony, you’ll share with a demonstration the result of the new increment at the end of the current iteration (Sprint in Scrum). So you’ll check the results of your hypothesis you made for this increment, and you’ll adapt your plan (i.e the next increments you think you’ll do, your release plan, but we’ll certainly discuss about it in another article).

You will self-organize yourself with your team to build the next increment during the sprint planning, and everyday during the daily scrum.

And you’ll continuous improve the team during the retrospectives.

Ok, and the Agile manifesto?

Yes, this article is too simple. Agile comes from the Agile manifesto, and the Agile manifesto gives more than that. But, we could ask us few questions.

Regarding the 4 values of the Agile manifesto, in the importance of a “working software over comprehensive documentation” or “responding to change over following a plan”, we could see some connections with the empirical approach and the importance of the incremental way to build a product. Isn’t it? And, in the importance of the “individuals and interactions over processes and tools” or “Customer collaboration over contract negotiation”, we could understand the importance of the team, a great team. Right?

You want a short article to read. I propose you to not do it with all the 12 principles ;-) But, going more in the details of the 12 principles is very interesting to do, including with this article in mind.

Conclusion

This article wants just to give the minimum in order to help you to have the real basics of Agile. Try to think about it, for example, during the sprint review meeting, remind you, you do it for the empirical approach, and for no other reason.

And hope that some readers will see Agile is nothing related to do something 2 times faster.