Agile – but how?
I read an e-book from B?rsen the other day (in Danish https://campaign.borsen.dk/web/faces/public/exo/ledelse2020_ebog), they where quoting a poll from Gallup about employee commitment :
The article was about modern management and briefly discussed using Agile methods to become more competitive.
Used the right way, Agile will increase employee commitment.
Agile is about decentralize as much as possible and use the employee’s knowledge to plan the work and make the right decisions, management shall set the directions, create a great working environment (based on trust) and help to remove impediments.
There are many ways to work with Agile, Scrum is one way of the most popular methods and I will shortly try to outline things that you should be aware of and what challenges you can expect to face.
Scrum is based on teams working in iterations, I am not going to describe Scrum here, but I will touch a few things in this article.
Teams
There is a lot of literature about teams and team building, one of the most famous is Tuckman’s stages of group development (https://en.wikipedia.org/wiki/Tuckman%27s_stages_of_group_development), also really good is by Patrick Lencioni’s “Five dysfunctions of a Team”, common for most of the literature is that teams goes through different stages in order to build the most important thing – TRUST – without trust in the team, you will not be able to get high performing teams, and every time you remove or add a person to the team you have to start over building trust in the team.
That is why you need stable teams; team members must be fully allocated to the team and the teams should be stable for as long as possible. If there is urgent work that some people in the team are specialist in, you should move the work to the teams backlog, not move the people to the team, this is usually a common mistake by management (pulling people out of the team, should always be a NO GO) who try to solve one problem but create several new on the way…
Before you start to create teams, consider the size of the teams, trust in the team is based on trust between the team members, and the more members, the more relationships – remember to count in the PO and SM in the team size.
Building trust in the team takes time and you always have to focus on it, even when you think that you are done – “Overcoming the Five dysfunctions of a Team” by Patrick Lencioni is a good place to start, but as with everything else in Agile, it is continuous learning, you are never done.
Mindset
One of the most important things management must do in an Agile organization is to create a safe environment, management needs to understand that the best way to improve is to learn from mistakes, we need to try out new things and learn from them – as Edison have been quoted for “I have not failed, I’ve just found 10.000 ways that won’t work”.
Trust outside the team is equally important!
领英推荐
It is important how you communicate with others, you must (especially management) always encourage a “growth mindset”, praise the learning, do not focus on the failures! This is not only the job of management, but also team members need to learn this, but management can encourage the team to learn it ??
Ownership – You build it, you own it!
The team need to feel ownership of what they do and what they build, I often say that if you have handover, you have things to improve, the team should own what they build, they should not handover maintenance to someone else!
The team must understand that they build and own it together, I was once working with a team with developers and testers, when I started, the team had not managed to finish the work they committed, but in the 2. sprint, the developers managed to finish the development tasks, however the testers had not been able to test all of it; the developers were very excited, until I asked the question: “As a team, did you manage to deliver what you committed to?”, after this the team allocated some time for the developers to learn the test scripts, so they could help the testers to build automatic tests if they became a bottleneck, and moving forward the team succeeded several times – and they also had a few sprints where they did not manage to finish all the work – which is a good thing – we need to challenge ourselves to become better!
Planning, estimating and follow-up
When a team do refinement, i.e. when they look at coming work and secure that it is ready for planning, they often estimate the stories in story points – it is important that you do not estimate stories in days, but instead use reference stories to compare and estimate in what we call story points – this will give the team a velocity (which btw is individual for each team, as they have different reference stories), a velocity can be used for many different things, a few: The team can see if they are improving (velocity goes up) and you can use the velocity to create a roadmap of coming releases (require that you have estimated your backlog).
When the team do sprint planning, I often recommend them to break stories into tasks and estimate the tasks in hours (based on the knowledge they have at that time) – the idea of estimating tasks in hours is to follow the burndown during the sprint, i.e. at the daily stand-up, the team members have been working on a task and have a much better understanding of the remaining work (the new estimate), so they should update the task with remaining time and the team can see if they are on track or not – it is important that the team focus on the remaining time, not the time spend, i.e. if you estimated a task to 13 hours and after working with it for 2 hours, you believe that you will be done in 5 hours, you should set the remaining to 5 hours not 11, and the remaining time can also be bigger than the original estimate, i.e. instead of 5 hours remaining, you might estimate that there is 20 hours remaining – it is important that the team members are honest and transparent for the team to learn and succeed!
Summary:
Literature:
Tuckman’s stages of group development: https://en.wikipedia.org/wiki/Tuckman%27s_stages_of_group_development
“Five dysfunctions of a team” by Patrick Lencioni
“The Ideal TeamPlayer” by Patrick Lencioni
“Mindset” by Carol Dweck
Agile Coach for Product Management and teams. Empathic but result oriented. Focused on mentoring people to achieve the most valuable outcome for them and the company
3 年Hi Rune, thank you for a good article. In regard of estimating the tasks in hours, I do see a pitfall. In most teams there are people with different skills and knowledge, and what 1 person might think is a 2 hours task, the other might believe is a 14 hours task - this can lead to long debates on the estimate, which is not really helpful, as both persons could be right, depending on who will do the task. If your reasoning is based on "person A will take this task, and that person will then do a rough estimate on the hours, and update if/when needed", then I would agree. How do you see this? And BTW - agree that spent hours are so much yesterdays news, but it might be that some good findings are there for future handling of similar things. ??????
Lead Software Enigneer at SimCorp
3 年A good read, Rune! Thank you. I especially like your description of the signifacant relation betweeen a team's performance and the trust within the team that, in turn, depends strongly on the stability of the team and on the environment that is shaped by management.
So interesting reading Rune - and agree trust building environment and psykologi safety is a must for agile teams