I’ve run into the following situations that make absolutely no sense to me. I suspect there must be an elephant in the room for them to occur, and I wonder if anyone has suggestions as to what this elephant might look like.
Situation 1: A team selects 5 product backlog items for a monthly Sprint. However, the team doesn’t finish regression testing and performance testing, and the unit tests are incomplete as well. When I ask the team why it didn’t just select as many items during Sprint Planning as it could actually complete (maybe only 2), the team members respond that the project is 10 months long and consists of 50 Product Backlog items, so they obviously have to select 5 items per Sprint to get the work done. I ask them about their Scrum training, in which they were shown how to select onlythe Product Backlog items that they could completely “do” within the Sprint. The team members tell me that could only work if there were fewer Product Backlog items.
Situation 2: A team selects 5 product backlog items for a monthly Sprint. They leave out regression testing and performance testing, telling me that they will do those things later. Why didn’t the team choose fewer product backlog items and actually complete all the necessary testing? Doesn’t the team realize that undone work accumulates every Sprint, and that undone work accumulates in an exponential, unpredictable sense? Undone work behaves much like compound interest on credit cards.
Situation 3: A Product Owner tells me that the team is going to have to go faster to hit the date and deliver all of the functionality. Why is it so hard for Product Owners to understand that some 60% of all functionality delivered is rarely or never used? The best way to “hit a date” it to remove functionality.
In all of these circumstances, people are acting completely contrary to what they have been taught and coached: done, transparency, and value-driven development. What thinking, emotion, or habit stops them from taking advantage of these learnings?
Ken Schwaber's Blog: Telling It Like It Is 
There are two main problems going on usually in these situations.
1. Lack of faith
There is likely a lack of faith that completely doing work is better than half-finishing work.
There is likely a lack of faith that things like unit testing and regression testing are valuable, and overall will decrease the total project time.
There is likely a lack of faith that that interest or credit card technical debt will catch up with them and have negative implications.
Why are people fat, don’t exercise, and eat fast food? Is it because they don’t know better? No, it is because they don’t really believe that little drops can ever fill a bucket. The same thing is going on here.
2. It is not coming from top down.
If the message is not coming from top down, and supported all the way down, people will not put their necks on the line to do the right thing (in general.)
So many times, executive management agrees with the ideas, but they do not have faith in the discipline required to get there.
It is tempting for a middle manager to inflate the productivity of his team by bending the rules.
Product owners look better when their teams accomplish more work.
All of these things compound to produce this problem, IMO.
IMO, poor leadership or weak management contribute to these type of scenarios most of the time. “we have to…” syndrome is often the culprit and often I find the team isn’t able to say no or make a realistic commitment due to outside pressure from somewhere.
Scrum can’t get much simpler however everyone involved needs to understand how it works and a strong leader or Scrum Master needs to grow a pair sometimes to help break old habits.
It is counter one’s intuition that by doing less items you can actually deliver more value.
One can only actually believe in it by being pragmatic enough to trust the actual data, or by their own experience. In most cases I have seen, the ideas only start to settle after a few projects.
In my mind it is a bit like understanding the theory of relativity. The data shows some bizarre events taking place, but it is very hard to visualize those things happening and believing in them.
People still think in terms of Newtonian laws, and most of the time not even that. Well, until you actually need to put a satellite in orbit.
Fear.
For the two first situations, the value of testing does not seem to be understood by the team members. Do they have some metrics to evaluate the time spent on bugfix and regressionfix?
Situations 1 and 2 are familiar to me. In the first, it seems that the Team would rather go along with what they believe are Management’s expectations and let Managment react to delays than to say up front they cannot do what is being expected of them. I map it to a lack of courage and openness.
In the second, people who add features to the product expect (and they’re usually correct) to be evaluated and valued as independent agents who add value (ie: features) to the system and not as part of a team that succeeds and fails together. Consider who feels more secure near the end of any release where the testing debt has become mountainous. Hint: it’s not the testers.
I would suspect that there is not one but manu elephants in the room… The most visibile one to me is: maybe the teaching (and learning) is the problem?
One elephant might be this: Teachings are not necessarily learnings.
Maybe will sound strange but I think EDUCATION is the problem. Education it’s the root of all good and also evil things. With a 2 days SCRUM training or even few month of environment and practices change process you cannot fight decades of seeded education, day by day, step by step. Interesting question that I also had in mind since I had my first problems introducing SCRUM. I will try to write something more elaborate, as a reply to this question in a future post on my blog.
People get used to things they know and use. Teams are told how many features they have to deliver and what is the deadline. So they do it at the pace which allow them to hit the window, forget-about-quality.
When they implement Scrum and at the beginning it is all fine. But then project managers, senior management, business folks, C-level execs, you-name-it come and tell them and tell them it has to be done this or that way. The pressure is strong enough people adjust their behaviors to what environment wants. And it ends up exactly like in your examples.
But these aren’t people in teams who should be blamed. The truth is if senior management works to break any process used by the team they will succeed. So the real problem here is lack of support, or understanding, of agile processes by folks being higher in pecking order.
The elephant is the management, that still buys into the “squirrel burger” illusion – that is that if they ‘push people hard enough’ they will get what they want by when they want it. It will take a generation change in the management to get out of this problem for good.
In my opinion, it’s the management by objectives that leads to this kind of behavior. If your performance is always correlated to short term objectives, why would you try to make it better when you’re just expected to do it? In financial industry (in France at least), traders now have a bonus that is (also) correlated to long term objectives. It should be the same in IT world, if your product has too much rework in the next three years, 0 bonus.
I would suggest that perhaps they fully comprehend the principles and values of Scrum. If they did, then they would understand that you do not make commitments you cannot keep in Scrum and that at times you need courage to say “no” to that one last Product Backlog item.
That is DIDN’T fully comprehend…
Your comment reminds me that for many teams ‘doing Scrum’ is not a primary goal. They may adopt or even embrace Scrum because they believe it’s useful, but they also hang on to a number of antipatterns which they also believe are useful. Letting go of something which got you to where you are is hard.
i can see 3 elephants here:
1) there is some kind of “blindness syndrome”, all these problems are obvious to us, but no to the team. sure they feel something is going wrong, sure they know it can just go worse. it doesn’t matter what the technical details are here, if testing.. partially done work.. anyway we see it.. they are going to be late
2) whenever they notice that…. they prefer to not change it, may be they don’t want to change they way to work, may be they are scared by management. what we lack here at the base is the lack of desire to change.
3) they lack the experience, capability and mindset to mutate this situation. at all level.
probably they missed the point that being agile means being agile at all levels. from stockholders to programmers. we all have to be able to change to produce more value.
all have to steer and change direction leaving the brake.
a single foot on the brake would stop the car.
one little add
the reason for 2) is for sure some personal goal… could be hidden, but it’s there for sure
IMO the Scrum Master is the only one who can rectify this situation. If management asked to deliver equal-size features in fixed time frame then, we should analyze the velocity of the team whether we can really deliver this from up-front.
Another thought, I worked in a project where regression was not required or required for a very few potential impacted components. This is because of the design which avoided coupling. The added features were isolated functions not in the core stream of the product.
1. Fear is a bad advisor.
2. Those teams need courage and a coach.
3. Where’s the difference between ex 1, 2 and 3?
Why? Survival instincts trump cognitive skills.
Why do people act contrary to what they were taught? They are afraid.
What learning might help? How to say “No.” That action, when conducted skillfully, will open everyone to a host of emotional issues that are rarely explored.
Why isn’t there training about the topic of saying no? Trainers are afraid? If you aren’t a skillful dancer when the elephants arrive, you will be squashed.
You ask what Stops them? Those poor guys environment hasn’t been trained and coached to the necessary level and they are lost out in the dark with a training and knowledge they can’t apply in their environment.
Might be the coach overlooked that 😉
They just get too much noise compared to then small training and coaching they received, and so it all wears off quite soon. It’s normal, then. To get rid of those beliefs and habits for an organization (not individuals) takes ages. It’s one of yen factors SCRUM doesn’t take into account enough: Organizations need enormous time for deep changes, even contrary to all rational knowledge.
Markus
The Elephant:
You can’t teach someone to ride a bicycle on a one day theory course.
Or, perhaps a better analogy if you’ve seen Pixar’s Cars, you can’t teach someone to turn right in order to go left. They’ve spent their whole life turning left to go left.
Jamie
When scope and time are fixed, the only place to flex is quality.
As far as technical deficit goes, over the short term, it is a lot easier to hide a quality issue than to hide a missed due date.
Yup. It’s not uncommon. Some teams even drop drawing burndown charts to take the evidence they fail (sprint by sprint by sprint) out of the sight. Sometimes management makes the team to remove the card table because “it does not look good”. That’s right – I had a fight once – a team was requested to kill the cork table because it didn’t allow (physically) to add more to the sprint. It was so damn full of cards already.
Oh and it scales with an ease. Multiple projects done in parallel, lasting forever, every single one.
The problem is people tend to think in terms of tasks (doing) not work products (done). It starts with the management – there must be a heat in the factory, right? – quickly it gets reflected in developers mindsets – I must prove I’m really, really busy to get a raise etc. One could not possibly be busy enough with just a single thing on his/her plate, right? It is a proven management strategy – ask to do more, and more, and more until you get a vivid objection. Than ask to do more.
Flip side of the coin is (we must not forget about it) the fact the code could be polished forever (Parkinson law). It is an artifact of an art after all, isn’t it? 😉 Therefore the team needs a stop sign, showing the right (expected) level of “good enough” to allow everyone move along to the next story without a guilty conscience. DoD helps, working with Product Owner on daily basis helps even more.
And I agree with others – one can’t tell people to behave differently, they need to be presented with evidence over and over again. It requires consistency and (sometimes lots of) courage.
Pingback: 有头大象在屋里-Scrum爱好者