Yeah, it might seem a little bit lame at first, but the whole idea is to talk about agile teams, so do not nitpick about the metaphors and examples using the movie. This post has spoilers, so if you have not watched Guardians of the Galaxy yet, go there and watch it, but come back to read the post =).
It’s been some time since I started writing down some ideas about agile teams, culture and how these things reflect in actions. After watching the Guardians of the Galaxy movie, my ideas and thoughts became this blog post. Each section is about skills and practices that agile teams should master. To better understand them, examples from the Guardians of the Galaxy will be used.
The sense of team
The main character of the movie, Quill – also known as Star-Lord -, acts as a scrum master. During the first minutes of the movie he managed to group different people with different purposes and abilities to work together in a very efficient way. He did it in the same way agile teams work: making everyone to have a common goal.
Quill wanted to sell the Orb for money; Rocket and Groot were hunting Quill for money; Gamora wanted to sell the Orb too, not for the money, but because she did not want it fall into the wrong hands; Drax wanted revenge, and hurt Ronan the way Ronan hurted him. Quill managed to set their goals to save the galaxy. Now, everyone works for the same purpose. All the personal problems were vanished, the goal of the team was now bigger than the personal goals.
Have you ever not called for help just because you wanted to show to someone (or even to yourself) that you could accomplish it by yourself? Well, Drax did it. And It was selfish. He called Ronan to Knowhere saying the Orb was there and so he could kill Ronan. He thought of it as an opportunity. But he lost the fight and the Orb as well.
In software development, trying to decide a software architecture, pushing code to master without code review or ignoring known bugs are some selfish acts that someone could perform.
Although it should be avoided, sometimes we still see things like these happening in agile teams. When it happens, we should reinforce that it’s a team. And a team works like a team, there is no space for solo stars. Drax realized he made a mistake doing that. He asked for apologies and the team understood and moved on.
Solving conflicts among members
Drax joined the team, firstly, because of Gamora. He wanted to kill her in order to hurt Ronan. But when he figured out it wouldn’t help, he kept in the team, for some reason. It could be a problem and may put the goal in risk if not managed well. But Star-Lord argued well and made people collaborate with each other.
Solving conflicts in the team comes from listening both sides. Drax explained why he wanted to kill her. She said she was against Ronan as well. Star-Lord helped both to get in a deal, since it probably was a communication issue. On a daily basis, we can face ourselves criticizing someone, not happy with something or two members that do not go along. Having an health environment where everyone is able to tell their issues is half the way. How to conduce the conflict resolution is the second one.
That’s a leader role, but it does not require only the scrum master to perform it. When things goes chaotic, the team must figure out a way to cool down and make things go well again. In an agile team, we can think in chaotic moments to be, for instance, when pressure from the external world come into to the team, for instance. Rushing the development, cutting edges, letting quality goes down, everything could be taken as the “chaotic” moment. Someone must notice it and figure out a way to solve it.
Behaving like a team member
Star-Lord never said “I am the leader”. This role came to him naturally when everyone trusted him enough. That’s the final scene where he was asked where to go to, and so Gamora says: “You lead, Star-Lord”. No roles are set, they must come naturally. When a member is comfortable performing some role, he must naturally say “let me handle this”.
As a leader, he is not supposed to solve all the problems. He needs the team to be part of the solution, so they would be more engaged and committed with the results. You can see it while they plan how to escape from the prison. It was not Star-Lord who came up with a plan. Rocket made it up and everyone was part of its execution, which, by the way, was one of the funniest parts.
Everyone had a task to perform and the plan’s success was depending on their execution. Rocket let everyone perform it without monitoring or over controlling. He just trusted people would do their best to succeed. And they did. Rocket did his part as well. Everyone was part of it.
Backing the team up
When Gamora was in the vacuum, after her ship explosion, Star-Lord put himself in risk in order to save her. Ok, it might have been for love. But, in real life, members of a good agile team will always do small sacrifices for other members. For love? Maybe not. I don’t think there is a word to describe the feeling of being united and friend with the whole team to the point of doing small sacrifices.
Have you ever exchanged your chair because someone else’s was not comfortable or kind of broken? Have you worked on someone’s user story in order to finish it because the owner had personal issues to deal during the sprint? If you had answered yes for any of these questions or you can think of a similar experiences, so you’ve done small sacrifices.
Do you remember the “We are Groot” scene? That was a sacrifice. A very nice scene indeed. Very touchy. Well, you might think you will not save someone’s life at this point. But you can totally save someone’s day. On daily basis, these small acts count a lot. They are an important detail that makes the team united and raises the trust sense.
Also, it is very interesting how those sacrifices are taken by examples and encourage other members to sacrifice themselves too. It is very nice when it happens because you feel safe. You feel safe to fail, to expose your ideas and to perform better.
The members should always be communicating with each other. It can be through Campfire, Skype, HipChat, IRC or even in person. But the communication must happen, its lack can cause huge problems like when Groot, Rocket and Drax were going to save Gamora and Quill from Yondu.
Rocket tells to Yondu’s ship crew that he would blow the ship away in case they do not set Gamora and Quill free. Actually, they already had an agreement, but it was not informed. The situation went weird. Sometimes, specially in consulting, communication fails and either we feel or the customer feels threatened like Yondu felt. If people take it personally, you will have a situation.
A lot of software projects fail due to the lack of communication. People do not clearly understand what’s going on, expectations are not met and fights among members can happen. It might be a change in the requirements that nobody knew except for the guy developing the feature or it could be a phrase without any context, it does not matter what it is, the lack of communication will lead to low trust sense, lower collaboration and also contributes to a bad work environment.
Having fun together
There is another moment that I need to talk about. While Gamora and Star-Lord were talking with the Collector, the rest of the guys were in the bar drinking and having fun. That’s important for agile teams. The more they spend time outside the work hours, the more they know each other and the sense of trust raises.
The sense of trust is the primary factor that unite people. They become happy to work with each other, they trust in the work and that they will cover them back. They will know each other as better as Rocket knows Groot! Yeah, they know each other pretty well. When Groot says “I am Groot”, Rocket knows exactly what he meant, just like when you see a disapproval look from your team member and knows he is shy enough to not say anything at first, so you gently say “I am not sure about this, does someone have any thoughts?” and then he answers.
The final scene is what best describes the journey of agile teams. They finally reached their purpose. And how it happened? Well, Star-Lord starts this very interesting dancing act for Ronan. In the mean time, Rocket was able to build the weapon again and they could strike Ronan with it. That’s teamwork. Unfortunately, it was not enough to defeat Ronan. Drax and Rocket shoot the hammer and the Infinity Stone broke apart. Star-Lord grabs the Stone and then everyone helps him. Everyone was needed, otherwise Star-Lord would blow up!
When everyone is holding each other and Star-Lord is capable of controlling it, everyone – the whole team – feels part of their victory. Groot in pieces was as important as the others.
The same logic is applied for project teams. When one fail, the team fails, the team learns, and the team improves itself. No guilty, no finger pointing. It is about not making the same mistakes again. So, who wins when the project succeeds? The team. The team that in that moment can feel like they have saved the Galaxy.
One of the most common questions discussed among the Agile Community is what should be done when a team doesn’t finish a user story (US) in a sprint? How can people track the progress made on an incomplete user story? In this blog post, I’ll share our approach to this question.
According to the community, when a developer finishes their work in the last few hours of an iteration, they must try to help their teammates finish their work. Otherwise, it’s recommended they help prepare the next cycle of work, analyzing the next user stories, refactoring a piece of code that could be better implemented, or writing tests. It is not advisable for a developer to get a new user story started if they won’t be able to finish this in the same cycle. However, this first approach is not always possible because user stories can be underestimated or something can happen that would delay the delivery of the user story.
A second alternative is to split the user story into two smaller ones and develop the one that can be finished on time. The first user story’s points are credited in the current cycle, the second one’s are credited in the next cycle. This approach improves the visibility of what was done in the current cycle. However, it hurts the agile philosophy, in some way it would be a delivery without business value for the customer.
The third way is for the unfinished user story to go to the next cycle with the original estimate. When it gets completed, the user story’s full effort estimate gets credited to the velocity of the new iteration. This could skew the average velocity metric, so be careful, because this is important to the Product Owner (PO) for forecasting and planning. Also beware to not have a bunch of backlog items almost done: one user story delivered has more value than a lot of user stories 90% complete.
How do we do it?
Usually, we use the first and third approaches in the following way:
- We try to concentrate efforts on work that is closest to delivery. As soon as a developer finishes the first US, they will verify if someone needs help with finishing a task or if some user story in the current cycle has defects that need to be fixed. Keeping the work-in-progress as low as possible helps to focus on what matters most. This process is repeated until the end.
- If this list is empty and the cycle is almost over, the developer looks for the smallest or most valuable user story (depending of project’s context) to be done.
- If the user story has not been finished by the end of the cycle, this US shifts to the next cycle with the original estimate. However, when we plan the next cycle, we’ll consider just the missing points to finish the US.
- When this US gets finished, we credit the whole user story’s estimate in our velocity.
- If the developer after resuming the work on the US in the next iteration realizes that the user story was overestimated or underestimated, usually, we don’t change the estimate on the story itself, but we update our ruler score with the real estimate, as lesson learned.
Note that we do not use these exact steps every single time, everything depends and adapts according to the context of the project or the moment. The most important thing is you prioritizing to deliver maximum business value to the customer.
And you? What do you do when you have an unfinished user story in your cycle? Share with us yours experiences!
Last month our team went to Agile Trends, an event in São Paulo where discussions revolved mainly around Agility in software projects.
Starting the event activities, Niels Pflaeging presented a keynote where he defends Agile alone is not sufficient to taking organizations to the Knowledge Era, and that deeper transformations are necessary for doing that. He started it with an overview of the History of Management, why bigger companies are structured the way we know them and what he believes needs to change so they can adapt to the new reality and remain competitive.
After the keynote, the so-called “Trend talks” started. Each Trend Talk session was composed of two 18min talks revolving the same theme, followed by a 20min discussion round. In the Trend talks, most of what was presented and discussed was related to the challenges companies face when adopting agile.
During such presentations, most of the success cases presented how companies have adopted the Agile principles but adapted the practices to their own realities, be it a startup or a bigger corporation. Which is similar to what we’ve been doing in our own projects: whenever we start a new engagement we use our custom methodology as a Starting Point and, as we get to know more about our clients, we adapt it to better suit their realities.
Other presentations also showcased some of the Change Management challenges that companies have to face in order to make this work. These topics are similar to our own challenges when engaging client projects, and it was interesting hearing the struggles from other professionals so we can make sure to always keep our toolbox up to date.
The event also contemplated some workshops, and we joined one that had Kanban as its theme. In this workshop, we honed our skills while running an imaginary pizza place (too bad the pizzas weren’t real) and as we progressed in the game, we could also buy adjustments to our workflow in an “upgrade store” using the cash we made. The point was to get us thinking about how our decisions affected the business’ performance and profitability. Besides that, we also joined a workshop about Learning 3.0, where the participants were divided in small groups and each group had a real problem to work on. We had to understand, share experiences related to the problem and discuss ideas about how to solve it. In this workshop we had the opportunity to work with people from other companies with different backgrounds, which contributed to bringing different perspectives to the discussions.
Finally, we also attended some interesting Keynotes addressing themes that were not directly related to Agile, such as Internet Privacy and the Internet of Things. Even though not directly related to project management methodologies, they were nice in the sense they help us keep our minds open to other trends related to the tech landscape.
Being part of the event was a great opportunity to see how events related to Agile have gained increased traction during the past couple of years. It was also nice meeting old friends there, as well as meet new people.
Have you also been to Agile Trends? Did any of the talks catch your attention in special? Please let us know it in the comments.
Dave Thomas wrote a blog post called “Agile is dead (Long live agility)“. In the blog post, he claims the use of “do Agile right” as a way to profit, whereas it should make people – developers specially – to deliver valuable software more effectively.
It had a huge impact in the community in a way that many other people came up to point out their opinions. Also, some good texts about the subject came up as Andrew Binstock’s “The Corruption of Agile” and Allen Hollub’s “The Agile Holocracy“. In reply to the last two articles, Uncle Bob wrote “The True Corruption of Agile“. These are the kind of movement that make the industry to evolve: to criticize the “state of the art” practices and ideas. And to better understand what’s going on, it is better to step back and look for what “Agile” is supposed to mean. Watching a talk by Martin Fowler and Neil Ford called “Explaining Agile” can help us to better understand it. I’ll try to tr;dl the talk by Martin and Neil, so we can follow along with the discussion.
Before the whole Agile idea had emerged, industry majority used to follow waterfall by using frameworks and methodologies that support its idea, such as ISO 12207 and CMMI. All of them established a strict set of practices that should be followed in order to be compliant. The practices became a process and each person would take an input and then transform it into an output which would be someone’s else input.
And so did the tools, they were designed to support the same process for every company. Everything should be automated in such way that development pipeline (requirements, design, development, test, maintenance) would work perfectly. The only team with autonomy to change the process was the process quality team.
A successful project in waterfall would be one where everything run as planned. All people did was following the plan and making an input into an output hoping to get the final product at the end of the project.
It was noticed that the plan needed to be changed often during the course of the development and the later changes were needed the more expensive they would be. Although there are certainly exceptions, it’s usually very hard to plan a project and not needing to change it.
It would be better if the plan period was shorter and, by making it shorter, one could adjust the plan between periods. In order to make a good plan, review and retrospective meetings came up, so it would be easier to spot problems and to solve them. And to do so, it is necessary to give the autonomy to the team to change its own process independently of its project or organization unit.
That’s why “Agile” came for. We would have iterations and after each one we would have a chance to change the course of the project, to change the way software is being developed and to change the whole plan, so that we would have an empirical process/practices and not a strict defined process.
Where the corruption is
All the discussions raised by the cited articles are being fired by the same reason: “agile” is being misused. People are creating strict practices and process and taking it as “the right way” of developing software, whereas they should consider the empirical knowledge that each project gives as feedback.
It is needed to adjust the process and practices in a way it makes sense and turn the software development easier to maintain and faster to deliver value. In order to accomplish that, you have to change things. Embrace the change was not supposed to embrace only the requirements change, but any change.
People has turned Agile into a set of strict practices, when it is a philosophy/culture of how to react to environment stimuli. The practices are the reflex of the reaction and, biologically speaking – don’t forget software is built by living beings -, people can react differently for the same stimulus. And in this thought is where people is corrupting the agile.
I’ll give a real example to try to make myself clearer. When you work on different projects with different clients, the cultural differences among the stakeholders are more evident. So, it is our job to make the project to succeed and the way of doing that is adjusting the process over the time and don’t be afraid of doing new things.
For instance, I worked in a project once that was following Scrum guidelines. At some point, the plannings were not taking even a full hour. The stories were well defined: PO and the Scrum Master already had prioritized them before the planning had began. We used to estimate them before the meeting and the only discussions raised during the planning were about making sure developers had understood PO’s needs.
Because of that, in some retrospective meeting we decided to merge Kanban with Scrum and have something hybrid. We would still estimate the stories so we could keep the predictability, but we did not had plannings anymore. Bugs and User Stories were prioritized in the proper column and the developer would assign himself to the most prioritized one. Plan changes were notified by Campfire. When a doubt about the US was raised, Scrum Master and the assigned developer would talk directly with the PO using Google Hangouts and/or Campfire. The changes were communicated to the others developers through Pull Requests.
We got autonomy to change things and it was very satisfying to see the results. Always remember those left-sided values from the agile manifesto and let it flow. Remember that the process cannot decide how you work, but the other way around. We had delivered with agility, even though we took the risk of going out of the box and not being tied to the conventional practices.
Finally, I want to thank everyone who is helping to push the community forward by raising discussions like that. As always, when discussing, be aware that we criticize the practices themselves, not people or companies. There is no such thing as “right” or “wrong” for subjects like this, there is what works and what works better for you. So, what other practices can we discuss about? Have you done any change which had a huge impact? Share with us on the comments below.
The formal definition of estimate is “an approximate judgment or calculation of the value, amount, time or size of something”. In a software development project, estimates are important to help us predict how much time will be necessary in order to finish a set of activities, or to select and prioritize scope for a release or iteration.
It’s rather common on Agile projects that the estimates are done in a planning poker session. Each team member has a deck of cards with the Fibonacci sequence (0, 1, 2, 3, 5, 8, 13), and for each user story (US), the team member privately selects one card to represent his or her estimate. All cards are then revealed at the same time. The estimates can represent story points, ideal days, or other units of cost that make sense to the project. Usually we use story points because we can consider three different aspects when estimating: complexity, effort, and risks. The story point unit allows us to more effectively capture sources of variation compared to an hour-based estimate.
Since story points are a relative measurement unit, the first step your team should take is to define one story as the baseline, so that they can estimate the other stories comparing to that reference. According to the literature, the team should find the simplest story in the backlog, and assign 1 story point to it, after that, they use that story as baseline to estimate the other stories.
However, here at Plataformatec we go a step further on defining that baseline story. We select at least one user story for each story point that we use, composing a “ruler score”.
In each sprint, we update the stories in the ruler with US’s of the previous sprint, so that when our team meets for the planning poker session, they have at least one baseline story on each story point to compare to.
Using that practice has brought us a lot of benefits, such as:
- The estimation process is more effective because the reference to each story point is clear, reducing the length of the discussion among the team;
- Even if the team has a new member, the story point variation is reduced because this practice enforces a reference to each story point in the “ruler score”;
- The team members have the same reference for each story point, preventing someone from having an implicit story point reference that is not shared among the others;
- On each sprint, the estimates becomes more and more stable, since using the ruler score guarantees that the story point references are always updated.
That’s it! We’d like to know what are your practices in estimating using story points. And if you try out the ruler score, let us know your results!
O Agile Tour, considerado o maior evento sobre agilidade do mundo, tem como objetivo disseminar a visão, a cultura e as práticas adotadas pela comunidade ágil no desenvolvimento de software através da troca de experiências entre os participante. É uma excelente oportunidade de aprender mais sobre as nuanças do ágil no dia-a-dia dos profissionais.
Ano passado, em sua terceira edição, o Agile Tour reuniu cerca de 7.500 participantes em 44 cidades espalhadas por 15 países. No Brasil, o evento foi organizado em 5 cidades e atraiu mais de 600 pessoas no total. Esse ano, só no Brasil serão 12 cidades participantes e, com certeza, teremos um recorde no número de inscritos.
Ao longo do dia teremos nove palestras sobre diferentes temas – dentre os quais: “PO, tão simples como dizem?”, onde estarei representando a PlataformaTec em um bate-papo com o público sobre os skills do Product Owner que nem sempre estão presentes nos projetos ágeis.
Caso você se interesse pelo assunto, não perca o Agile Tour 2011. Além de ser uma maneira diferente de se aprender mais sobre ágil, é um ótimo canal para conhecer pessoas e ampliar sua rede de contatos.
Ah, o evento é gratuito! Por isso, não perca tempo e se inscreva já!!