Agile teams are self-managed team. They decide together as a team how they want to do things. Conflict between team members is also one of the things that they need to be handled by themselves. The nature of agile development plays a part in how conflicts are managed

Yesterday, I read an article titled “We’re better together” on Entrepreneur magazine. The article talked about several aspects of collaboration. A section stated that there were two reason conflict between you and your co-worker would not (always) lead you to failure. One of the reasons was “Your fate is connected”. The term made me think about how agile development lifecycle affect conflict/disagreement in agile team

Co-failing

I got the word from the article. Team promises product owner in the sprint planning what he will get at the end of the sprint. The promise is team commitment. I can’t say at the end of the sprint that the un-finished user story is not my fault since I am not the main person in implementing it. Product owner doesn’t care much about who is doing what during a sprint. He is more interested in whether he gets what he has expected or not. If a story is failed to be delivered, the failure is of the whole team

This is quite different from the waterfall world which boundary of task and responsibility are more specific. There are areas of responsibility assigned to job title. If I am a developer, I will not be involved much with the problem of slow running automated system test unless I have been asked from QA leader to help investigate it. My tester friend may not be interested much if I urgently need HTML5 training for developing the new module. He just waits to test the module. If the quality is so low (since I am new to the technology) then he just report more bugs. The higher number of bugs he has detected may even play a good part in his performance review

When a conflict happens, the fact that agile teams are co-failing makes team members aware that they have to eventually reach an agreement in some form. If the conflict causes them to not able to deliver then the whole team is at fault

This doesn’t mean that we need to compromise everything to get all stories done. It just means that a decision must be made for the team to make progress. Could we choose an approach and make it loose enough so we could replace some part of it with moderate effort? Cold we test it manually for now until we know how to automate that part? Agile teams often make tradeoff like this to reach a point that they can move on and get stories done

Incrementally delivering

It is very often that team members learn the technologies or approaches to build the system as they go. The team doesn’t have to get everything right at the first time. Things will changes from sprint to sprint. The best solution last sprint may has short coming when we incrementally and new functionalities to it. The unattractive approach may become viable when we get more knowledge of the tool we are using. Team members know they don’t need to fight to death for each decision. We may just pick a candidate approach at the moment and see if it will still serves us well for the next couple sprints

Again, this is balance act. Some decision is very costly if we get it wrong. If team feels the need to get more information from outside then Scrum Master may able to arrange it. But spending a lot of effort trying to be accurate about thing that team has limited knowledge on is definitely not productive

Fast feedback loop

Agile teams deliver workable functionalities every sprint and a sprint span just a couple weeks. This will make little room for things that doesn’t produce the workable output. Anything that makes team able to get the acceptable product at the end of the sprint is, in some degree, proved to be the right thing to keep on doing. And anything that doesn’t really help will reveal its problem quite fast. We will

learn pretty early that automated unit testing is really important when changes break old functionalities very often. We will learn that mixing UI and business logic is bad when there is a requirement to call the logic without UI

We learn many lessons in a short time because anything added to the system must be workable. All modules are incrementally evolve and incrementally integrated to the system

This fast feedback loop reduces the change of getting something wrong and realize it later when it is too late to fix. Many disagreements can be settled by just try one solution, if it doesn’t work then we will know pretty soon enough

Some arguments are better to involve product owner

Some problems don’t have right or wrong answer. Team members are often engage in disagreement without realizing that they are actually trying to guess what users want. Should we let users click the action button and show error if pre-conditions are not met or we should disable the button at the first place? There are many kinds of question that are easier just to ask product owner how he likes the system to behave

This may seem subtle but it really helps. It reduce the chance that we will have long and painful meeting trying to list pros and cons of various solutions to tackle an open end issue without anybody actually know what exactly how the feature is going to be used. It is the real great benefit for agile team to frequently communicate with product owner