Tag Archives: customer

When Local Optimization Won’t Make a Difference

Posted by on 2012/05/21 No comments

A couple of weeks ago, I mentioned at the office during my measure and manage flow in practice talk that we should invest more in optimizing the whole flow and reduce the efforts spend on local optimizations. In retrospect, I didn’t spent too much time on explaining why, because it had a very loose connection to the subject of the talk, and I assumed that the audience would understand what I meant anyway. Well, I have to admit I was wrong. Since the talk, I’ve participated in several discussions were we just stated that local optimization is bad and I met only one guy who was able to give me an example, why was it harmful in his environment. However, I think it is not too late to make this right. Local optimization is not a bad thing, but it won’t make any difference - or will make it worse - when it is not part of the global improvement initiative.

This is is what I think about local optimization:

First of all, optimization means that an organization does certain improvements, and as a result, its lead time (the time the whole organization needs to finish the whole process) gets shorter. Second, local optimization means that a team, which is in connection with at least one other team, reduces its cycle time (the time needed to finish a certain phase in the whole process). Most probably, this improvement won’t have any affect on the lead time when the other teams have different goals.

This is a common flow in a software development process:

The blue rectangles are the phases in the process. For example, analysis (1), development (2),  testing (3), and integration (4). The width of the rectangle represents the cycle time. Team 1 is working in Phase 1, Team 2 in Phase 2 etc.

Read more »

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

Visualize the Flow on the Highest Possible Level

Posted by on 2012/03/19 2 comments

I gave an internal workshop about Kanban a couple of days ago, and the colleagues who were there looked enlightened when I mentioned that Kanban should visualize the whole process, because this is the place where it can help the most. Don’t get me wrong, it is also fine to have Kanban on the team level, but the real optimization and improvement should happen on the highest possible level. Since their reaction surprised me – I thought the goal of Kanban was clear to them – I decided to write a bit about the reasons. A little repetition won’t hurt.

The first core principle of Kanban says: “visualize the workflow” which means that we should make the steps of our processes visible so that we have a clear picture of what happens after the customer sent us a request and we deliver a product. In case of a small company where there’s a direct contact to the customer, and delivering the product does not involve a third party, the [work]flow can be visualized quite simply:

However, large companies tend to have complicated processes, and several teams are participating in the whole flow:

Read more »

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

Increase Customer Satisfaction with the Kano Model

Posted by on 2012/01/14 No comments

A couple of weeks ago I had a great discussion with one of my colleagues about the Kano model and how we could use it to make better deliveries. The model itself is a classification of features of a product based on customer needs and attributes. It was created by Professor Noriaki Kano (on the right) in the 1980s. Professor Kano defined three different feature categories: basic, performance and excitement, which are represented on the diagram below. The x-axis defines the effort put into the execution/implementation of a feature, and the y-axis defines the customer’s satisfaction after receiving the feature. In the software industry poor execution can result in a faulty or unusable product.

The presence of the features belonging to the basic category which presence has no positive effect on the customer’s satisfaction – bottom right corner -, but they are must have features, so their absence or poor quality causes huge dissatisfaction – bottom left corner. Let’s say we are about to create a web shop. It is a must have feature to make it possible for a customer to sign up to the site. Even if it’s the most sophisticated sign up feature, for the users, it is just a sign up feature, but without it or with a faulty one, they cannot use the site, so they’ll leave.
Satisfaction in the features categorized as performance is proportional to the quality in which the features are implemented/delivered. Let’s say we introduce Facebook as an alternative sign up procedure. It isn’t a must have feature, but it will increase the customers’ satisfaction in the project: the users can use their existing accounts, and we don’t have to store user data unnecessarily. After Facebook we introduce twitter as the next alternative. It has no effect on the existing users but may attract more customers.
The last category is the excitement which is the complete opposite of the basic category: the presence of an excitement feature drastically increases the customers’ satisfaction, but nothing happens when it is not there or doesn’t work as expected. For example, we introduce a feature which allows customers to use our shop without signing up, just using their email address and PayPal. If it’s available, the users will be excited to use this great convenience feature, if it’s not, they won’t miss it

Read more »

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

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)

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.17_1161]
Rating: 0.0/10 (0 votes cast)