AGILE IN ACTION

Since writing the original Agile Zealot's Handbook , Gus and I have had the chance to reflect on some of the wording. And Mishkin Berteig's recent generalisation of the handbook has prompted 3 minor editions: 1. We changed the title of TECH to QUALITY because delivering business value without compromising quality is achieved through the disciplined application of practices. 2. We modified the LEARNING text. We added reflection to inspection because it's one thing to look closely at something, but you need to think more deeply about it to reveal root causes and identify further actions. We also added re-planning as a specific activity that must occur at every iteration boundary, which along with adaptation and improvement, is based on what you learnt from the previous iteration. 3. Under TEAM, we felt a team also needs to be empowered to be creative because only when it has the freedom to be creative will it find better solutions by taking risks, failing fast and trying different things. So here's the new version:

Gus describes the characteristics he would expect to see in an agile company . While Jason Gorman talks about recognising agility in a company. And Rachel Davies has some ideas about things she would look for in an agile company .

At Google, Ken Schwaber talked about Scrum and described Infrastructure (or Core) Software and the pain that it generates for an agile team. Infrastructure Software provides functionality that most other software depends on and must therefore integrate with. Typical problems are: It's fragile because so many things are dependent on it. Change something in the infrastructure and some external, dependent software breaks. It's brittle because it wasn't developed with sufficient automated tests. Change something in the infrastructure and something else in the infrastructure breaks. There are only a few people left who know the code and are willing to work on it. So, you're working in an agile team, hustling along at a sustainable pace. You can develop new functionality quickly, that is until you have a dependency on the infrastructure. Bang! There goes your velocity. Your productivity is completely throttled back by the velocity of the infrastructure team/s (assuming they need to write some code to support your new functionality). And their velocity is much less than yours because of the problems above. Ken asked, where Infrastructure Software comes from? He determined that it was a result of teams coming under pressure to get more done, and habitually cutting quality and writing crap code (rather than saying ' No! We can only get this much done in an iteration '). This has knock-on effects during subsequent iterations, as they stop paying constant attention to design and technical excellence and end up building legacy out of the box. Voila! Infrastructure Software. Another infrastructure problem relates to physical organisation, e.g. when companies centralise specific skills, such as operations or database administration, apparently to improve efficiency. Unnecessary external dependencies such as these will also throttle an agile team's velocity. This is not an effective way of working together to get things done and deliver business value. Build whole, cross-functional teams that include their own operations and database administration skills. Because centralised teams, such as operations, are disconnected from say, product teams, and because they probably support many product teams, they cannot be expected to possess extensive domain knowledge or a detailed familiarity with each product. Therefore, to make centralised teams viable, organisations allow them to enforce standardisation. And, standardisation kills innovation. Bummer!

InfoQ recently published an article titled Debating agility at Thoughtworks , which follows an exchange of views about perceived religious entrenchment and dogmatism among practitioners of agile methods. I guess some people might think me religious, especially after Gus and I wrote what we sarcastically called the Zealot's Handbook . I don't think it's far off the first edition of Extreme Programming Explained , but perhaps with the knobs turned up a little further than 10. I choose to follow the Zealot's Handbook because I produce better quality, achieve higher productivity and experience more fun when I do. I'm not religious about it. My choice is an objective decision made by an experienced person based on empirical results obtained in the field. I've been doing Extreme Programming for 6 years and in that time I've tried many variations and they've never been as successful as when I follow the Zealot's Handbook . This success is why I choose not to compromise my agility and why I avoid a pick and mix of practices. I'm a person driven by my values: trust, courage, empowerment, accountability, respect, communication (including feedback) and simplicity. They are the heart of me. I'm a person guided by my principles and, in the context of software product development, I'm also guided by the principles of the Agile Manifesto and the principles of Extreme Programming and Lean . As such, the adaptations I make to gain improvement do not conflict with my values nor my principles. This enhances my agility. If the adaptations did conflict with my values or my principles, my conscience would wrestle with my actions and I would be at odds with myself. This would make me unhappy and my agility would be diluted to some agile mediocrity.

I read John Scumniotales 's post on Team Leadership and Self Organization a few weeks back and I've been meaning to comment. There are a few things I don't agree with: John says:

When a company wants to make lasting change, for whatever reason, it’s usually not enough to change just the physical organization. Shuffling hierarchy, bringing in new people for existing roles, and creating new roles with new responsibilities will not, in and of itself, produce the enduring improvements being sought.

Who's making the decisions around here? Oh everyone in that committee over there! But they don't have the authority to make decisions. Ah I see. Actually no-one is making decisions around here. No? Ok. Let me see if I've got this right: If it's architecture decisions I need to speak with him. If it's timescale and priority decisions I need to speak with her. If it's decisions on requirements I need to speak with them over there. For this dependency I need to speak with him or her, except when it's relating to this, in which case I need to call her. And for this other dependency I need to contact this guy in India. And why are you making the decisions all the way up there (in the hierarchy)? Look how many layers of management I need to get through to ask you to make a decision. Don't you trust those working at the coalface to make the decisions? Getting decisions made in a hierarchical company organised by roles can be confusing, difficult and wasteful. I observed exactly this problem last night, in Can Gerry Robinson Fix the NHS? Obfuscated decision-making contributes to constipation .

Do things happen too slowly in your organisation? If they do, your organisation is constipated. Look at how decisions are made. Is anyone making decisions? If they are, how far is the decision-maker from the point where the decision is needed? Are committees involved without the requisite authority to make decisions? Does decision-making emphasise a chain of command, control and adherence to policy or procedure? How many layers of management approval need to be obtained before anything can be done? I see this all the time in large organisations and it's frustrating and then depressing.

In today's Metro newspaper, there was an article titled 7m GBP to tell mandarins how to keep desks tidy . It said that civil servants at National Insurance offices in North Tyneside were being trained how to keep their desks tidy and free of clutter. This is part of a pilot Lean programme brought in by consultants Unipart to boost efficiency. Apparently, black tape is stuck to desks at various locations to indicate where people should place their phone, keyboard, stationery, etc. Is this part of an application of the 5S Philosophy ? If it is, I hope it's part of a more extensive programme to introduce a Lean thinking culture, which aims to eliminate waste and improve effectiveness and quality. Otherwise the net result will be nothing more than a lot of very clean desks. The 5S Philosophy focuses on effective work place organization and standardised work procedures, which together simplify the work environment. There are 5 steps: Seiri - Sort and eliminate unnecessary items from the workplace. Seiton - Set in order and utilise efficient and effective storage methods. Seiso - Shine, thoroughly clean the work area regularly. Seiketsu - Standardise best practices in the work area. Shitsuke - Sustain a new standard of work place organisation because human nature resists change and it's too easy to return to the old way of doing things. Since I read Tom DeMarco 's book, Slack , I focus on being effective before efficient . I always aim to be effective first because it has a more immediate impact than being efficient. And once you're effective you become more efficient naturally. More large organisations should take a leaf out of this book.

Be prepared for some rib tickling chuckles when you read Resign Patterns Ailments of Unsuitable Project-Disoriented Software by Michael Duell.