agile soul

Agile, agile, agile and more agile! Are those programmers beach body ready yet?

New fancy mac-pros, sushi for lunch everyday, the cool managers wearing shorts and tie on summer, all the walls in the co-work space decorated with gratifies, etc...

That definitely sounds much more fun than the office of many of us working in the corporate world. Who wouldn't like to work in such environment ... ;p
But is there anything else apart of those things that really makes your team an awesome agile team?

We know well that agile its about the feedback loops and there are a huge amount of books written on the topic, practices, principles, etc... So in order to put in practice an agile development style, what kind of characteristics should the team have? In my opinion there is an expense list of characteristics that the best agile teams have. Let's  a look at some of them:

Communicative
There is nothing worse than being in a non communicative team. It is essential for the agile team to communicate both internal and external whenever is necessary regardless if the current task in hands have to wait for a clarification. The team leader or the business analyst are not postman that carry messages outside of the team. Also agile teams and agile developers don't hesitate or doubt when they have to say something to somebody and they are not afraid of making a critic or taking a critic.

Transparency
For the agile team every aspect of their daily work its 100% accessible to everybody. There is no place for secrets. Everybody knows everything about everybody. Business roadmap, planed stories, passwords, colleagues salary... Absolute transparency is the best to build trust and cooperation.

Cooperative
There is no mine or yours for the agile developers. We are all in the same ship and we work based on 100% consensus agreement basis. We not just help each other and do pair-programming, we also swarm with other members of our team or even other teams, no matter how big the current priority is. Team building is more important than the business itself, we do not hesitate if we have to stop what we are doing and swarm with testers, analyst, architects, junior team members or anybody that needs a hand.

Fearless
Agile teams are well known for their incredible capacity to spike, prototype and challenge everyone and everything. There is no process, language, task or challenge that can stop the agile teams.

Experts
Due to its role diversity and multidisciplinary nature, agile teams have huge experience in what they do. The redirection that characterises agile teams gives space for every member to gain experience in any field that is needed or they have interest in. The agile team members enjoy and are always eager to learn new things no matter if it is outside of their comfort zones.

Solid relationships
When it comes to relationships between team members, there is no just silly small talks next to the coffee machine. Team building its something very important in the agile culture and doing all sort of team activities(e.g night outs, sports, quests, hobbies...) out of the office it is important for the agile team. To be able to enjoy being with each other in the office, we have to be able to enjoy being able to be with each other also outside of the office.

Effective self management process
Even if the agile team culture in occasions gives the impression of being laid back and informal, the process that governs the daily work its very well understood and defined by everybody. The difference between agile management and the old school command and control management is that in the agile everybody natural finds its place and knows what to do without the necessity of being told by a manager.

Context aware
Sceptics sometimes believe that agile teams are not aware enough about what are the priorities for the business. That they only care about their cool development tools, clean-coding and having fun while developing whatever they want. But it is not like this at all, sometimes agile teams are more aware about the business than the business itself. The agile company is a better prepared company to compete in the market than the non agile one. This is due to the multi-directional capacity that exists when having self-directed teams.


Agile practices and culture keep evolving. From the first ones who wrote the agile manifesto, to the most radical practitioners , everybody agrees that agile teams, are changing the industry for good.

Retrospectives – “Lets talk about it”(Part 2)

In the previous post, I briefly explained what retrospectives are, why they are important and also I explained what is often that happens before them and how the facilitator prepares for it.

The following posts will be more focussed on retrospective formats/styles that could help the self organized team in different scenarios.


The first format/style I would like to explain is what I call "The Diplomatic Open Retro".
This retrospective style is best suited for a team that its not very familiar with the concept of retrospectives and also has a necessity of improving mostly its internal team self organizational process(e.g internal communication, workload management, development practices, internal optimizations, etc...).

How it works
At the beggining every attendant receives some post-it notes and is asked to write down all the topics that would like to discuss. Ten minutes should be enough, but depending on many factors sometimes gathering topics is more difficult. In order to help people getting inspired, the facilitator can play some relaxing music, also could write some of the hot-topics from the previous analysis in a board or even encourage the people to talk to each other(as long as it is helping discover topics).

This period is a critical part of the retrospective and it should take as long as needed, nobody should feel rush and only when all are happy with the topics collected the retrospective will carry on. Also it is important to mention that in the post-it, the team members can write in whatever way they want, there is no predefined format, even a simple sentence could do. If a team member doesn't know what to write, it is perfectly fine(he/she doesn't have to).

The next step will be to go one round around the table in which each of the members will briefly with a couple of sentences, explain each of the cards they wrote. There will be no replica, this is just a pure diplomatic exercise in which the members will try to convince the others of voting on their topics to be discussed. The person talking will stand up and as he/she briefly explains the topic, will also start sticking them into the voting board. During this period it often happens that people are mentioning the same topic so, this will be also a great exercise to group the topics that are repeated together so the voting can after be more accurate.

Once the topics are on the board, it is the time for for voting. Each of the members will be asked to place 3 marks in those topics that considers more important to be discussed.

It is important to understand that the time for the retrospective is limited and not all the topics will be discussed so the team needs to have a mechanism of selecting those topics that are considered more important. No voted topics will be discarded(They will appear in future retrospectives if they are important).

The voted topics will be discussed in order of(most voted ones first). The facilitator will make sure that takes notes of possible actions and key points as the conversations goes. Each topic will be time boxed within 10 to 15 minutes, after that time the facilitator will ask every body to start proposing and deciding on actions and owners for those actions. Actions will need to be decided before moving on to the next topic. It is very common in retrospectives that there is a lot of debate but little actions, this retrospective style attempts to gather actions while topics are closed. For the team to decide that an action is not needed its ok but this is rare to occur and if it occurs it will have to be decided by all that no action is to be taken. See an example of how gathered actions look like:

ACTIONS

Low Team Capacity(4 votes)

• Team unsure if should talk to HR, Management or other Dev team.(Owner: No action to be taken until we find out) 

Coolaboration between teams(3 votes)

• Devs to assist testers before moving into next dev task(Owner: All devs)
• Setup the machine of the new joiner(Owner: Team Leader)
•  Review handover checklist before going on holidays(Owner: All devs)

Failing builds(3 votes)

• Determine why the build is red for more than a month(Owner: Senior dev)

Cakes all over the office(2 votes)

• -Stop eating unhealthy cakes and organize a team dinner to celebrate xmas(Owner: Team Leader)

Tech debt catch up(2 votes)

• -Not enough time to discuss in this retro, add as a hot-topic for next retro(Owner: Facilitator)

Sometimes the team is unable to decide an action, because their dependency/blocker is outside of their team. In this case, they will need to identify who are those individuals that need to be influenced. But that is a topic that I will cover in another post.