Categories

At Xebia, we like experimenting with new solutions that enable us to give a more satisfying answer to our customers. One of these questions is: are Agile and Scrum applicable to non-IT environments? And though we are known with project such as wikispeed, we wanted to prove it on ourselves. So we did.

A product manufacturer joined us in our idea. In 4 months we changed their product development department, as well as all connected departments. We discovered that Scrum as a framework is compatible with non-IT environments. So we discovered our way of working within the framework. While looking at the results, we asked ourselves: what are the key values in this company, that made this change successful?

At first glance, the Agile manifesto does not give an answer. Though very concrete, The Agile manifesto has some hidden values in it. We made a first step to discover them.

Feedback: gain feedback in order to learn and make your product better. Feedback is needed when you want to embrace change, is the output of interaction and de purpose of customer collaboration. Feedback is the foundation of Agile and for example Lean startups. Lean startups is not about building a product as soon as possible, it is about gaining feedback as soon as possible so you can valid your business case.
Gaining feedback is possible in various ways. Architects (the ones who are designing houses) gain feedback by a drawing, the butcher gives you a piece so you can taste the product you want to buy. Car manufacturers gives demonstrations to the car press and sometimes even involve them in the development of the car. Be creative in gaining feedback and the way you demonstrate your product.

Iterative: Don’t try to be perfect at once. Or even try to solve the whole puzzle at once. At the start of building a new product, you do not know what the outcome will be, nor your client. So try to solve the puzzle while gaining feedback with the product you have. Only with the feedback of your customer, you are able to be most valuable for your client – and your company. Iterations help with gaining feedback, and force you to split things up. While timeboxing yourself, you enforce ourself to be concrete and work on real products instead of paper.
Small sized products are required for working iterative. But their is no objection to work in even smaller sizes, such as user stories. If you cannot create user stories (sometimes teams just couldn’t) you can always try to add a new feature or make an improvement to your product within 2-4 weeks. You can even do an experiment in order to validate your (technical) assumptions or make a proof-of-concept (what’s in a word).

Valuable: Everything you do, should have value for the customer (customer value), the company (business value) or required by law (regulatory value). This is written in order. Ask your customer what he needs the most, he is the only one who can tell you!
Don’t accept the product value that is stated initially without asking why. Too often there are hidden assumptions in it (the customer likes this, so it has lots of value) that are not true. Asking five times why helps to find the real reason. Try to prove your assumptions, while using Lean startup techniques or by asking the customer. Quantitative arguments of a business case have extra value to the qualitative arguments.

Cooperation: You can cooperate at two levels: within and outside our team. Cooperation within your team creates synergy and helps people to get the best out of them. Cooperation outside your team helps to get the customer heard. And oh, he wants to be heard. Really. Interaction -and even more: collaboration- is not only valid within your team. It is even more valuable outside your team.
You can cooperate at various ways. Prefer the one that gives you the most layers of interaction: verbal, non-verbal, written, realtime are examples of such layers. Standing together at a whiteboard includes all layers of interaction and is the most valuable one.

We discovered that these values are applicable for all sorts of environments, no matter what kind of products are made. That is not a surprise: most agilists agree that the Agile philosophy is a major step forward in the history of business. Agile is able to not only change IT, but also the world outside IT. With the Agile manifesto and these values in our toolkit, we think lots of non-IT companies are able to become Agile too.

Shares

Previous post

Next post

Comments

the wikispeed url in the page gives a 404.
for people who have never worked in a manufacturing development department it might be interesting to give some examples of what was the ‘before’ and ‘after’.

This sentence: “Agile is able to not only change IT, but also the world outside IT.” completely ignores the roots of the principles Scrum is based on.

Please know your history! Manufacturing as an industry in general, including product development, do not need anything like Scrum. Perhaps some disorganized individual companies can benefit from it, but applying the Scrum framework ignores a lot of the real principles which underly Lean.

If you want to move to the world of manufacturing, read Deming, Takeuchi and Nonaka, and others. Don’t try to impose a watered down version of some principles translated into an enforcing framework that values processes over responsibility.

You’re right that Scrum has its roots in Lean. When I get a question regarding a manufacturing facility, I will surely answer them with Lean. That does not mean that the values of Agile are not valid within a production environment. I think that Lean is Agile, although it is not necessary to claim this.

In general, Lean is applicable in production environments (where products are manufactured in large quantities), and Agile is applicable in development environments (where products are ‘manufactured’ once). You can even apply lean product development if you want to. (http://en.wikipedia.org/wiki/Lean_product_development)

In general I would recommend to work based on principles rather than method alone. In the end, each method (or framework) has its limitations and in the end none is universally applicable. Both Scrum and Lean are great but often fall victim to this.

It’s not a of question how and when we can apply Scrum, but how we can learn and achieve results. Tho that end, experimenting like this is a good thing.

Isn’t lean manufacturing about building a product not designing a product?

The description here is of working with a product development department (the design engineers in the office not the guys on the shop floor)?

So when Kristian say “Agile is applicable to development environments” I read it as they applied means the design office not the machine shop which builds the design.

Lean design, when back-ported to software developers, suggests I need to have some code fragments ready to drag and drop into a running solution on demand; always the fantasy of model driven development but I am not sure it has come to fruition yet…