New Agile Zealot's Handbook
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:
VALUE
IF you don't repeatedly release software
into the production environment
at least once every month
that realises value for your business
and satisfies your customers...
QUALITY
IF you're not paying constant attention to technical excellence
with simple, effective, incremental design
driven by continuous, repeatable automated testing
with at least 95% coverage...
LEARNING
IF you're not learning
by inspecting and reflecting every iteration
and you're not re-planning, adapting and improving
all of the time based on what you've learnt...
TEAM
IF your team is not empowered to self-organise and be creative,
does not sit together and engage in face-to-face communication,
does not include your customer
and all the necessary skills to make its own decisions and take immediate action...
THEN YOU HAVE COMPROMISED YOUR AGILITY
Tags:
agile zealot,
agile values,
agile principles,
compromised agility
Links to this post
A word on outsourcing
Don't!
Tags:
outsourcing
Links to this post
'Infrastructure' isn't all it's cracked up to be
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!
Tags:
agile,
scrum,
infrastructure software,
organisational infrastructure
Links to this post
Religious? Dogmatic? Or just strongly principled
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.
Tags:
dogmatic agile,
agile religion
Links to this post
My take on self-organisation and leadership
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:
A team has to have a strong, management supported leader.
In Scrum, the Scrum Master provides
servant leadership to the team. In terms of technical leadership I like to build redundancy into a team to avoid single points of failure. I encourage the team to see the role of leader as something that can move from one person to another as the situation changes. Any person in the team is free to demonstrate leadership at any time, e.g. if someone knows more about something than the others and they persuade them to take a particular course of action, then that person is leading. I believe management should visibly and vocally support the whole team and every person in it, and not just the leader.
John says:
The team lead has equal and balanced knowledge, respect and appreciation for all disciplines required to get software built. As such, the team lead can dive into details with team members to help remove impediments regardless of whether it's a development, test, scope, or documentation issue.
I strongly believe that every person in the team should have these attributes. And every person should have the awareness to keep their game up.
John says:
The team lead owns the resources and schedule. The team lead has authority and control to direct and modify project resources. Also, operating within bounds defined by the business, the team lead can alter the schedule.
I don't think any one person should have authority in a self-organising team. I'm a firm believer in
participatory decision-making and being driven by consensus (using a gradient of agreement). The team decides collectively how to best utilise its skills and respond to changes in the schedule.
John says:
With authority and control comes accountability. The team lead is held accountable for resource and schedule issues.
You don't want to control people, you want to
empower them. The team is
accountable for the project, and the team decides how to best utilise their skills and deploy people to get things done, and to deal with changes in the schedule. Each person is held
accountable by the team to the commitments they make and the actions they take.
John says:
The team lead can influence and negotiate scope changes with the customer proxy
The team is free to negotiate scope changes with the
Product Owner.
Tags:
self-organisation,
team,
leadership,
scrum
Links to this post
Obfuscated decision-making
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.
Tags:
organisation,
culture
Links to this post
Agroculture
Culture is a little like dropping an Alka-Seltzer into a glass-you don't see it, but somehow it does something - Hans Magnus Enzensberger
When a company wants to make lasting change, for whatever reason, it's usually not enough to change just the physical organisation. 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. It's too superficial. Issues that prompt a company to seek change are often thought to result from problems with the physical organisation, but they're more likely to be symptomatic of problems in the company's culture.
Changing culture isn't easy nor quick. It's bloody painful. It requires diligence, perseverance, passion and dogged determination. Are the improvements worth the effort and pain to bring about change? The hardest thing though is recognising the need to change the culture. And this comes down to awareness. You probably won't see much of this in large organisations.
Tags:
culture
Links to this post
Organisational 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.
Tags:
organisation,
culture
Links to this post
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.
Tags:
lean
Links to this post
