I’ve seen many teams struggle with their Scrum or Kanban boards.
Many of the teams had an “in review” column where the stories would pile up during the sprint.
A lot of stories were worked on in parallel but the burndown looked something like this (if they were lucky):
Why can’t we get stories done continuously?
- Too many stories started in parallel due to specialisation or lack of focus
- no visibility on the progress (missing burndown)
- no real team commitment but loosely coupled bunch of individuals
- doing mini waterfalls due to dependencies on work from outside (testing, deployment)
- no clear definition what done means
- Agree to focus on getting stories done before starting new stories, helping each other on the tasks that need to be done, always checking on what team mates are working on before picking tasks of a new story
- Set up a Definition of Done for the team that can be used as a working agreement inside the team and also in negotiation with the PO to let him or her know what to expect as outcome of a sprint
Step 1: Gather input
Step 2: Now, Next Sprint, in the Future
Step 3: Work in progress, follow-up
recently I did a retrospective with a team and one of the points that we found out to improve is teamwork.
|image source: http://www.freshtracks.co.uk/images/blog/outnumbered.jpg|
This reminded me of a book that I read about teams: “The Five dysfunctions of a Team”.
And since it is an awesome book that gave me a lot of insights about team dynamics I wanted to share some of it with you.
In many companies a Team is the smallest working unit and therefore the foundation for success. If you have teams that work together really well, take over responsibility for what they do and show commitment you’ll normally also have the outcomes that you want see.
So what is a good Team and how does solving conflicts help in being successful as a team?
- Trust – this is the basis for a good team. Members need to be able to trust and rely on each other. “All for one and one for all”. This includes being open to suggestions for improvement from fellow team mates and also the ability to give this feedback in case others lack skills in certain areas.
- Culture of Conflict – Teams that are not open and honest with each other will hide their conflicts. The subliminal conflict will always be there in discussions and members will talk behind the backs of the others. Teams that trust each other will openly talk about conflicts and solve them.
- Commitment – Teams will only commit as a unit to their goals if they have Trust and a Culture of Conflict. That is needed to get the buy in of all team members. There will always be decisions to take that not all team members will have the same opinion to begin with. Then they have to openly discuss and solve disagreements to be able to commit as a whole.
- Accountability – Teams that commit to targets know what needs to be done to achieve these targets. All team members work together to achieve what all the single members of the team could not achieve alone. This also includes reminding team members of what they committed to do. Everyone has a bad day sometimes, and team members will be there to motivate each other.
- Delivering results – Great results are the result of great teamwork, and great teamwork is only possible with all the value that you read before. “Stars” inside a team who value their own ego or career development higher are the biggest threat to delivering team results. They will undermine all the values because they have their own secret agenda.
How to improve your team?
- First step of trust is to get to know each other better. This works best for newly assembled teams and can be achieved with a speed-dating exercise where all the team members talk to each other for a few minutes to find out about family status, hobbies, interests and so on. This will result in a deeper understanding of team members.
- Finding out the team effectiveness – Team members identify the most important contributions of their peers to the team as well as the most important area to improve. This will give the team a lot insights about their strengths and where to improve most
- 360-Degree Feedback – Team members make specific judgements and give constructive criticism. This requires a basis of trust to use and also this feedback needs to be detached of performance evaluations or compensations
- Team Leaders – in order for team members to show vulnerability and take risks the leader has to be a role model and do the same. If the leader has an image of invulnerability and no flaws it will make it difficult for team members to be open about their weaknesses.
Even more important for the team leader is to create an environment in which it is ok to show weaknesses and make errors. If you get punished for making an error what you will do is to simply hide all the problems.
- Mining for conflicts – someone in the team can take over the role of a “miner” and uncover buried disagreements in the team and work on them until they are solved. Important here is the commitment to stay on the conflict until it is solved
- Encouraging each other – while working on conflicts team members should remind each other that it is important to continue working on disagreements even if the tension is so high that some team members want to withdraw themselves of the discussion because they feel too uncomfortable. This is when their peers can help them by coaching them.
- Leaders role – a leader should support conflict instead of suppressing it, they need to demonstrate restraint to allow a natural resolution of the disagreements. This is often counterintuitive for a leader since they often need to protect the team from harm. The inability of a leader to allow healthy conflicts inside the team will in the long run harm the commitment, accountability and ability to deliver results of a team.
- Cascading Messaging – after a meeting review the key decisions that have been made and agree what needs to be communicated about those decisions. By doing that a team reassures that everyone understood the decisions the same way and that it is clear who to inform and what information should be communicated
- Deadlines – setting deadlines to take decisions and following them even if they are only milestones to the real important decisions, forcing misalignment between teams to be addressed
- Worst-Case Scenario Analysis – a team that struggles to take a decision often can be helped by painting the picture of the worst outcome that could happen, often resulting in reduced fear and thus helping the team to understand that making a wrong decision is not tragic at all
- Leader – a leader must be willing and comfortable to make wrong decisions and he or she must push the group to adhere to schedules (deadlines) that the team has set
- Publication of goals and Standards – for an agile team this would mean the creation of a Definition of Done that is agreed upon by all the team.
It can also mean to write down “Team agreements” about the ways of working and interacting with each other. In an agile Team a clear goal would be a user story that has a clear description together with acceptance criteria, so that no one could talk him or herself out of not reaching the committed target
- Giving feedback about performance – in an agile team if you have a backlog you normally also have a burndown. A team can use the burndown to constantly reflect on their progress towards their committed goals thus reminding each other of what everyone needs to do to achieve the agreed team goals
- Team rewards – a team is more likely to succeed if the team as a whole is rewarded in case of success. Team members won’t stand by quietly if one of the peers is not pulling his or her weight
- Role of the leader – a leader should create a culture of accountability in the team meaning he or she is not the only source of discipline. In the case the team fails to hold each other accountable it has to be clear that the team lead will step in when it’s necessary
- Make results clear and only reward actions and behavior that benefit these results
- Public Declaration of Results – once a team has committed to achieve a specific goal it should also be comfortable with declaring these goals publicly. The whole company should have a culture to not throw stones at those that don’t achieve results but collaboratively support teams through continuous improvement cycles
- Team leaders are the most important factors in achieving results. They need to be selfless and objective and reward those that contribute to the achievement of group goals. If team members sense that a team leader doesn’t value results but for example his own career most then no one will be motivated to deliver
this is the second article about Value flow – last time I gave a short introduction in Value Stream Mapping.
With Value stream mapping you can find obstructions to your value flow and then work on them one by one until the value flow improves.
But one question that you might have had when reading the last blog is still open.
What is value in software development?
Wastes in Software development
- Overproduction – parts of your product that haven’t been ordered by your customer. In software development often generic classes or “building for the future to be flexible”. Most often it means to make things more complicated than they really need to be. “Gold Plating” would also be considered overproduction
- Waiting – The tester waiting for the developer to end the implementation part so that he or she can finally start the (manual) testing. The developer that waits for the build pipeline to finally give feedback if the automated tests were broken or not. The team that waits for the PO to decide that important decision so they can start using the new tool.
- Unnecessary transport or conveyance – Having to move the needed material long distances. In software development this is needed information. And the fastest way of getting to this information is if the team is collocated and sits together with their respective PO. Any form of “EMail, telephone, walking over to the next building” can be considered as unnecessary transport.
- Overprocessing or incorrect processing – Doing extra work or processes due to usage of bad tools or poor product design (architecture) often causing unnecessary motion and producing defects. Waste is when your product is higher quality than it actually needs to be.
- Excess inventory – too high WIP (work in progress) which causes delays and in the end leads to a hiding of the problems because problems often only surface after they reach the end customer. In software development the most typical form of excess inventory is working on too many projects in parallel.
- Unnecessary movement – all extra movements that a worker has to to at the production line such as walking and longing for tools. In software development I’d consider every extra step during the normal work e.g. filling out form xy before checking in to source control or clicking 4 times with your mouse in the UI instead of just using keyboard shortcut “cmd + alt + p” as unecessary movement.
- Defects – Finding bugs, rework and fixing of the bugs, extra releases or patches that need to be shipped together with all accompanied extra work
- Unused employee creativity – By far the worst waste in my eyes. Most often ingenious middle managers which are 10 years out of development decide on environment and tools for their development teams instead of delegating these important decisions to them.
Not listening to the improvement ideas of the employees and not providing an environment of learning and continuous improvement. In many companies employees even have to beg to get books paid for self studies.
Now what does this all have to do with Value Stream Mapping?
You know how to create a Value Stream Map. You learned it in how to create a Value Stream Map.
But what do you do with it?
How can you read a Value Stream Map?
- Why do we only release every 3 months?
Because it takes us 2 weeks to do a full regression test
- Why does it take us 2 full weeks to do a full regression?
Most of the tests that are done in a regression are done manually and we only have limited resources to do the tests
- Why do we have so many manual tests?
Our skills in writing automated tests are lacking and we couldn’t create automated tests for our legacy code base
- Why couldn’t we create enough automated tests for our legacy code base?
We’re asking for the time to do it for several months now but we’re always under pressure to deliver the next release
- Why are you under constant pressure to deliver the next release?
Between releases we would need some time to “wrap up” and refactor some of the things we had to do for the previous release, but since we’re not given that time we’re working extra hours to get things done in time