My work, coaching teams in agile software development, regularly places me in the midst of organisational change. Sometimes I am brought in by management implementing top-down change and other times by a tech lead attempting bottom-up change. It is completely normal for people to resist change, any change carries a risk that it will make life worse rather than better. The most resistant are those whose power is threatened by change. Others may are confused about the reasons for change and doubt the benefits. The Satir Change Model is useful in understanding how we react to change.
Not surprisingly, as someone supporting a change I sometimes get caught in the middle, where management desire change but the subjects of the change have a vested interest in the status quo and dig their heels in. People need both the incentive and the capacity to change. When these factors are not addressed I have ended up in some to frustrating situations, where my advice is not followed or I get frozen out by the team I am engaged to coach.
Some scenarios I have encountered:
Not enough time. People have such heavy workloads that although they know I will be in the office, they will only be able to spend an hour or so talking to me and no time at all implementing any change. Where management is driving change, they need to ensure that the people subject to new working practices are given enough time to learn new techniques and adjust their working practice. It is likely that there will be a slowdown in productivity. It may help to slow down the pace of change and set more realistic goals.
Inappropriate change. Sometimes the sponsor of a change has identified a solution "we want to go agile" or "we need XP" rather than identifying the problem and desired outcome. It is important to check if the chosen solution is a good fit for the context. There may be more basic problems to solve, such as implementing software version control.
Lack of management. I arrive at 9am on Monday to find no developers are in the office - the team is made up of contractors who work half days at the start and end of the week and 10+ hour days in between. I show up for a meeting with their manager who is double-booked and has forgotten our appointment. Code is not checked into version control for months at a time.
So how do I deal with the situation where I am paid to coach but barriers prevent me engaging with the development team?
My first step is to identify and sell the problem. Do people understand why change is needed? To do this I take time to listen, talk through the concerns of each member of the team. It is important to understand the context and the systemic causes of the problem before making recommendations.
Next, I offer alternative strategies to resolve the problem. It is important that the team participate in decision making and are offered choices of approach.
At regular intervals review the approach, remind the team that they still have choices and discuss the consequences of incongruent actions. When things do not go to plan try to understand the root causes.
The way I interpret the coach role is that I am there to teach not coerce [there should be no need for a rolled up newspaper]. I do not take on any specific process responsibilities other that to facilitate the implementation of agile development practices and to make observations. If I take on a task for the team (such as tracking velocity or pinning up stories after the planning game) when I leave this task is likely to lack an owner. The same goes for removing obstacles, I work with the team to remove obstacles rather than doing this by myself because that way the team developers a greater sense of ownership.
It is essential to maintain your integrity, stay honest and endeavour to respect everyone involved. You are not infallible so admit it if you don't have a stock answer, a sense of humour helps.
Remember that you have a responsibility to your sponsor. Keep them briefed on progress and barriers you encounter without cover-ups or attributing blame. Explain how they can help accelerate the change.
You are being paid to coach so keep trying - don't give up! Be assertive - keep trying to engage with the team and don't take failure to reach people personally. It's the change they are resisting not you. By persevering and working at the team's pace you can hope to achieve small successes every day.
Here's a write-up of a conversation at Extreme Tuesday Club last night triggered by Allan Kelly. The question Allan posed is How should an XP team handle technical analysis activity?
In any project there are likely to be some stories that are presented by your customer that you do not understand how to deliver without some investigation. Sometimes these stories involve dealing with new architecture and sometimes they involved delving into an existing legacy system to understand it's workings. It is clear that you cannot estimate these stories the same way as ordinary stories because they are outside your experience. Although a developer could give a guess-timate based on some past experience sometimes you may not have comparable experience. Using guesswork to produce estimates will pretty soon affect your team velocity and thus become usless in helping to predict how many features you can deliver in your weekly cycle.
If you cannot estimate a story without some investigation then declare this. Sometimes all that is required is half an hour to step outside the Planning Game to look at the code before you can give a better estimate. Other times you may need to ask your customer for some iteration time to do a more thorough investigation. In XP, such investigations are called Spikes.
The way I prefer to manage spikes that take up iteration time is to create a time-boxed Spike story. Spike stories do not deliver code but instead deliver estimates for a refined Delivery story.
Delivery stories implement a feature that passes customer acceptance tests. You can estimate these because you know the codebase and how to implement the new behaviour. You can get this understanding by completing a Spike.
So we have two types of stories - Delivery stories and Spike stories. This way you can scope an iteration taking spike work into consideration, tracking completed spikes the same way as delivery stories, both contributing to your team velocity.
An alternative to spiking within the iteration is to spike between iterations - this disrupts the team cycle and only really makes sense if you have many spike stories enough to keep the whole team busy spiking.
Another scenario I have encountered is where an organisation out-sources a project. None of the new developers know the codebase so they are not in a position to estimate any stories at the Planning Game. Planning a first iteration comprised mainly of spikes is a way to get the team in a position that in subsequent planning sessions they can give estimates with confidence.
I stumbled across an article by Malcom Galdwell entitled Personality Plus. This article suggests that Myers-Briggs is somewhat undermined by Walter Mischel's resreach showing personality depends on context. When I took MBTI, I got the impression that context is recognised by those qualified to apply the instrument. Some information is included with your results on how you may flip to other behaviours in different contexts - such as in situations of increased stress.
What I found interesting in Gladwell's article, was the idea that MBTI is an example of an indirect way of assessing personality and that if we were to take personality assessment seriously we should consider a direct approach. Testing out behavour in real contexts. You can take a step towards this by using simulated situations that may provide some useful feedback on personality.
What many XP teams do as part of their recruitment process is to invite candidates in to pair with the team on production code. This gives the team a chance to get a feel for the candidates personality and skills in a real context. A weakness in this approach is that the team may prefer candidates with a similar personality to themselves. Building up a self-selected team may lead to a lower level of conflict, as a team with the same interaction preferences may homongenize well. However, there are some down sides to this too. A team that is close-knit may have a tendency to be blinkered in approach and develop groupthink tendencies disrespecting the needs of others within the same organisation.
Although differences in personality may occaisionally create more conflict, a healthy team culture will make the team more versatile in different situations. So some awareness of the strengths of different personality types may enhance your recuitment process.
At XPDay4 , John Birtley and Hubert Matthews presented an interesting session on Agile Deployment. They recommend that teams should develop a set of environment tests for each application to verify the environment configuration is appropriate before deployment. This practice can help if you deploy to a production environment that is maintained by another team. Handover the environment tests with your application and if problems are reported about your application this will give you a way of making sure that the required permissions, libraries, file srtuctures are all in place before you assume responsibility for the defect.
Investing in environment tests may actually go a small way to reducing the amount of error handling code in your application.
Other advice in the talk was to automate as much as you can in your deployment process and try to match your development environment with production environment as close as possible. Frequent deployment helps to get the wrinkles out by cranking thru the process often.
The keynote for XPDay4 was Dave Snowden ex-IBM, former director of the Institute for Knowledge Management and founder of the Cynefin Centre. He introduced us to Cynefin, a welsh word that roughly translates to "multiple places of belonging". Cynefin is a framework for Sense-making uncovering Networks via Narrative techniques - for an introduction see this paper.
Both the talk and afternoon masterclass gave some insights into how narrative techniques can be used to break thru or leverage our natural pattern matching. Cynefin provides ways to categorize domains as order, complex and chaos thus helping to identify how to create a phase shift from one to another.
In my work as an agile coach I am often landed in organizations where I need to get to understand values and power structures quickly, it seems that Cynefin is worth further investigation.