Light Touch Agile Coaching in the Cornish Software Mines
Join the DZone community and get the full member experience.Join For Free
Under the auspicious of Grow Cornwall I have been in providing Agile coaching to several companies as part of an Agile programme designed to bring better development practices to multiple companies. To date six companies have been part of the programme to some degree and next week we are adding some more.
In the next few months I hope more of this work will come into the public domain as articles and case studies. There are even plans to hold an Agile conference in Falmouth, to be named Agile on the Beach. (More to follow soon.)
This engagement has really given me a chance to think about my coaching style and develop some techniques and approaches which I’ve thought about in the past but not really codified. One of these I call Light Touch Agile Coaching.
Many description of Agile Coaching assume a full time coach. Scrum specifically just about mandates a full time Scrum Master for each time. The Scrum Master is closest Scrum gets to an Agile Coach, indeed, some people would see them as the same thing. I don’t, and thats worth a full article in its own right but not today.
In Cornwall there are three companies I’ve be working with more than others and a clear pattern to the work has emerged. It goes something like this:
- Companies joining the programme receive a training course over two days, preferably offsite. This has worked best when the net is spread wide and the whole development team and managers are involved.
- The team are allowed a little time to digest this then asked: do you still want to try Agile? The programme is designed with the expectation that they say Yes, in which case the coaching begins. If they say No then fair enough, its is there decision.
- I visit once a month, I spend between half a day and two days with the team. How much time I spend depends on the size of the team and the company, how long I have been working with them, and the particular set of problems they are faced with.
- My visit usually starts with an inspection of the white board - call it a Kanban board or an Information Radiator if you prefer - its the board with all the work on it.
- I read the board, I ask question, I get asked questions, I understand the state of play and get an idea on what needs addressing.
- Sometimes, some places, I sit down with a manager and talk about the last month. What has happened, what progress they have made, what understandings they have reached, what has puzzled them, how the team have performed, and so on.
- Next I sit down with the development team and conduct a similar type of exercise. Sometimes the teams have conducted their own retrospective and I review that, other times this exercise takes on elements of a retrospective.
- (One of my challenges is to make all the teams proficient with retrospectives so when my work is finished they can continue themselves.)
- In some companies I sit with the marketing group for a conversation too. All the companies I’m working with develop software for external customers and some of them have marketing teams. As the development teams have become more effective a lot of my focus has shifted to marrying up marketing with development so the right thing gets built.
- During the course of these meetings I start to construct a list of “Expected next time”: things they managers and teams tell me they will change, or things they will put in place for my next visit. Naturally, as a I talk to people I’m also looking through the last “Expected next time” list and seeing how the team have done.
- I started doing the “Next time” list for my own benefit but I’m open about it with the teams and it has become a useful little tool in both tracking whats changing and getting commitment form the teams.
While I’ve concentrated on Agile processes and management (both product and more company) coaching we have also introduced more technical coaching. Jon Jagger and Nancy Van Schooenderwoert have helped out here. They have taken a similar light touch approach. In Jon’s case he normally spends his time pairing with the developers on his visit while Nancy works remotely.
There are some variations to the approach outlined above, things haven’t always gone smoothly and one company dropped out of the programme right after the training. But, on the whole it is working and working well.
Some successes to date:
- One company develops a software product for doctors, they recently received ISO-13485 using an Agile process I helped them develop. ISO-13485, for those who don’t know, is a standard based on ISO-9000 which certifies a company to create medical devices.
- The day after completing TDD training with Jon Jagger one team wrote a unit test which found a bug in their live system.
- One manager when asked “So this estimation process and charts are more accurate than the way you used to do it?” replied “This isn’t estimation, that is Mystic Meg stuff, this is science, I know when we will deliver.”
- By adopting Agile one company has won, and is successfully working on, a new website for one of the worlds largest telecom’s companies. The same company has now spawned a spin-off which is born Agile and will work with the same telco in a contract worth over a quarter of a million pounds.
- The three companies I am working with have all been strong enough to hire new staff in this year.
Published at DZone with permission of Allan Kelly, DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.