Monthly Archives: November 2014

What we can learn from our Lean cousins at Alcoa


A few weeks ago I visited the Alcoa rolling stock facility at Point Henry. The facility has been successful in producing high quality product and keeping market share in production of rolled aluminium of the sort used in the blanks for drink and food cans. A year ago though, predicting that it would be unable to keep pace with mega production facilities rapidly coming on line in China, the US parent company decided to close down the facility.

I was expecting my tour to be a somewhat depressing experience, given that we were just seven weeks away from the shut down. This couldn’t have been further from the truth. I was introduced to a bunch of highly motivated, highly skilled individuals, who not only knew their stuff about Lean, but who had developed a unique and effective approach to quality – one that us folk in the Agile world can learn from.

Alcoa introduced Lean at this plant in 2006. It was a top down, not negotiable introduction of this methodology. Lean experts from Toyota were brought in to provide consulting advice, but it was the effort of those on the ground who worked to transform culture and develop brilliant quality methodologies, that lead to the successful outcome.

The cultural change focused on:

  • Developing self-organising teams
  • Getting close to customers to understand quality
  • Reducing waste
  • Encouraging everyone to voice great ideas

It was in this environment of openness to great ideas, that the safety team, and then the quality team embedded an understanding that there are three ways that quality fails occur:

1. Automatic (or knowledge based)

When we complete a task which we have done many times and which we are highly familiar with, we are effectively on auto pilot. If someone were to ask you which red lights you stopped at on your way home from work, you’d most likely be unable to recall, because stopping at red lights is part of your automatic mindset. The quoted figure for individuals failing an automatic tasks is 1 in 1000.

2. Rule based

When we complete tasks based on a fixed rule, we mostly adhere to the rule. When driving home from work in the early hours of the morning, rules tell us that we should stop at a stop sign and not treat it as a give way sign. However the likelihood of an individual always adhering to this rule is reduced by comparison to automatic functions. The quoted figure for individuals failing to adhere to rule bound tasks is 1 in 100.

3. Unfamiliar (or skill based)

Where an individual is embarking on a new and unfamiliar task, the likelihood of error is obviously much higher. Driving on the other side of the road when travelling overseas is an example of where a familiar task is suddenly unfamiliar. Coming back to work after a break and finding that something such as the code base, has changed, is another time we are likely to make errors. The likelihood of quality failures in this situation is very high and is estimated to be at between 1 in 2 and 1 in 10.

The teams at Alcoa specifically respond to this by flagging during standup, whether tasks they are embarking on that day are automatic, rule based, or unfamiliar. Not only do they flag this, but the whole team actively identifies the likely error traps and discusses mitigation for these.

This struck me as an incredibly useful model for Agile teams eager to improve their quality. Before embarking on development tasks, encouraging the whole team to put their heads together to ask a bunch of questions. Are there any tasks we are embarking on that could adversely affect our code base or architecture? Will what we are doing today impact others in the organisation? What level of preparatory work might be required to reduce defects? Is what we are doing going to generate an unreasonable amount of waste? Have we taken into account lack of knowledge of any individuals about to embark on this task? Do we have all the information we need to commence this task? What are the likely error traps? How can we mitigate these? I’ve included a screen shot of the Alcoa pre-task checklist.

A bunch of other impressive quality measures also jumped out at me from the visit to Alcoa. During the transformation to Lean, the local implementers immediately recognised resistance to change as the key blocker to success. However as some people came on board with the new way of working, that involved clarity of roles, a huge degree of cross skilling and encouraging continuous improvement, what also emerged were individuals who showed initiative to lead the cultural change as “Champions”. Leveraging off the initiative of these individuals, quality champions became embedded in every team. It wasn’t their job to take sole responsibility for quality, but to keep abreast of best practice, teach the team and nurture initiatives and activities of those in the team. It’s true that in Agile we expect everyone to take responsibility for quality in every phase and in every build, but utilising the passion of someone who is a quality champion can help embed ownership of this within a team.

What impressed me most at Alcoa was the understanding that every Operator had about the customer who was buying their product. The guys knew where the rolled aluminium would be used, for what purpose and most importantly what level of defect would be tolerated in that product. In discussion with the Operators, I was reminded of the principle of trade-off sliders often used in Agile inceptions. Achieving a high level of quality is going to require a high level of input. In Agile inceptions and beyond, we aim to reach agreement on a time versus output scale. Perhaps we should also be asking what level of quality can we deliver for the time and cost? Do we need to discover more about our customer, to decide on the level of tolerable defects? Are our developers informed about who our customers are, or is it just the product people who understand this?

When Eric Reis in The Lean Statup talks about early adopters tolerating a higher degree of inconvenience given the often rudimentary nature of first implementations, should we too be asking questions about just how slick, defect free and seamless every implementation needs to be? Perhaps we should be asking – where does this drop sit in the implementation lifecycle, or how does return on investment fit with increasing our defect detection and remediation?

Being a typical Lean environment, there’s heaps more measurement at Alcoa than in the average Agile environment. Every morning, representatives across the entire production process meet in the “8:30 room”. It is of course named “the 8:30 room” because at 8:30am representatives from each team come together after their individual team standups, for a Scrum of Scrums. The 8:30 room is a glassed in area on the factory floor, which is home to the most massive and the most effective information radiator I have ever seen. Casting my eye over it, I could immediately see where specific teams were up to that day in terms of production, risks and issues. The focus of this communication is to validate dependencies and risks across the whole production process for that specific day. Targets versus actual output is discussed, as are quality and safety issues. Most importantly, with representatives from each team present, blockers can be immediately resolved.

Scrum of scrums is a practice I’ve seen implemented across various workplaces, but with varying degrees of success. It needs rules, and a rhythm, just as standups do. The scrum of scrums I’ve been involved in could have benefited from introduction of more measurement to validate where there were blockers affecting other teams. Keeping a greater focus on interdependencies and quality traps is something I’ll be much more likely to do after seeing this in action at Alcoa.

Finally to some cultural quality initiatives at Alcoa that really made my heart sing. I’ve previously blogged about the step in the product lifecycle at, which is simply called “Thinking”. At Alcoa “Bright Ideas” are an encouraged part of the quality lifecycle. The fun bit is that each week, the person who has suggested the best bright idea, gets to spin a wheel of fortune style wheel, with various dollar amounts on it. The winner also gets to nominate the charity to which the money will be donated. Some of these bright ideas go on to become Kaizen, or continuous improvement initiatives, while others are acknowledged as great ideas, but with lesser business value.

In the same way that flagging potential improvements is acknowledged, staff are also rewarded for “pulling the help chain”. An equivalent to Toyota’s Andon cord, the help chain is the signal to cease production. It’s a fundamental safeguard to protecting output quality. In Alcoa waste is easily quantifiable. Waste has to be re-smelted and go through the whole production process again. Once rolled aluminium is colour coated, re-smelting is even more expensive and it has to go to a specific smelter that can manage the toxic output of burning the colour coating.

In Agile we value quality at every stage of our production too. We acknowledge that quality at every step produces a quality end product. How could we do better on this though, by learning from our Lean cousins, not just to identify, but to quantify waste? If we implement an interface that hasn’t had the eye of a User Experience Designer caste over it, and the interface is not fit for purpose, the cost of this in the development lifecycle can easily be quantified. How much better would we do if we quantify the cost in our projects of not pulling the help chain when we spot code that will potentially break the code base, or activities that will introduce technical debt, or implementations that will adversely affect other teams!

Alcoa pre-task briefing

Alcoa pre-task briefing checklist



Teaching fun: the great pancake cookup


I recently attended a workshop on developing effective teams. The university I work for is in the earlyish stage of Agile maturity. I’m not. That’s why they’ve hired me. To introduce Agile and transform their digital team.

The workshop facilitator asked us to think about the most successful team experience we’ve had across our career and what made a successful team. The answers to this question came hard and fast – a great leader, enough resources, clarity of roles. I shouted out my answer along with the other participants – FUN! Silence descended on the room. All other participants looked at me. The facilitator responded, “no one has ever used that word to describe why a team was successful.

I discovered in that instant that in this organisation, needed to learn that work could also be fun.

I quickly devised a way for us to combine both an activity to embed a better understanding of story articulation, with teaching the team to have a bit of fun. This project, which in the planning phase I ran with the utmost seriousness, was labelled The Great Pancake Cookup.

The team was invited to an express project inception where we fleshed out our elevator pitch:

For the Digital Team
Who need to have fun through an inclusive team activity
The Great Pancake Cookup is a lunchtime event
That will allow us to enjoy a delicious meal we prepare ourselves, actualise how well we collaborate AND make all other staff insanely jealous as the delicious smell permeates the office.
Unlike other teams, our lunchtime event will not consist of soggy veal parmas or limp burgers, but express our inner Masterchef through both creative savoury and sweet pancakes.

The scene was set. We got right down to discussing our trade off sliders.

Time: We decided on one hour from prep to consumption – preferring to slightly supress our inner Masterchef in favour of having enough time to enjoy our meal.

Budget: We agreed to each kick in about the equivalent of what we’d normally spend on eating out for lunch.

Quality: This wasn’t something we were prepared to compromise on, as we had clarity on our customer base’s expectations – nothing less than scrumptious. We did agree to compromise on presentation though, given our time constraints.

Scope: As Product Owner, I really needed to temper scope creep. Yes – a choice of 10 savoury and 10 sweet toppings was attractive – for the breakfast buffet at the Hyatt Hotel, but could the consumers still feel delighted with perhaps 4 or each? I surveyed them and they thought there would still be good uptake.

The day of the event arrived. As Product Owner, I was busy approving stories so they could be moved into the done column:

As the Digital team, we want to have all the correct equipment available for cooking pancakes, so that we can successfully prepare our meal.

Acceptance criteria:

  • mixing bowl
  • power whisk
  • three electric frying pans
  • two broad blade spatulas (a link to an image of a spatula had been thoughtfully inserted into this acceptance criteria)
  • power board

As the Digital team, we want to have all the correct ingredients available for preparing and cooking pancake batter, so that we can successfully prepare our pancakes.

Acceptance criteria:

  • Self-raising flour
  • Back yard chook eggs
  • Lactose free milk
  • Oil for frying

The Devs were standing by about to plug in the three electric frying pans and ramp them up to 200 degrees. “Wait”, I yelled, “we may have forgotten to articulate one particular story:

As the Digital team, we want to ensure the electrical items we are using are tagged, so that we can comply with the university’s safety standards and so that we do not create an electrical failure, or worse, in the staff kitchen.

A quick consultation and we agreed that the risk of shorting the staff kitchen and leaving everyone else without the use of a microwave was outweighed by the benefit of pancakes. We compromised on using two frying pans.

The event was a huge success, on many fronts.

A team fairly new to Scrum, learnt the rudiments of project inception and story articulation

The team moved from what would be called in the early childhood education arena “parallel play” to “group play”.

We had fun!

We showed those around use that work can be fun.

Most importantly – The pancakes were super good.

What next?

We decided that soggy parmas and limp burgers are sometimes nice, particularly on a Friday when you can get a $10 deal at the local pub.

We also decided that when we do team lunches, we’ll take it in turns to bring in a bunch of moderately healthy stuff we can assemble ourselves. The foodies in the group bring home grown heritage tomatoes, sometimes it’s burritos or bagels and dips.

But it’s the “assemble it ourselves” part that’s important. The interaction of chopping veggies together, chatting while we wait in the queue at the microwave and sitting down to enjoy what we’ve prepared.