Mike Hill of Anarchy Creek presented a plenary talk at XP2005 that listed his top five FAQ's on the transition to XP. At number 2 was "We want XP. Where do we start?"
Mike listed his first 4 steps:
1. Get a leader to buy in.
2. Get a workspace.
3. Stabilize the build/integration/deployment process.
4. Learn to micro-test.
A key message in his talk was to "listen very closely".
It is really important to understand the problem you are trying to fix before applying a solution, such as XP. No matter how much an organization is sold on the idea XP, as a coach you need to be honest about the obstacles and make it clear if XP is not appropriate. No one will respect you if you ask people to blindly follow XP practices without using common sense.
Some examples I have encountered ...
Pair Programming probably will not work if developers in a team are working on a mixed stack and only have skills in one layer - such as AS400 or C++. You really cannot pick up a complex language like C++ by pair programming. You need to recognize personal development issues too, the team may resist diluting their specialist knowledge or being forced to learn another legacy technology.
Continuous Integration will not work if some code does not have source control and you have no idea what code has actually gone live so you have no environment like live to do Continuous Integration in.
Test Driven Development will not work if other teams working on a shared codebase are not bought into maintaining unit tests or caring if they are broken.
Refactoring will not work if developers do not have a good knowledge of Object-Oriented design.
Given the above situation, are there any XP practices that make sense? The subset of XP planning practices (iterations, standups and planning game) are derived from another agile method, Scrum, and can be applied on their own, just don't call it XP.
One technique that I borrowed from DSDM is the Suitability Filter. I call it an Agile Risk Assessment. You make a list of prerequisites for the method and check the status of these with the team before you start - you add these to the project Risks and Issues Log and then refer back to them if the organisation refuses to listen to your advice and then points the finger at you afterwards.
I am always amazed that when productivity improvements are sought that the first rule to be broken is usually Brook's Law ("Adding manpower to a late software project makes it later"). Get more people they cry! Swiftly followed by leaning on the team to do heroic hours. Not heeding the disruption as new team members add drag to the existing team with their questions and mistakes. The slow down of team meetings as the team bloats and team dynamics return to the Forming phase - see Tuckman's development stages. All these exacerbate a situation that is increasing in complexity due to more parallel development streams.
Alternatives to adding manpower are to trim scope by working out the Minimum Marketable Features or to bite the bullet and slow down to speed up by cleaning away the crud that the team wades through on a daily basis - automate tasks that take time and increase the chance of error - and question any over complicated architecture - do you really need EJB's for this?
I have also seen Brook's Law broken at a meta level, when new teams (or aquisitions) are added to a development organisation in a short space of time - perhaps this can work where they have separate concerns - but in most cases the holy grail of code reuse comes into the picture. Increased communication is not the sole limiting factor in such cases, constraints of extending the existing infrastructure may be overlooked. If teams are asked to share limited connections or integration platforms then collisions are inevitable causing slow down. Even if the addition of the extra folk do help you to get more code written, it is also likely to show up constraints downstream in the project cycle, especially where teams share specialists such as technical authors or security testers who can become overloaded.
Whilst browsing the net I came across an article by Jo Freeman
The Tyranny of Structurelessness about how the lack of explicit structures in feminist groups during the 70's obscured decision-making processes thus shielding manipulation by cliques.
This set me thinking about the amorphous structure of the eXtreme Tuesday Club - a club without formal membership that has met every week in London since 1999 and has run annual conferences for the last four years. I am not one of the founders of XTC but it was on my initiative we formalized the organization as a non-profit and opened a bank account to hold conference funds in 2002. Our wiki and weekly meetings are open to all-comers.
The other non-profit I help organize is the Agile Alliance, our structure is clearly defined; we have formal bylaws, an elected board of directors and we need a quorum to make decisions that are minuted. This can only work because we have a formal membership who can vote on changes.
XTC has no membership dues nor any listing of members other than what individuals choose to add to our wiki. The idea was to setup a way for developers interested in XP to meet over a beer and keep admin to a minimum. On paper the only members of the non-profit are the handful of bank signatories. Earlier this year we had some confusion because the DSDM consortium had taken a review by myself of DSDM v4.2 as an XTC endorsement - the wiki page The Nature of XTC helps to clarify this.
Given the above, I do hope that the XTC and XPDay conference organization is visible and open to people who want to get involved and not a clique as defined in "The Tyranny of Sructurelessness".
I have been working as an agile coach with one client for over a year but they never cease to surprise me.
When I opened their newly relauched IT intranet last week, I found that all the pages on on their agile software development process had been neatly swept under Coding Standards.
I also found a new mission statement (quoted below) that includes a rewrite of the Agile Manifesto without any mention on the page of the 'A' word!
Individuals and Interaction over Process and Tools
Amazing Development over Comprehensive Documentation
Partnership over Working to Contract
Response to Change over Following a Plan
Trust over Control
Responsiveness over Predictability
While there is value in the items on the right, we value those on the left more.
By removing any back reference to the original they have detached the values from the Principles behind it.
Hmm .. Amazing Development replaced by Working Software
Time to get my coat I think ;-)
I am interested in factors that impact the motivation of software development teams. According to Robert M. Pirsig in "Zen and the Art of Motorcycle Maintenance", our physic gasoline is Gumption, a reservoir of good spirits that can be added to or subtracted from. If you haven't got Gumption you might as well gather up all the other tools and put them away. He then explains that a Gumption Trap is anything that causes one to lose sight of quality and thus enthusiasm for what one is doing.
Mihalyi Csikszentmihalyi described a Flow state which characterizes a feeling of motivation. This state is achieved when a person is stretched by an activity but not overwhelmed by it. To achieve this state you work towards a goal using rule-bound action steps that providing you with feedback. In flow, one's concentration is so focused that there is no attention left to think about irrelevant concerns or problems. Self-consciousness tends to disappear and you lose track of time. Gumption traps prevent you getting into Flow by distorting or delaying the feedback process.
One of the principles of the Agile Manifesto is "At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly." In team retrospective sessions, you can use Systems Thinking tools to help identfy Gumption Traps and analyze possible solutions.
Ivan Moore and I are running a workshop on this topic at OOPSLA in Vancouver. This builds on a simlar workshop run last year at XPDay Benelux.
At Agile Development 2004, I attended an excellent tutorial presented by Jeff Patton on Interaction Design Meets Agility. The tutorial was run as a workshop where we learned how to use of techniques from Constantine and Lockwood's Usage Centred Design to determine a release plan.
XP has no explicit practices to help the on-site customer come up with an adequate set of stories for release planning. This workshop technique appears to be a neat way to uncover stories for types of users that may otherwise get over-looked (often times maintenance or customer support users can get left out of the picture). It may also prove useful to determine a persona per key user to use in Soap Opera Testing - heard about at Agile Development 2004 in a tutorial on "Exploratory Testing" presented by Elisabeth Hendrickson and Brian Marick.
Jeff Patton has a new yahoo list on Agile Usability for discussion on where usability fits in an agile software development cycle.