Have you ever thought about the largest impediments while working according Scrum?
I personally encountered following largest impediments with teams i was working.
Story points and relative estimation
We realized that it is very difficult to separate time and size while making estimates for specific tasks. Another problem related to this issue is trying to be very specific while estimating with story points. This led to a lot of misunderstandings at the start. It’s quite difficult to realize that duration of implementation might differ for both tasks estimated as the same size. 3 is not equal 3 !!! 🙂
The very first team’s impressions was – How can it be?! So, it led to a frustration at first. But one thing helped us a lot – we made an analogy to simple physical formula: V (speed) = S (distance) / T (time)
We agreed on meanings for formula’s elements.
V is team’s velocity and it can change over time. We can go faster or slower which depends on situation – someone i sick, we face a lot of impediments and etc. Team’s goal is to achieve constant/predictable speed.
T is our fixed sprint time box (2 weeks)
S is size of our features that we want to estimate. It’s a common thing to measure destination in meters (Europe). So team’s goal was to identify “our” meters, to make it easier we took some already implemented tasks as standard for our measures.
Analogy with meters also helps to explain why 3 is not equal to 3. Imagine that someone asks you to measure a distance from your home to work and lake nearby. You might say that it is about 9 km to both destinations, but when you measure actual distance (traveling the distance/taking item into development) you identify that distance to you work is 8,5 km and distance to the lake is 10,1 km. So, initial estimates are not equal, they only help you to have an understanding of size!
After we applied this rule several time it became very easy to estimate by story points. Btw, we used Fibonacci.
Agile (not only?) development practices
I mean automated testing, integration testing, developers do testing, and etc. Why “not only?”, well i think these practices are applicable everywhere.
Our quality reduced dramatically during first sprints. It should have been expected result since we were developing more than we were actually able to test and verify. Developers refused to test. It led to very simple thing – while one feature was developed another stopped working.
It was a nightmare, team started to blame Scrum, we couldn’t finish product backlog items properly, everybody was disappointed.
We did the following. We reduced speed (velocity) and dedicated some time for test automation and integration testing. The team was surprised how much value it gave them. They were able to detect problems in advance and in no time. It was a break through, team saw the value and they started to apply automation everywhere they could. And developers do testing, but in a different way.
Communication with other teams
I faced very interesting problem at very early stages of applying Scrum – people started to avoid helping other teams despite the fact that they are working for the same project. Team members were focused only on their own goals and they were afraid of doing anything else except what was planned in the current sprint.
This issue helped us to identify one simple problem – cross-dependencies were not identified properly by our product owners. We increased cross communication among the teams to be able to detect possible dependencies as soon as possible. Cross dependent items are included into the same sprint for several teams. Joint planning sessions and cross team short meetings are organized in a periodic manner (Scrum Masters can cancel those meetings if they are not relevant for the current sprint).
I again was curious
what other people think about this topic and what impediment they have encountered. I started a topic on the scrum alliance group. You can read all the answers in details here
- Writing good user stories – clearly
- Let the developer do the estimates
- Functional managers try to control their “resources”
- Interference (intrusion)
- Team contribution during sprint planning
- Some members tries to force only their way.
- One way communications
- Estimating tasks with huge buffers
- Management offers no time for the team to learn, with deadline pressure as the reason
- Fear and habbit (no willing to change)
- Misconceptions about Scrum
- Contracts not adapted to Agile
- User stories not completely “done” at the end of the Sprint
Do you recognize yourself here?