Tag Archives: Scrum

Make the Customer Try Out Your Product

Posted by on 2011/12/07 No comments

I’ve been participating in demo meetings with customers and product owners for years now, but we seldom talked about interesting things or rarely made significant decisions during these meetings. There can be several explanations to that, but I’m pretty convinced that we were doing these meetings wrong. The chart below depicts the categories help you understand why I think this way. Here are the content of the user stories brought to the meetings:

The figure represents quite a typical progress, nothing is wrong about it at first sight. Let’s add to the picture what has been discussed after each sprint during the mentioned demo meeting. For example, during the demo meeting of sprint 3, we mostly talked about user interface (UI) issues and only a little about functionality:

In most of the cases the team presents a subset of user stories during the meeting, and the customer just sits there – because it is a presentation after all – and has a couple of comments on the user interface of the product. Sometimes, they talk about real functionality, but that is not enough. Everything is just fine until the product is released or delivered for system testing:

This is the point when the customer really “enters” into the “functionality” section and even into the “non-functional requirements” section and starts using the product. What happens now is a disaster, because

  • the delivered software works differently than it is supposed to work
  • nobody really remembers how to use the product
  • it doesn’t meet the performance criteria

I think everybody has been in a similar situation who is doing Scrum. Read more »

VN:F [1.9.17_1161]
Rating: 10.0/10 (2 votes cast)

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.17_1161]
Rating: 10.0/10 (1 vote cast)

Physical and Electronic Boards

Posted by on 2011/07/13 No comments

Several weeks ago, I went to a team leader event with @csapoz and Krisz, where – besides other interesting topics – we talked about the usage of physical and electronic Kanban and Scrum boards. At that time I thought that electronic boards were evil – kill communication and collaboration -, but I decided to give a try to their suggestion: use the physical board for tracking and collaboration, and use the electronic board for administration.

It turned out that the idea is excellent, and my early fears were groundless. My colleagues are hardly using the electronic tool, and every important decision and discussion is done in front of the physical board.

As an electronic tool, we are using redmine in order to

  • store our user stories, feature requests and defects
  • record queued, started, finished dates for our cumulative flow diagram (CFD)
  • record estimated and spent times for improving our planning, and for our Product Owner

Our post-its on the Kanban board have the following information:

  • redmine issue number and a short slogan
  • queued, started, finished dates for tracking ageing items
  • number of times an issue had to be moved back

We have been working with both systems for almost two months now, and there isn’t any administrative overhead, and actually it is easier to generate charts from the database of redmine than from post-its.

Usually, electronic tools come with fancy AJAX based boards, and it is really tempting to use them, but actually, they aren’t that advanced at the moment – lack of flexibility for example -, and they kill the collaboration.

I know that I could set up the tool so that I get yet another annoying email about a change, but when I see somebody moving a post-it on the physical board, I know that something has changed, I can go there and talk about it. No electronic tool can replace this experience.

What do you think? If you are using electronic tools, how are you using them?

VN:F [1.9.17_1161]
Rating: 0.0/10 (0 votes cast)

Guest Blogger: The Time-box Issue

Posted by on 2011/06/21 No comments

This is the first time in the history of my blog that I share the thoughts of a guest blogger. I introduced Kanban to my friend Peter (@keksz_i on twitter), who is very exited about Kanban and eager to learn more about it. Unfortunately, he had to participate in a less successful planning meeting…

The Time-box Issue

I just recently got familiar to Kanban – thanks to Zsolt – and I’ve started digging myself deep into Lean thinking. As a progress, day by day I am realizing more and more about the drawbacks of Scrum during my work. Hereby I’d like to share some of these small but rather important experiences.

We were at a planning team meeting. Our team was expected to commit 22-24 story points, based on the team’s velocity. We’ve already selected 18 story points of high priority stories from the backlog, but there was another 8 pointer “must to have” high priority story. Obviously, that could not fit to the sprint, as we would had 26 points with the 8 pointer. All other stories had lower priorities or they were not even estimated. How shall we proceed in that situation? We had a customer pressure to deliver to that story as well, but we could not, as it was a very high risk that we are not going to finish it by the end of the sprint. Basically we were in a time trap indicated by the iteration.

There were two possible solutions. One of them is to look after smaller stories from the backlog and fill the gap with them. Unfortunately, we haven’t had them. Even if we had had other stories to take, that solution wouldn’t been effective. Doing low priority things (stories, fixing low priority bugs, technical depth) just to fill the sprint instead of doing the real important jobs is really a waste. We definitely should not have done that.

We went for the second option: splitting the 8 pointer story to smaller stories. We were able to split it into two 3 pointer and a 5 pointer story. The first was a kind of preparation story for the epic with no testing effort. The other 3 pointer and the 5 pointer were the actual implementation stories including testing. By doing the splitting, we were able to commit to the two 3 pointer stories, having 24 points to work on in the current sprint and most likely having the remaining 5 pointer story in the next sprint. This looks much better for the first glance, but if we have a closer look we can realize that there is a huge waste. We had to do an estimation session to so the splitting, we doubled the testing effort where obviously we had overlaps and we had to prepare and demo it 3 times for the customer. In fact, the estimation numbers are also reflected the waste, as the overall complexity of the original epic became 9.

Using Kanban, all of these wastes would not arise at all. In Kanban, there is continuous delivery, there is no time box to fit. In Kanban, we would just pull the 8 pointer story, implement, test and deliver it at once. Without extra estimation sessions, without testing and demonstrating a half-functional story, without waste.

 

VN:F [1.9.17_1161]
Rating: 10.0/10 (1 vote cast)

Kanban on Organisational Level

Posted by on 2011/05/16 No comments

A couple of days ago, I talked to the head of an organisation, who was having a hard time to get an overview of the current work of her organisation, and struggling to have enough manpower in order to deliver products in time. This is a common problem, I had talked to other leaders who had the same issue, and in fact I was in a similar situation before myself. As a solution, we introduced Kanban on the organisation level.

The Problems

Before jumping into the middle, let’s have a look at the problems which triggered this introduction in my case:

  • Missing overview of the ongoing work items
  • Not enough manpower to deliver

Why is it hard to get an overview? It is a very good question indeed. Usually the head of an organisation – later on in this article I’m going to refer to her as leader -, has to deal with several things during the day, and it is very easy to lose track of the recent events, which may change on hourly or daily basis. Usually she only gets back into the picture when something turns south, but usually by then it is already too late.

In a healthy organisation, everybody is working on something, but for how long, when will it be finished, how much effort has been spent on it? These are also very good questions, and usually one has to dig quite deep in the organisation to find the answers. These answers are crucial for acquiring new work items into the organisation. Unfortunately, they are very often incorrect, and takes time to get them, so leaders take new work items based on inaccurate data, and then the organisation becomes overburden.

I truly believe that using a Kanban system can help solve such problems. Let’s see how.

Read more »

VN:F [1.9.17_1161]
Rating: 9.0/10 (1 vote cast)