Energized Work | agile in action: July 2007

Planning poker

Links to this post

0 Comments

Don't multitask

Kevin Fox identifies multitasking as one of the main reasons why projects take so long and are still completed late. He says there are three central reasons organizations find themselves in the trap of multitasking:

Most people simply don't understand the impact of multitasking:

They don't recognise the inherent interruption (and disruption) in task-switching and the delays it creates. The drivers for multitasking are built into the processes, measurements, and systems most companies use to manage their projects. We strive hard to keep people busy all of the time, to maximize the output and be efficient. This coupled with conventional scheduling techniques routinely leads to overloading people, making multitasking nearly inevitable. Switching tasks before they're complete is waste.

Erroneous assumptions are built into the processes, measures, and systems used to manage projects:

Chief among these is the belief that the earlier you start a project, the earlier it will finish. This is probably valid when people don't need to work on multiple projects. But in a multi-project environment, starting new projects earlier only increases the work in process and with it the likelihood of multitasking. Though it seems counter-intuitive, projects will finish earlier and more of them will get done if they're started later. The pressure from upper management and sales to add more projects or start them earlier, in parallel with projects that haven't yet completed, can make it virtually impossible for project managers to cope with the pressure to multitask. How many times is someone redirected to work on an urgent task, only for it to end up sitting at a step downstream waiting on something else, or because the priorities shifted again? Multitasking is a way to avoid prioritisation.

Most people genuinely want to do a good job, they just don't know how:

People multitask in response to perceived needs in the organization - an urgent job, a critical task, a customer complaint. If you have multitasking in your organization, it's almost a sure sign that you have people who care about doing a good job and are working hard for the organization (excluding those who want to be seen as heroes). But remember the first reason - most people don't understand the impact of multitasking. It's an accepted mode of working. People must realize the impact of multitasking and shift their belief of what it means 'to do a good job'. And this must be supported by changes to the process, measurement, and system.

Tags: lean, multitasking

Links to this post

0 Comments

Time pacing, rhythm and choreography

Lean uses the concept of time pacing to provide regularity. Events are undertaken at regular intervals so that this week's schedule is as similar as possible to last week's schedule. For example, Intel introduces new microprocessors at regular intervals rather than waiting for design breakthroughs or market pressures. Agile methods use iterations as fixed-length repeating cycles. Their regularity creates a relentless sense of urgency (especially 1-week iterations) and, over time, a rhythm is established, which helps people work proactively. Without rhythm people tend to be reactive. The transition from one iteration to the next is carefully choreographed (through an iteration review drawing the current iteration to a conclusion, a retrospective to identify and take what is learnt into the next iteration, and a planning game to kick-start the next iteration) so that the changeover is completed without appearing to down tools and really stop.

We run our lives on the basis of routine. We don't need a schedule to determine when we should have breakfast every day. Regularity and rhythm give us the ability to achieve a continuous flow that delivers valuable functionality to customers regularly rather than batch and queue big releases.

Tags: time pacing, rhythm, lean, agile

Links to this post

0 Comments

Who cares about software?

Well, I do for a start. I'm fed up with incompetence, poor quality, complacency, mediocrity, compromise, and short-termism. I care about software. And so should you!

Links to this post

1 Comments

Visibility is a good thing

Via Lean Blog.

Ford CEO, Alan Mulally, talks about the concept of making problems visible and how Ford had a culture of hiding the problems to make things look good. He tells a story:

One of the first meetings we had, I asked how it's going, and most of it was all green and a little yellow. I said, "Hey, we lost like $12 billion, it can't all be green."

The next week, [Ford Executive Vice President] Mark Fields was launching the Edge [Ford's new small sport-utility vehicle] up at Oakville [Ontario]. He had a technical issue, so he chose not to deliver the car because we wanted to start off with the highest quality. In the weekly review, he presents the chart with all the launches. It has all the greens, yellows and this one big red box. The place goes silent.

I started to clap. I said, "Mark, that is great visibility and I am glad you understand that. Is there any help you need? Other resources you could get from technical or product development?"

So, within a couple weeks it went from red to yellow to green and we had a great launch. It's not a warm and fuzzy thing, it's relentless focus on your area. The expectation is we will portray it exactly as it is, and that's OK. What will not be OK is not dealing with it.

Scrum is based on empirical process control theory where everything is kept visible at all times, you inspect frequently creating more opportunities to obtain feedback, and you adapt frequently to keep improving and to optimise results. There's no hiding problems, burying bad news or ignoring obstacles. Visibility of problems provides better information on which to make more informed decisions.

When you start Scrum, almost immediately it reveals pre-existing problems. Newcomers often blame the problems on Scrum and claim that the process isn't working. Don't panic! And don't blame Scrum. It's doing what it's meant to do. See the problems, understand them and deal with them.

Tags: visibility, scrum, lean

Links to this post

0 Comments

Competing against time

More than ever the element of time is critical to businesses today. Businesses need to compete on the basis of speed to achieve a competitive edge in the marketplace. Being responsive to customers needs as they occur and reducing the time between conception and delivery to the customer are central to Lean. Stalk and Hout in their book, Competing Against Time, identified 4 rules of response:

The 0.05 to 5 rule: Value is being added between 0.05% and 5% of the total time.

The 3/3 rule: The wait time, during which no value is added is split 3 ways, each accounting for approximately one third of the time:

Waiting for the completion of batches
Waiting for physical and intellectual rework
Waiting for management decisions

The 1/4-2-20 rule: For every quartering of the total completion time, productivity will double and cost will be reduced by 20%.

The 3 x 2 rule: Companies competing on the basis of speed enjoy growth rates of three times the average, and twice the profit margin.

Tags: lean

Links to this post

0 Comments

A bit of trust goes a long way

In a trusting environment, great swathes of bureaucracy can be removed, hierarchy can be flattened, and process can be simplified and streamlined, saving time and effort. Trusting relationships between organisations, teams and team members give people the freedom and confidence to experiment, learn, be creative, make decisions and share knowledge. People become more cooperative and collaborate on work. Communication becomes conversational and more effective. And a communal atmosphere grows as things become less formal. People are friendlier and more casual, and have fun. Untapped human potential is tapped.

When trust is prevalent it's just so much easier to get stuff done.

Tags: trust

Links to this post

0 Comments

A journey without an end

I have a hard time with the words 'adopting Agile' or 'transitioning to Agile'. (Notice that I'm using Agile with a big 'A'.) They suggest an end state, but I don't think there is an end state. It's certainly possible to be 'not agile'. I believe agility is a scale measured by your ability to deliver value to customers in a continuous flow realising maximum return on investment for the business while dealing with change in a rational and empirical way, and having fun doing it. In my mind, achieving agility is simply a journey of continuous inspection and adaptation, and in lean terms, a journey of continuous improvement. It's a journey without an end. And that's no bad thing.

Many people are afraid of this "no end-state". Sometimes they use it as an excuse not to embark on the journey. Others simply invent an end-state (and stop trying to improve). I said before that we're not limited by our abilities but by our vision. I see this thinking as a lack of vision. They're not seeing all the step-by-step improvements for what they are: Tangible improvements that add value. If something moves you forward to something better and adds value, it's got to be worth doing for those reasons alone. Who cares about an end-state?

As Chris Pitts says, there's no time like the present. So, start your journey today and begin improving from here.

Tags: agile, lean, vision, continuous improvement

Links to this post

0 Comments

Soft skills or character attributes

Over on Delivering Value, Chris Pitts talks about the non-technical skills or attributes that are important in an agile team:

The most important skill is empathy. You've got to see what the other guy is talking about even if you consider it to be wrong. Equally, you have to see what issues your colleagues have and be prepared to help. You need the courage to share information openly and honestly (and your fellow team members are empathic, right? So it should be safe to do this). Finally all this boils down to trust and the ability to communicate without being judgmental (or judged). But, perhaps the number one skill is the ability to have fun while working!

Chris contrasts this with the political corporate culture so prevalent today:

Corporate droids often see information sharing as a weakness to be exploited. In the same vein, the ability to see another's point of view and to help them is also considered a weakness. It stops you from using the information they've divulged against them to climb the corporate ladder. Corporate droids hate to see people having fun. There is no direct value in fun. And, combine short-termism with a modicum of fear, e.g. loss of job, lousy performance review and impact on career, and you get CYA syndrome.

Feel free to join the Delivering Value social network.

Links to this post

0 Comments

Adaptation and organisational change

In the last Agile Practitioners Forum there was a debate about why there is a need for organisational change when using agile methods. At least 2 people were arguing that there isn't a need to bring about change outside the project. The majority, however, were saying that there comes a time when the wider organisation becomes a constraint and inhibits a project team's ability to improve further and achieve higher levels of quality and throughput.

A bugbear of mine, and I've been harping on about it again and again and again, is how many organisations restrict adaptation to how they practice agile methods. Some practices are used and not others, principles are ignored or compromised, values are not understood and little is done to establish an ecosystem in which project success can be achieved. They refuse to entertain the idea that the organisation needs to adapt too. As George Dinwiddie says: Organisations want the benefits of Agile, but they don't want to give up the cubes and solo development work. They don't trust the team to self-organise and create valuable software, so they stick with organisational frameworks that prevent the very things they fear won't happen.

One of Brian Marick's themes about agility is that it's about acting to change the context more than it is about adapting to suit the context. Inevitably there needs to be some local adaptation because agility is in constant interplay with its environment. But organisations need to empower the people doing the work to ask themselves "what should I change about my environment that would enable me to work better?" and then take the necessary actions to bring about that change. When an organisation is trying to achieve agility, restricting change to just the project imposes a glass ceiling on a team's ability to get better. This is effectively capping human potential and that can't be good for the organisation going forward.

Tags: adaptation, organisational change

Links to this post

2 Comments

Value

Understand value from your customers' perspective.

Zeithaml and Bitner define value as some combination of the following:

Value is low price. E.g. the customer wants a bargain. Stop doing all of the activities that do not directly contribute to product value.

Value is whatever I want in a product. E.g. the customer wants to experience owning an exclusive brand pair of trainers rather than just any old trainers. This is marketing.

Value is the quality I get for what I pay. E.g. the customer expects more for his money.

Value is what I get for what I give. E.g. taking absolutely everything in account, the customer considers a particular luxury car to be worth the money and the wait, if there's a delay in delivery. It's not just about the money.

Structure your organisation and arrange your process so that value can flow from your company to your customer. Any activities that are not adding value for your customer are waste.

Tags: value, lean

Links to this post

0 Comments