Paul Hammant's Blog: My ThoughtWorks 'Sweetspot' Venn Diagram
A previous client recently stated an affinity to a model I was using then to describe ThoughtWorks’ project teams at client sites. I thought I’d make a blog entry of it, as we are presently migrating wiki tools internally, and who knows what can happen.
Note: the diagram/model below has never been approved by TW management, but its how I see us at some client sites , and it has been popularly received by clients in the past :)
Explanation
For most missions, ThoughtWorks staff come on to the client’s site for a period of months. We’re going to do four things together:
1. Tech improvements.
Technology : Take bad Java and make good Java applications. Ditto for .Net solutions, or Rails visions from legacy hairballs.
Technique : Introduce or perfect design patterns usage, IoC, Continuous Integration, Trunk-Based Development, Continuous Delivery, automated functional testing (etc). All these get better as the TW staff influence the project.
Of course some clients are already in the perfect technology place.
2. Agile Processes.
We’re known as an Agile company. It was quite convenient some ten years ago to be in a place where competing consultancies were rubbishing Agile. They have one by one changed their message from anti-Agile to pro over the years. All along we have stuck with our pro-Agile agenda, sometime introducing practices (Behavior Driven Development), or being prominent amongst proponents of a practice such as Continuous Integration, Dependency Injection. Yes, there is some overlap with technique above.
ThoughtWorkers at a client site are going to want to do as many Agile methodology practices as possible; Most likely something closer to Extreme Programming than Scrum (although we do Scrum too).
3. Co-Sourcing.
This is where the client’s developers are mixed with ThoughtWorks developers (and BAs, QAs etc) for the same project. Obviously with pair-programming, a ThoughtWorkers dev is going to be working directly with the client developer often.
4. Bar Lifting.
This is easier to setup and somewhat orthogonal to the main development effort. Sooner or later the client is going to need to hire more staff for the project. Either because it is big, or because ThoughtWorkers are rolling off, or working towards an imminent end date. We help them get better at recruitment for those positions. Often we are overhauling the interview process by introducing a simple to administer technical test that is given before the face to face interview.
Some clients are pretty good with the skills level already and don’t need the help. Some just have outliers that are ‘below the bar’, and helping with interview practice and tests was something they could have done themselves.
We’re also going to help the client’s incumbent staff move to better coding practice; Through osmosis, ‘lunch-n-learns’, etc.
The four in Balance
When all of these things are in balance, you end up with one of those missions that all the participants remember fondly years later. “Ah, those were the days…”
The four out of balance
Less Co-Sourcing?
That means we have coaches in smaller number trying to figuratively advise client over their shoulders staff on how to apply better patterns and practice. That or the client’s staff are missing from the project, and ThoughtWorkers are going to do it on their own. There is no-one to teach in that case, and ThoughtWorkers don’t get to make the lasting friendships.
No Agile Transformation?
Hmm. This one will hurt. The client loves TW, but wants us to do it the formal Waterfall way, or has is chasing a Watergile idea.
Sometimes they have looked at the Agile way that we’re prescribing and seeing “efficiencies” to be made, and suggest them through ThoughtWorks management.
This will lead to unhappy ThoughtWorkers as well as a costlier and lengthier build-out. There are other risks that Waterfall brings too (read about that elsewhere).
No technology improvements?
You want us to do Cobol? Great <forced smile/> we get a chance to write another “Cobol-unit” and open source that (with your permission), but it is going to be painful, and slow going.
No Bar lifting?
Disclaimer: Most of the time the client developers are just fine, and love their time with ThoughtWorks on-site.
In the worst case, the clients staff are happy not learning anything new about technology, and technique. We want to teach (and to learn), meaning those missions are going to have unhappy ThoughtWorkers. Put it another way Steve Jobs says: “A players hire A players, B players hire C players”. This has been written about a few times, but perhaps Guy Kawasaki is the most lauded witness to it, and can give the best explanation . I like to remember that B players also (typically) reject A players. The worst of these teams seem self-repairing back to B/C level.
This as part of a Programme?
(please excuse the jump to British English. I want to differentiate from ‘program’ - the bits of code we write in software-land)
If the client is big enough, they may have many projects running concurrently, with an expectation to finish some of them soon, and to spin up others shortly. In this case there is need for a programme team. This is something that’s quite small - a programme manager, an Agile coach, a technical architect and a technical author. The last role there is to socialize successes, because there’s going to be the occasional backlash; Or more positively, opportunities to showcase things to new groups within the organization. Responsibilities involve prioritizing the stream of forthcoming projects, fine tuning individual project teams, and alike.