My last post covered the rationale behind our team at an investment bank wanting to make a switch to Clojure from Java. I want to write in this post about how we were supported in our efforts by those at the bank.
Aircover from Within
First not all the team jumped in at once to use Clojure. We created what we called a ‘pod’ within our team. Invitation to the pod was extended to all but to join you had to get the Emacs/Swank/Lein environment setup working first by reading our projects github README page. People joined the pod at varying times with their own personal approach. I.e. some devs wanted some space to try out their own thing in the Clojure codebase whilst others wanted to pair up. Some devs wanted to install the very latest version of Emacs themselves and understand all of our Emacs config whilst others took a more direct route through to the code. At one point we had an Emacs versioning arms race of which I dropped out.
Some of the team didn’t join the pod initially and stayed back to provide air-cover to those within the pod. For the system we had to maintain/develop they stepped up to satisfy whatever business requirements came our way as well as handling any emergent technical problems. Gratitude is owed and deserved.
Technical Leadership Vs Bottom Up, Organic Adoption
I’ve heard of a case at a different investment bank of someone fairly senior decreeing that development going forward needs to be done using Clojure (I disclose now that I don’t have all the facts). I’m not sure how I feel about the idea of this. On the one had it feels good that someone high up has got a kick-ass mentality to drag up the quality of the tools that people in the trenches are using to eliminate waste and to speed up development. On the other hand I can see some people getting frustrated – i.e. not everyone wants to get bloody on the cutting edge and to call themselves Lisp hackers, having to revert from the cosy wizardry of professional refactoring powerhouse tools like Eclipse/Intellji to having to use Emacs or Vim, tools of old.
Changing from a statically typed OO language to a dynamically typed FP one is a fundamental change requiring lots of organic support and I’d be interested to hear if it can be forced or not. Maybe it can be. Maybe this is good. There’s also still immaturity around the Clojure tools ecosystem to grapple with. Nrepl is replacing Swank-Clojure, Lein 2 is about to be released which is a major upgrade. Although you can get copious amounts done using Clojure one has to say that the ground still has the occasional tremor and this may affect bringing onboard the masses. I would expect that there is lots of devil in the detail around Clojure mass adoption.
At our bank we were given some room and trust to take technical decisions so long as our cost/benefit case was solid. It felt right for our team at the time to start using Clojure – we were not instructed to do so.
Support from the Business
The Business were typically not as patiently supportive as our technical stakeholders. However pleasant our business customers are there’s always an element of ‘why we have got X amount of the team diverted away from serving the direct requirements of the business to do tech stuff?’
It may sound obvious but the only effective way I’ve found to deal with this is get a synergy between the ‘tech stuff’ and needs of the business as soon as is reasonable. Our pod of Clojure devs made a switch from straightforward 100% reengineering to doing a mixed blend of new requirements for the business too. Now the business are happier and we get some relief. Since development is more productive around our new infrastructure we can turn around long standing requirements for them faster and it’s fun to do. They will reap the rewards from here on in.
This does however mean that we’ve increased the amount of work we’ve signed up for and overall pressure on ourselves, this has affected our morale. We are currently sailing quite close to the wind with anti-patterns ‘scope creep’ and even at times ‘death march’ hovering. There’s no doubt that we’ve had our share of stresses and that there are more to come. I can though take some comfort that with hindsight the thought of sticking with the old status quo of a monolithic Java app does not become any more appealing. Eventually the waste will crush no matter what the resources of an institution.
Notes: 1) I wrote this post a year ago before I mothballed this blog site and lost my domain name. I’m not really wanting to get back blogging often but I have a couple of things I want to write about in the medium term. 2) Ironically the team I’m presently on and the one I used for the basis of this post has drifted into a non-sustainable tactical mode that isn’t enormously self-organised – I talk about this at the end.
I’ve written a couple of posts on Self Organising Vs Managed teams in the past. Over the last year I’ve had the good fortune to work on a team that is predominately self-organising, and wanted to write up the main learning points that stick out. I’ve written this from the perspective of facilitating a self organising team. This is also against a backdrop where a dev team has a high degree of ownership over its codebase, and is of a small to medium size (around 10-12 people). If the conditions aren’t right to begin with, then it often doesn’t matter if a team is self-organising or not.
Organising Self Organisation?
The first sub-topic to address is the meta. That is of how much should you organise a ‘self organising’ team. I once worked on a team where the PMs thought that a strong dev team would somehow ‘grow’ out of the various developers they had scattered around a room. Like monkeys and typewriters.
And of-course it really didn’t work. Deadlines missed, low morale, software written to a dubious and inconsistent standard. I’m sure the project managers who were there at the time would now say that the project was successful and use it as a highlight for their careers, but the fact is that the whole thing sucked massively, almost comically so.
Staying with monkeys and typewriters, of course if you have the right monkeys then they should be allowed to crack on and solve the problem they are there to solve. But where this works there is usually some kind of organisation in place, no matter how subtle and transparent it may be, and we’re talking about a team consisting of seriously good monkeys. A rarity.
I know that on the face of it the idea of organising a self-organising team sounds contradictory, that a self-organising team should surely lack any sort of dictatorial or outside behavorial influence. But I do think that there needs to be some founding principles at work. Just like tolerance needs intolerance of intolerance, I think a self-organising team needs some organising to be self organising.
I’m not someone who has reservoirs of faith and patience for being able to work with just any plucked-out-the-ether developer. And if I’m honest this was one of the hardest things about being a consultant, because that’s exactly what’s expected of you. I’ve worked with many developers who simply just shouldn’t be developers. I’ve been on projects where I’ve spent most of my time refactoring and deleting code written by others and just hoping that I’m going faster than they are as to have some kind of net benefit.
The reality is that if you are tasked with running a team and you want it to be a ‘strong’ team, then you really need to ability to hire and fire. You need to be able to populate the team with the best people that you can get your hands on. If you don’t have this level of responsibility and you’re told just to suck it up and work with whoever, then you’re really up against it. In a team you need leaders and people with exemplary skills that inspire others to up their own skill-sets and abilities; everyone working together to help each other along. You also need people that are fun too, and everybody in the team needs to be generally easy to get on with.
Challenges I’ve faced include having to convince business stakeholders that developers are not a commodity that can be easily swapped in and out. It’s a battle that’s never really won as stakeholders come and go, and usually they never lack conviction in their own opinions. Talking in terms of objective evidence and waste/risk helps, and this is where a team facilitator can play a useful role. Another challenge is making sure that inevitable attrition is mitigated, however tough it may be to do so.
It just so happens that if you’re tasked with facilitating a team populated with bright, good people, then you’ll probably find that for any given job they’ll be someone on the team who is better at doing it than you, or more likely, has the drive to do it.
I’m consistently and pleasantly surprised by the varied skill-sets of those around me. There are people with quite finely-grained nitty-gritty problem solving skills, then there are others who possess a natually gifted systems-overview way of thinking. There are those adept at getting close to the business and understanding their wants and needs, and conversely there are those who see the business as dark hooded figures, whispering and scheming on the sidelines.
The point is that when working with creative, intelligent people, then the job title changes from that of leadership to facilitation. I’ve little doubt that certain circumstances call for the type of robust expletive laden leadership offered by Gordon Ramsay in his kitchen, but where there are highly skilled people involved such as in the software delivery industry, then this approach doesn’t really work. You let people who are able to solve complex problems get on and solve them. As a facilitator your job is to help make that happen by mostly getting out of the way, or to muck in and help if your contribution as a task-executor is useful.
I’ve worked on a team where the facilitator wasn’t a Gordon Ramsey, but was instead a wannabe primary school teacher. ‘Have you written a FIT test?’ That’s good. ‘Have you you asked the BA about the requirement before starting work?’ Ha-ha! Just checking. It makes you want to just tell someone like this to get out of your face and to basically fuck off.
I think as a team faciliator you need to be able to trust someone to do a job. But admittedly there are subtleties. Knowing who has the relevant skills for a particular problem helps, and trying to avoid the situation where only he/she can do a certain job also helps. Some people enjoy taking on responsibility and a degree of accountability, others would rather get on and code. Making suggestions about what certain people could work on if they wanted to is not an altogether bad idea.
You need a ‘mouthy team’. The Agile stuff of retrospectives helps, and perhaps more so does the location of the office-place with respect to nearest agreeable pub. Really though, it comes back to having good people in the team. The team needs people who can challenge ideas and practices, to offer an opposing way of doing things that works.
You then also need people who can take critism, including yourself. Team members need to be able to watch other team members piss all over their best and brightest ideas. Not everyone is tactful about it – we are geeks after all. If instead you want people who’ll always listen attentively with words of support, then you can always hire consultants.
Sometimes a decision does need making, particularly in murky waters where there is much contention. In this case it’s about getting buy-in from the team and choosing a direction people are happy with, even if people acknowledge that there’s an element of gambling. I’ve read that this is a drawback of self-organising teams – inertia of making strategic choices – but I’ve rarely encountered a situation where competing views jostle against each other and logic doesn’t win out to pick a solution. If you have personalities in the team that stick to a position and refuse to budge despite logic and evidence… then either feedback needs to be given or the topic of ‘hiring and firing’ needs to be revisited.
Energy is something a team facilitator can bring to the table. Whether it’s keeping a stand-up on a Monday morning upbeat, organising team lunches, or encouraging brown bag sessions and tech talks. The facilitator may not be the person that comes up with the idea of a particular technical talking session, but they should be able to make it happen if someone feels it’s important. The facilitator should also be able to cope with the more mundane stuff that needs doing. Someone needs to plan meetings such as iteration planning meetings, kick-offs and retrospectives. Some of this can be delegated to those that enjoy this kind of stuff, but it needs taking care of. Some are better at this than others.
You need a good manager to give the team some space by which it can become encapsulated and be to judged on its results. The team must also be supported in the occasional battle (i.e. the prioritisation of technical platform work over business requirements is a popular one). At the same time managers must resist from standing completely back and allowing teams to self-organise themselves to effective failure. There is also people rotation to think about – why should one team have a set a talented people in contrast to other teams, shouldn’t they be shared around? Spare a thought for the beleaguered manager, his/her job is never easy.
It’s not a religion.
As I said in the notes at the top, the team I’m currently in and had in mind when I wrote this post has drifted away from being self-organising, and has gone into more of a non-sustainable tactical way of working. If people are happy to, when you’ll attempting to climb over a large challenge then sometimes you have to tolerate silos and to ask people to stay in particular work-streams for a short duration. It’s not ideal and you need the backing of the team to do this, but sometimes going tactical to get shit done can be fun too. The trick that we haven’t attempted yet is to crawl back.
This is a post about the practice of risk management through use of a ‘DEFCON Door’.
A DEFCON door? Well if you’ve seen that early 80′s film ‘WarGames’ starring Matthew Broderick, or if you simply know your US history, then you’d know that DEFCONs – Defense Readiness Conditions – are used to be a “measure of the activation and readiness level of the US armed forces” (as described on wikipedia). During the Cuban missile crisis DEFCON 2 was reached, with the US airforce readied up to go and bomb their cold-war rival the USSR.
And how might this be applicable to your typical day-to-day IT project? For starters, once on a project what we did was to find a spare door and to configure it as such:
It’s very simple really. Along the top column headers are the various DEFCONs. DEFCON 1 would mean that it is the consensus of the team that the project is going to fail because of a particular issue; that a very serious risk has indeed materialized. DEFCON 2 risks are still very serious, and DEFCON 3 ones are merely lesser risks that the team feel are important enough to warrant exposure at a particular given time.
What I found most pleasing about the DEFCON door was that it seemed to be a fairly natural extension of the Agile software development practice and was therefore well-adopted by individuals on the project. For instance in a similar way to how we do story estimation a person would read out a ‘risk card’ and then the team would count to three and display with a finger count the the DECON level that they thought the risk had reached. No fingers at all meant that the risk could simply drop off the door altogether – which ought to be a good thing.
Normally every couple of days or so after the standup we would do a quick review of the door. Sometimes, we also did it after a retrospective, because a few things that had been brought up were indeed risks that the team thought were ‘DEFCON appropriate’.
Risks would sometimes traverse up and down through the DEFCONs as the team would attempt to grapple with them, and often risks would be broken up into multiple risks, or instead merged together to form all encompassing ones. No one team member should own the door as it works very well as a collaborative tool where everyone can have input.
Thoughts on effectiveness:
I think often individuals within a team will have very real concerns about some particulars of a project. Personally speaking, one of the wants that I have when I have such concerns is that my concerns will be listened to and registered by the team, and I think the DEFCON door to an extent gives you that.
It also brings the team closer to the risk tracking that would ordinarily be done by project-managers. Although I don’t think it should be a replacement as it best works as a lightweight tool, there’s real value in having team-members contributing to tackling and identifying risks on a day-in, day-out basis.
The DEFCON door also has uses outside the immediate vicinity of the team, such as the ability to show project stakeholders the door and say “these are the major risks that the team feels are present right now”. Often stakeholders not operating within the team will have a want to gauge a collective opinion about how the project is going and the challenges that are being faced. Here the door can play a useful role.
Firstly, it sometimes can be difficult to locate a usable door, especially a nice wooden one. If need be you could use a wall, but then you’d be harming the linguistically pleasing flow of the “DEFCON Door”. It is however, really up to you.
Understanding what the scope is of the door can be at times slightly difficult. For example it can be tempting at times to throw up enterprise-wise risks up on the door that are not directly project-related (e.g. is this architecture appropriate for adoption by the wider organization?). A strategy a colleague of mine came up with is to have a DEFCON corridor, but I fear this may be over-egging the solution. I would endeavor to keep the door simplistic, and if the door identifies risks and questions to be managed elsewhere then that can only be a good thing.
We should also note that this model of risk management is very lightweight and simple, and that there is much more about risks than can easily tracked and measured on the door. Therefore it would seem appropriate to use it to augment a more sophisticated risk management process.
In conclusion, the DEFCON door is a simple tool that aims to bring risks explicitly into the highly visible and participatory realm of an empowered, self-organising Agile team.