Tag Archives: improvement

Introducing the Expectation Line in Scrum

Posted by on 2011/11/12 5 comments

Several weeks ago my colleague Tamás made an interesting point about our planning meetings: we always committed to an iteration backlog – we are doing an interesting combination of Scrum and Kanban, but not Scrumban -, but we never asked our product owner whether she was happy with our commitment. She said that she hadn’t been satisfied, but followed what Scrum said anyway - classic autopilot behavior. This got me thinking and I realized that during the last couple of years every product owner I met had this very same problem: scrum was new and it didn’t help them much, because before Scrum the business dictated the speed of the development, but after introducing Scrum the development slowed down and started to live its own separate life.

In order to understand why, first have a look at this typical iteration backlog lifecycle:

The first sprint is usually more successful than the second one, but after five or six sprints the number of delivered user stories stabilizes – in Scrum terms: the velocity becomes stable. I talked to different Scrum Masters from different organisations and they independently told me that after the teams reach this kind of threshold, no matter what the product owner says or does, they deliver exactly the same amount of user stories. This is the point when the team starts its own life and starts to dictate to business: no matter what the product owner‘s expectation is, she will get the same amount of user stories sprint by sprint. Which is somehow good, makes the development predictable, but the business is never predictable, on the contrary, it changes a lot. Since the outcome of the planning does not follow the expectations of the product owner – which is driven by the business – she starts to ignore Scrum and eventually she gives up and from then on she will just pretend to be a product owner, when in reality she will fall back to classic project management.

Read more »

VN:F [1.9.13_1145]
Rating: 10.0/10 (1 vote cast)

Local Leadership Fail

Posted by on 2011/09/27 No comments

Today’s post isn’t about software development, it is about an epic leadership fail I had the honour to live through. As it happened, I had to go shopping several days ago. There is a nice store nearby, I go there all the time, but this time I got into the middle of an unpleasant situation between the cashier ladies and a customer. Actually, they were shouting at each other, and I was standing right in the middle of their little war. As it turned out, the problem was that the customer wanted to – and did – pay with small change. Actually, she had a bag of coins. The customer didn’t like the tone of the cashier ladies, and they didn’t like the bag of coins. The cashiers insisted that the proper way to pay with a large amount of coins is to have them in rolls, which is not true any more.

There are too many fails in this situation, for example

  • although the customer isn’t always right, her money is as good as anybody’s, so take it
  • even if a cashier is underpaid, there is no reason to be primitive. If she doesn’t like working as a cashier, then she should quit and look for another job
  • don’t ruin somebody else’s day (like mine) with your frustration

But somebody was missing, at least for me. Oh right, the shift leader. Actually, I saw him in the store: he was sorting tea boxes about four meters away from the danger zone. There was no way that he didn’t hear anything from the fight, and yet he chose to mind the teas instead. How nice of him, because everybody wants to buy tea on a hot Sunday afternoon.

Actually, what he did is a nice example of bad leadership. Hide when the heat comes and let the employees take it. It is not a surprise that the cashier ladies always complain about him to the customers, including me. This is another interesting “feature” of the store: complaining to the customers. The cashiers don’t respect the shift leader, and the only thing he can do in order to keep up his status quo is to abuse his power and set a schedule for the cashiers they definitely don’t like, and show them who the boss is. Still, it wasn’t him who deserved the fail prize from me: it was his boss, who also happened to be in the store! She was the one who was supposed to tell him: “Get over there, solve the problem and after that, come to my office!“.

Nice little company, I have to admit. But they have to change soon, because the competition is coming and it is coming fast. Another German store is being built right next to this store. They are famous for their great but cheap products, and their customer service. How will they compete with them? Using their very weak leadership skills and attitude? I hardly think so. They’ll certainly fail.

When I was in Germany several years ago, I was in a store of this chain – the new one -, and I had a lot of coins with me. It’s worth spending them abroad because they are kind of useless in Hungary – you cannot exchange coins, only notes. So I paid about 20 euros with a handful of coins. Literally, I had my hand full of change. Nothing happened. They took my money, I got my goods and everybody was happy, end of story.

There are several lessons here:

  • Always be with your team, and help them no matter what
  • Take the heat from the customers, it is part of your job
  • Never abuse your power
  • Don’t give power to those who cannot handle it

And the last one is for myself:

  • Find a new store
VN:F [1.9.13_1145]
Rating: 10.0/10 (4 votes cast)

When Expand and Collapse Got Beaten

Posted by on 2011/09/14 No comments

Today’s post is an instructive story about mixing various good patterns and ideas. They are very useful separately, but when one uses them together, they may lead to problems which nobody wants to deal with at all.

We found several different defects in a certain feature, and in order to reduce handover costs I collapsed them together to make an “umbrella defect” (defect1+defect2+…defectN) and put it into our Queue. When my colleague started to work on it, I was quite happy with the result: less handover costs less context switching and more focus on a faulty feature. It was really nice until our deployment day came. Or Kanban board and version tree looked like this:

The mentioned umbrella defect appears as ‘UD‘ on the Kanban board, and it covers ‘UD1.1‘ and ‘UD1.2‘. Based on our Kanban board, there is no impediment to the deployment, but right before the deployment we realized that not everything we wanted to deploy had been tested since we were using one-track. One-track means that we don’t have branches, labels or tags, we just have the trunk where we have our latest version. One-track is an excellent thing, but it seems that it doesn’t work well with collapsing.

Read more »

VN:F [1.9.13_1145]
Rating: 0.0/10 (0 votes cast)

Our Detective’s Blackboard

Posted by on 2011/09/06 No comments

My colleague Attila and I had an interesting discussion several days ago:

- Zsolt, I feel that sometimes we are missing the big picture.
- That’s not cool, and it may explain the high number of work items moved back.
- Maybe, but can we do planning together again? I miss it.
- Sure we can, but no regular planning meetings, right?
- Of course not.

As my friend @keksz_i pointed out, regular planning meetings aren’t that effective and I’m also not a great fan of them: talking to the product owner is a brilliant idea, but the traditional task breakdown is just a tremendous waste of time. After our discussion, it was clear to us that we had to bring the planning back, but we needed something new, something effective. So we came up with the following detective’s blackboard for our next feature:

It is drawn on a large piece of paper and hangs on the wall right next to our Kanban board. It has all the information we need in order to do our work: the big picture, how our user interfaces will look like and how they will communicate with other parts of the application. Additionally, we also have work items, prioritisation, test plan and estimation.

Read more »

VN:F [1.9.13_1145]
Rating: 0.0/10 (0 votes cast)

Customer Diversity

Posted by on 2011/08/23 No comments

Last year at xp2010 Scott E. Page talked about the benefits of diversity inside an organisation. According to Scott, diversity improves the performance and decision making process of an organisation.

Today late afternoon I attended a startup meetup event where Patrick Vlaskovits talked a bit about the diversity among customers. Based on his experience startup companies should define themselves a specific market segment – their customers – which they can serve properly and are really passionate about.

Imagine that a company works with a variety of customers. Different people want different things – sorry for the cliché – and there is no way that a startup company can deliver a feature or a set of features which satisfies all of them. This eventually will cause dissatisfaction among the customers, and they’ll leave the company. Fewer customers means less revenue or no revenue at all, and the company shuts down.

Startups aren’t necessary small companies, actually, their size does not matter that much, but their passion really does. People start companies because they have a good idea, they see something in it, and finally but not least they are passionate about it. If the “not-the-target” customer wants a feature which the company is not interested in at all, it is pretty sure that there won’t be any passion in working on that feature. Without passion the product will lose its edge, and the real (target) customers may leave.

It seems that a company can really benefit from the diversity among team members, but on the other hand, it causes trouble if we are talking about customers. Read more »

VN:F [1.9.13_1145]
Rating: 0.0/10 (0 votes cast)