AGILE IN ACTION

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 .

Via InfoQ . Nils Haugen explains planning poker and how it works. At XP Day in 2006, I attended Nils' session Experiments in Agile Estimation .

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!

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:

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.

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.

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

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.