Ative at Work - All Comments

re: Good Project, Bad Project

Christian Bjerre — Sat, 14 Jan 2012 06:47:36 GMT

Lots of good facts about test and test code here.

One interesting thing can be added: Test code seems to have lower code quality than production code. Thus people are even less motivated to create good tests ...

re: The TDD Controversy - JAOO 2007

magento themes — Thu, 07 Apr 2011 09:08:37 GMT

Managing development will be one of them. I've had the (mis)fortune to mostly work on existing software, meaning I have just had to fit in with whatever was already in place (usually not much).

re: Retrospectives - Adapting to Reality

Luke Hohmann — Fri, 25 Mar 2011 18:19:44 GMT

Can you share a picture or sketch of this technique? It sounds really compelling, but I'm not sure how I'd organize it in a team. Thanks.

re: Lean Principle Number 1 - Eliminate Waste

Martin Jul — Sun, 30 Jan 2011 22:13:28 GMT

Hi Fernando

Thanks for the excellent input. It is very good advice and very actionable.

Thanks a lot for sharing.

Martin

re: Lean Principle Number 1 - Eliminate Waste

Fernando Carvalho — Thu, 20 Jan 2011 21:35:17 GMT

What is waste?

First you need to realise what you costumer realy want, and pay you to do.

Next, you must focus on do just what you're paid to do.

Code is one, for instance.

How can you work with the minimum stock possible?

You must realise that many requirements are inventories, and you must work with only one at a time.

In order to resolve only one requirement, how many documents you need? How many handoffs you need?

Working with only one requirement, temporary forgeting every thing else, you will find what is absolutaly necessary to produce that one requirement, and what is waste.

Hope it helps.

re: Lean Principle Number 1 - Eliminate Waste

Martin Jul — Tue, 11 Jan 2011 21:17:06 GMT

You are absolutely right that it is often difficult to identify the waste. If it were, I am sure it would have been already removed.

The root cause is frequently that the causal dependencies between the things we do and the downstream outcomes are not always clear.

Sometimes the scientific method is the great arbiter. You can make an experiment with a control group and measure the impact of what you do compared to not doing it.

However, in my own experience, and this is what I heard from the lean senseis at Toyota as well, you often don't need statistical analysis and the whole apparatus.

If you map out the value stream - all the activities that go into producing a certain product, and try to relate them to how they create value for the customer, a lot of the waste becomes very clear.

It is often hiding in interactions between departments.

For example, there is often a great deal of management work related to planning and scheduling so each department can maximise its utilization, rather than maximizing the value creation flow across departments.

For example, we worked with a company that had a very expensive bug tracking system and detailed change management processes with executives meeting to prioritize which defects should be fixed first.

We did a multi-year project with this company and eliminated the need for that whole process. By keeping the software at a constantly high quality the list of open issues was tracked on post it notes, and since the turn-around time on fixing anything that was found was on the scale of hours, there would be no bugs to prioritize in the executive meeting.

The bug tracking system and the bureaucracy around it was suddenly waste.

Of course, if the organisation is routinely creating defective software it may be better to have the process in place, so it was surely invented to save resources and improve the outcome, but it was hinged on low quality.

When the quality improved, a lot of the bureaucracy became obsolete.

Therefore, we should always strive to improve quality and revisit our assumptions - why are we doing this? what would need to change to make this unnecessary?how can we make this activity obsolete?

Once it becomes clear that you have a lot of bureaucracy BECAUSE your quality is low it points very clearly to where you should start if you want to remove the waste.

Starting the other way around just makes you look like a fool since you have the sickness and you just suggested to not even try curing the symptom.

re: Lean Principle Number 1 - Eliminate Waste

Lean Manufacturing Techniques — Tue, 11 Jan 2011 11:17:46 GMT

Many people came to work today to spend their time on waste? Some maybe! But not most. So what is waste, and how do you identify it?

Some waste is obvious. But other forms of waste are more difficult to spot or to solve. I’m sure in most organisations it’s sometimes very difficult to identify what is waste and what is not. Some processes or conventions might seem wasteful, but actually provide real value elsewhere in the organisation, or prevent other forms of waste from emerging later. Other activities may seem valuable, but actually do not really result in any real value.

re: Retrospectives - Adapting to Reality

Diana Larsen — Sat, 23 Oct 2010 14:48:37 GMT

Martin, I enjoyed this post and agree with you that continuous improvement is at the heart of all effective retrospectives. I'll add your Do Don't Try activity to the ones I keep on my website. I worry a bit about stopping at naming the critical issues. I've not seen many team situations in which simply recognizing ineffective behavior is enough. You don't need "bureaucratic control mechanisms." Just an idea about how to proceed and someone(s) on the team to commit to taking action. For instance, Bas Vodde has written about "now actions" that work well for his teams.

www.scrumalliance.org/.../61-plan-of-action

I look for the thing team members have the most energy to tackle, identify the now action(s), ask who will commit to it, and make a task card to take into iteration planning. Also lightweight, and more likely to result in improvement.

Avoiding bureaucracy is certainly a worthy goal, and stopping at naming may not create action. I recommend you find an activity in between the two to sustain your team's Kaizen.

Thanks for the post.

re: The Waste of Defects - Bugs are Stop-the-Line Issues

Jen — Tue, 21 Sep 2010 12:43:54 GMT

Just for clarification

Lean talks about "Andon" and not "stop the line". "Stop the line" could be one state of Andon. Primarily "Andon" is a notification system of a quality / process problem. The alert can be activated manually by a worker using a pull cord or button. The alert is usually a signal light - yellow or red. Red could also mean that the line is automatically stopped - but that is not implicit. Therefore I would say that it should rather be called "Pull the line" because you can pull the line for a yellow signal which does not stop the line. Stopping the line is only an utmost action.

Nevertheless, bugs could be issues for the red signal. But not all bugs require to stop the line - they need focused attention.

re: How Scrum Reduces Rework

Peter Saddington — Wed, 08 Sep 2010 21:36:54 GMT

Sounds like those organizations need a "product management team" to align the work.

I've found that organizing such a team helps them (all those POs) get together and prioritize work, etc.

re: How Scrum Reduces Rework

Martin Jul — Wed, 08 Sep 2010 20:26:18 GMT

Yes, it is definitely our experience that getting the Product Owner role to work is the single most difficult thing in implementing Scrum.

In many large organisations the PO is usually a team of people since no single person has enough knowledge about the domain across all departments and this, of course, which makes things more difficult.

It is worth the effort, though.

I have process data showing how we evolved the scope along the way and discarded a huge amount of low-value ideas before implementing them (almost 2x the delivered scope) on a project that delivered a much better and relevant system on time and budget than originally planned all due to working closely with the product owner on backlog and priorities.

re: How Scrum Reduces Rework

Peter Saddington — Wed, 08 Sep 2010 01:43:42 GMT

Great article on how Scrum reduces rework. One of the things that I would assume are obvious here is that you have a product owner that is available and apparent throughout the process to allow the team to make the changes necessary to utilize Scrum with these capabilities. You could almost say: "Having an involved and available Product Owner takes care of 91% of issues in rework."

www.whitebarrel.com

re: Myths about SCRUM - "it's a daily stand-up meeting"

Martin Jul — Wed, 28 Jul 2010 13:37:00 GMT

The key to successful stand-ups is that everybody understands why it is important and valuable. People are smart, so if it is just a daily nuisance with no visible benefit it will degenerate.

re: Myths about SCRUM - "it's a daily stand-up meeting"

Juha — Wed, 28 Jul 2010 08:56:44 GMT

Thanks for the post, just what I was looking for. I noticed that when I tried to be efficient and not waste time during the daily scrum it lead to situation where everybody just said how much to deduct their estimate and people were avoiding to speak about problems. Fast, but not scrum :). Maybe thats what you need the cert for, creating open but efficient atmosphere for scrums.

re: Learning TPS from Toyota in Nagoya

Martin Jul — Wed, 23 Jun 2010 11:34:23 GMT

You are most welcome :-)

Regards,

Martin