07.07.12
Posted in Clojure, Java
at 4:55 am
I needed this the other day and wondered if it would help others or if there’s a better way.
There are two functions. The first goes looking for a key anywhere in a map and produces a sequence of key-paths that can be used with get-in, update-in and assoc-in. Note this code only recurses into substructures that are vectors or maps.
(defn find-key [ks k m]
(cond (map? m)
(reduce into (map (partial conj ks) (filter #{k} (keys m)))
(map #(find-key (conj ks (key %)) k (val %)) m))
(vector? m)
(reduce into '() (map #(find-key (conj ks %1) k %2)
(iterate inc 0) m))))
The deep-update-in uses the above:
(defn deep-update-in [m k f]
(reduce #(update-in %1 %2 f) m (find-key [] k m)))
m is the map, k the leaf key you're looking for (a single key, not a path of keys), and f the function you want to do the update.
Permalink
04.26.12
Posted in General, Java, Uncategorized
at 7:32 am
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.
Good People
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.
Empowering (Delegation)
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.
Mouthy Team
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
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.
Management Support
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.
Permalink
11.01.09
Posted in General, Java
at 8:13 am
Update: Very annoyingly ThoughtWorks redid their website and my whitepaper and those of others were removed. Here it is.
I recently wrote a white paper and it has been added to the ThoughtWorks collection of white papers here: http://www.thoughtworks.co.uk/what-we-say/white-papers.html.
After having been involved in a few projects whereupon the client has a need to modernise an ageing technology stack, I thought I’d pull together from these experiences (and from those of some helpful colleagues) and do a write-up.
Here’s the abstract:
“Gartner makes the prediction that by the end of 2010 ‘more than one-third of all application projects will be driven by the need to deal with technology or skills obsolescence’. The process of refreshing technology platforms – Modernisation – is one that is fraught with risk. From spiralling complexity to software development teams losing business focus, there is ample opportunity for a modernisation agenda to fail.
This paper has been written for the non-technically minded business and information stakeholder without prior knowledge of Agile. It looks at using principles and practices originating from the Agile philosophy for mitigating the modernisation process.”
The actual PDF can be downloaded here: http://www.thoughtworks.co.uk/pdfs/agile-modernisation.pdf
Thanks to Liv Wild and Simon Brunning for peer reviewing, and to Davie Moston and Gaurav Sood for giving me feedback on its various incarnations and iterations.
Permalink
07.28.09
Posted in General, Java, Uncategorized
at 4:40 am
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.
Potential Challenges:
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.
Permalink
07.18.09
Posted in General, Java
at 12:41 pm
A post I wrote three years ago but never published, I was pissed off back then after a couple of lousy gigs in a row. This was me coming out of the bright eyed Agile love affair mentality a lot consultants have.
Looking around the IT industry at the moment (or rather the microcosms of it that I’ve had exposure to), I’ve begun to develop an unfortunate degree of cynicism about the widespread adoption of Agile.
Currently there are people making claims that Agile has finally passed the chasm; that light has indeed been shone upon the masses. The more cooler of kids will of course have moved on to pioneering something else (maybe Lean), but Agile generally is where it’s all at. If you’re a conservative CIO waiting for something to come out of beta, then the wait with Agile is over.
But – and the more cynical than I would have clearly foreseen this – this widespread adoption is going awry. Namely, that when Agile techniques are ‘leveraged’ in the way that traditional software processes are, the sort of problems that those in position of management thought they’d seen the back of come back to bite, and harder. Problems such as low morale, lack of individual ownership, late delivery and runaway budgets.
Modern Agile methodologies (XP, Scrum) do indeed tend to offer a higher degree of transparency. But transparency itself invites meddling from those able to manipulate the process. Readily availability of metrics such as ‘velocity’ measurements essentially provide the grounds for managers to increase the amount of management. Metrics allows for targets to be set, and for endless tinkering to ensure that the targets are reached. The trust engendered to individuals to do the best job they can is lost when sophisticated charts come into play.
This is at the root my concern. That the previously existing command-and-control, blame-assigning culture of IT organizations simply carries on under a new fashionable look. In fact one might postulate that since Agile facilitates broader intervention at the various stages of software development, then Agile can actually increase the amount of bureaucracy directed at a development team.
And we must ask the question of ‘is this really such a bad thing?’, and am I just blowing this way out of proportion? We surely ought to welcome transparency and the safety nets that Agile practices layer into software development… Aren’t I sounding like the developer who wants everything his own way (perhaps) against the grain of the greater good?
Software is not simple brick laying. You can’t, as much as you might want to, trivialise it to the extent of paying a load of hot-swappable monkeys to write sonnets. Writing software is challengingly complex and has an infinitely diverse problem set. The solution requires innovation and that clever thinkers are given the time and space to follow their best judgment.
I have an inkling that some might feel I’m being somewhat unfair to the understanding of what Agile is really all about. Agile is simply a philosophy after all with axioms such as ‘people over process’ and ‘working software over comprehensive documentation’. The Agile manifesto itself doesn’t directly dictate how a software project should be done.
Well yes this is true. But then this is the difference between what an innovative approach is meant to be used for, and of what the collective wisdom of the masses decide it’s to be used for.
Without a deeper understanding of what a methodology is all about – or the bother to discover what it’s all about – managers will seek to use popularised yet blunt ‘Agile’ techniques to manage more, and then the whole ideal of empowered individuals/teams comes second or third. At worse the adoption of Agile simply becomes a guise for management by checkboxes. Got pairing? Tick. Got ‘stories’ in place? Tick. Got iterations? Tick. Not quite working? Oh well, let’s adjust the amount of pairs in team X, change working hours, assign workers to particular areas…
The lack of the masses understanding what Agile is all about is its downside.
Permalink
06.14.09
Posted in General
at 1:31 pm
This summer the Pither family set off for a week’s vacation in Burgundy, France. This was despite a warning in one of my wife’s baby books “The Yummy Mummy’s Survival Guide”, that a holiday with a new-born is not actually a holiday, it’s just the simple feat of surviving in a different location for a while. In fact it mentions that being able to come back without filing for a divorce or equip with five different foreign illnesses should be the level of expectation-setting.
But one of the reasons that we chose Burgundy was that we’ve been there before and we know what we’re up against. Specifically, we’ve been to the same gite. It’s a lovely place that was renovated from being a ruin by the most dedicated of hosts. It’s quiet, the quality of the finish of the individual apartments are superb, and it now has a swimming pool. Excellent.
We wasted no time in hitting the Saturday market at Avallon, around 10 miles away (we organised the trip to cover market days at nearby towns). Here we got some cheese, vegetables, pies, nibbles, pate, ham, herbs… all loads of good stuff. And we wasted no time in getting down to business in the consumption of said perishables.
The cheese by the end of trip was so well developed that it was enquiring as to my views on the MPs expenses crisis. Speaking of cheese, looks like Lily also has a bit of a taste for it:
This was at a restaurant in Ladoix, a village on the revered Cote D’Or; a Burgundian wine region. We went to this particular restaurant having been before we because we knew it would be reasonably priced, and the food and wine excellent. It didn’t disapoint. Have a gander at my Oeufs en meurette (eggs in a red wine sauce), I’m sure you’ll agree it’s pretty serious stuff:
This was just a starter. And since my resolve had already been compromised, I took on the chocolate fondant:
Things were looking pretty good at this stage. We’d had a good share of food and wine tasting on the Cote D’Or, and we’d also been to Chablis. I really like Chablis. For the spirit of adventure we did two wine tastings there. Lily didn’t really like the first one, and chose that as the moment to announce to the world that she had teething issues. Mid-way through a wine purchase, I had to feel incredibly guilty as I attempted to conclude business in sub-standard French whilst listening to the sound of my wife scurrying round the bending streets of Chablis attempting to pacify my daughter. Ah well. Got the wine though.
Lily for the vast majority of the time was an angel. On this holiday she found the ability to do her baby gargle thing (and now has a great deal to say), she added grabbing to her already well developed bashing skill, and she now enjoys attempting to stand up on both legs (whilst being held of course). She’s always smiling when you make eye-contact with her. She’s a pleasure to spend time with.
As they say about France, Champagne is its soul but Burgundy is its stomach. As a wannabe foodie, I decided that this trip would be the appropriate time to commence a study of tarts. Not just any old tarts, but fruity tarts. I’m talking about strawberry, apple, lemon, raspberry, even rhubarb (a wine grower person was most impressed when I suggested that her 2004 rouge vintage tasted like cooked Rhubarb). Now though, sadly I’m tarted out. We bought four tarts each for the last day, and at one point I was contemplating of doing a John Prescott styled chuck-up in order to get through them. Testing times.
The weather wasn’t dream-like fantastic. But it was t-shirt weather, there was a fair bit of sun, and for the purposes of our holiday (bumming around cafes in ancient French towns, doing a spot of wine tasting, eating loads of good food, spending time with Lily, the swimming pool) it was good enough. It certainly wasn’t like the last time we were in Burgundy, where we had to endure a four course meal laden with wine in a 40C outdoor climate. Strewth.
Above: Kath and Lily hanging around Beaune.
Above: Kath and Lily at Chambolle Musigny having bought some wine.
Above: Trying to relax at the restaurant/hotel Le Montrachet. Had a fab meal there.
Permalink
06.13.09
Posted in General, Java
at 8:13 pm
What’s it all about? It’s easy to communicate without violence isn’t it? One would have thought that the majority of us would be able to convey a linguistic subtlety without having the need to head-butt the other person in the face (unlike some of my neighbours, but then that’s a different story 
).
NVC is about communicating without getting people’s backs up; their heckles raised. It’s the ability to enter into a discourse with compassion and empathy, and to uncover what the real wants are that people have during a conversation, including those that we have for ourselves. And while it may seem like it comes naturally to some, it’s actually very difficult for the vast majority of us. In society we’re conditioned to think in certain ways, for example to judge and to offer our immediate evaluations; we are unconscious of some of the blockers that we have towards effective communication. This results in an inherent violence that stirs in each of us.
So what specifically is NVC? Thankfully it’s actually quite simple. It’s a four-step process. I’d ideally advise people to pick up a book on it, as it’s one of those things you really have to take on board and to heart, rather than to simply acquire an intellectual grasp of the concepts.
1: Separate observation from evaluation
It’s habitual for many of us to combine observations and evalutions. For example, if my wife tells me that I always leave the place looking messy, then I’m bound to feel defensive about that. “No, I don’t”, I’d probably say, “I actually spent a couple of hours doing some cleaning at the weekend”. I’d feel attacked, and bad mood for both myself and my wife would probably ensue.
But if she were to state that there were a couple of socks on the floor in the bedroom, then I probably wouldn’t really have much of a feeling about the situation at all. I’d likely instead develop a want to pick up the innocuous pair of socks, and I might just darn-it go and do it.
Confronted with an evaluation, we typically either defend ourselves or submit. Confronted with an observation, and it’s a different story. According to the Indian philosopher J. Krishnamurti, the ability to separate out evaluation from observation is the highest form of human intelligence. Does it always rain in England? Or did it simply piss it down last year at Wimbledon? (2007 rings a bell)
2: Feelings
When you communicate, state your feelings. I feel X about Y. I have to admit, I’ve found the acquisition of this particular skill to be particularly difficult. Why? Because for a great many of us we haven’t really delved into the workings of our emotions. I don’t always know if I’m feeling mostly angry, mostly frustrated, irritated or even aggressive (life on the London tube does that for you). Like when I taste a glass of wine, what’s actually at play here? Is it the vintage, the oak in the barrel that it was fermented in, the field it came from, or the blend of grapes? There’s a lot going on in people’s minds that it can become difficult for us to categorise our various emotions and to label them.
People can spend a lifetime in the pursuit of unpicking their various emotions (Buddhist scripture states that there are eighty four thousand negative emotions alone). In the west we’re starting to label the ability to recognise one’s emotions as Emotional Intelligence (EQ). People also use the term ‘awareness’; e.g. are we aware of ourselves?
So communicating a feeling requires an awareness of the feeling in the first place. And it can be remarkably powerful. If I can be aware, open and honest to state what I’m feeling, then I invite empathy. If my wife were to say to me “I’m feeling a bit frustrated with the state of upstairs”, rather than “you’re pissing me off leaving these socks around”, then I’d probably have a connection with that. I’d understand and gain some empathy for the emotion she is experiencing, and I’d likely develop a want to do something about it.
As I said it’s difficult. At work one time someone asked me why I seemed a little down, in contrary to how I was when I first joined the project when I was more upbeat and positive. Rather than state my feelings of frustration at my apparent inability to influence some positive change fast enough, I defaulted to bravado. What me? Nah, I’m cool…. honest. I’m a bad-ass ninja-type character. Seeing as the person asking me about my feelings was an influential person on the client-side (I’m a consultant), it was an opportunity missed.
3: Needs
I really like this part of NVC. Like the all 4 components of the methodology, it’s an independent skill that one can muster (and is therefore in-turn measurable by the lovable Dreyfuss model of skill acquisition). I wanted to call this skill “needs based thinking” as I think it’s so powerful.
If my wife were to say to me “I’m feeling frustrated as upstairs has some clothes on the floor, and I have a need for the place to be tidy this weekend so that we can enjoy it”, then we’re really on the money. I know some more of what her needs are, and I therefore know better how to meet them.
Frustration, some people say, is the feeling one gets when their needs aren’t met. A big personal realisation for me is that I’m not totally aware of all my needs. I didn’t quite appreciate my need for engaging with others, having challenging intellectual skirmishes, my needs for adventure, for approbation… (goes without saying that not all needs are admirable). I, like others, am a complex person with complex needs. If I can identify them better, them I’m sure to have a happier life right? Conversely, one should ignore their needs at their peril.
It follows therefore, that if I can communicate them, then there’s a much greater chance of having those needs met. I’ve found that when I’m honest about my needs to others (without wrapping them in bravado or dressing them up likewise), then I tend to get some compassion back.
4: Making a request
So, now I know that my wife is feeling frustrated because there are some clothing items on the floor in the house upstairs, and that she has a need for the place to be tidy so that she enjoy the weekend. Great. But what I really want to know is what the next steps are. Thankfully in this situation I can infer that the action item should be to get off my arse and to pick up my clothes.
But it’s not always this clear. I can reveal my observations, feelings and needs to others, but without solid requests we can’t be sure that the other person knows what to do to make a situation better. I’m anxious that we have more preparation to do for this presentation and I need to get a handle on it… any chance we can hook up tomorrow evening to go over some things?
In Conclusion
NVC is certainly challenging to embrace, and of course there’s a fair bit more to it that the quick primer I’ve just given. I myself am probably on the journey to becoming more aware of it’s impact, and am hopefully a little more “consciously incompetent” than “unconsciously incompetent”. I’m a novice, but it’s a communication technique that I really, really want to learn. If you’re interested, I’d recommend that a good place to start is by picking up this book:
Permalink
03.31.09
Posted in General, Java
at 1:22 pm
“Self Organising” teams are somewhat of an elusive goal for Agile/XP projects, in the sense that the application of theory to practice can be far from intuitive, particularly for those coming from a traditionalist software management background. Despite this, having a team with the ability to ‘self-organise’ can make all the difference on a project, and not only in terms of productivity but also for purposes of satisfaction for those working within the team. Having seen some teams succeed and fail in this area, it’s a concept that I find especially interesting.
So, what precisely is a self-organising team? In the context of IT at least, we should be able to essentially understand that a self-organising team is a team that has the freedom and ability to shape itself accordingly to meet the varying challenges of software development (and of-course actual production).
Shapes itself how though? Well, to start with on an Agile/XP project we can look at some actual specifics, such as a team being able to choose the order of the software requirements to be developed (stories), and of whom exactly on the team gets to work on what particular task. Furthermore we can easily imagine that a self-organising team is one that decides when and how it should grow as to meet the demands placed upon it, and of projecting what sort of timescale to accomplish those demands is achievable given the current resources at hand.
So therefore it’s likely that we can all have a vaguish but regularly acceptable sense of what a self-organising team is. I would stipulate though that one of the problems with this term is that it’s frequently used too liberally, and can be quickly become quite a nebulous misunderstood concept associated with the best of consultancy-type babble. What I’d like to do here is to cut through some of the fuzziness to get a better understanding, and I’ll do that by initially focussing on what in my opinion a self-organising team is certainly not.
So what is not a self-organising team? I wouldn’t say that the converse means that a team that is necessarily un-organised. Just because a team isn’t self-organised doesn’t mean that members shouldn’t be able to turn up to work on time or to keep the build green. Instead, I’d say that the direct opposite of a self-organised team is one that would be entirely managed; the ‘managed team’.
In the scenario of software (a depressingly common end of the spectrum), the picture would be of a team that is not really a team but a collection of micro-managed people. Developers would simply turn up to work, and would be told of what particular piece of functionality they should be working on, and of exactly whom they should be working with. Any real challenges, including those of a technical nature, would have been worked out in advance by key personnel. Therefore we can see that in this idealised traditional vision of the workplace (borrowing from Frederick Taylor 1856-1915), all that the developer really needs to do is to shoot into an ‘open goal’; that is to do his/hers assigned and ‘plotted out’ series of tasks.
Managing a team in this way can be an extremely difficult job. Not only is there huge pressure on the management team to make the software production process flow more quickly, but managers will quickly discover that there is a never-ending torrent of things that can be managed. Who should be in the right meeting? Should developers pair-program the whole time? Can we trust them not to? Why are these developers discussing a discussion that has been discussed before by other discussers? Why are these developers discussing at all? Decisions have been made, challenges supposedly put to bed ahead of time… Frustration beckons as the developer’s open goal is proving to be not that open.
On such an example of a project, developers would find their innovative capabilities stifled (as any innovation would be managed via some specific process of having just the relevant technical stakeholders present at a particular time), Instead, developers will simply plod on, and any potential deviation from the course (such as refactoring some technical debt) would be fed back to the project management team and…. managed. Quickly managers would find themselves not just managing the production of software requirements, but also having to deal with the extremely blurred area of ‘technical debt’ that some developers keep on talking about, and they would need to ensure the eradication of a whole ranges of bugs that range from the critical to the downright trivial (as in why-don’t-developers-just-fix-them-right-away type trivial).
There is also the underlying serious contention that morale will decline on such a project. And with morale, a sense of real commitment to the overall mission being completed successfully. An easily observable, steadfast symptom of this is quietness within a team, present in one that is managed as opposed to self-organised. Communication when not occurring organically, along with morale, has the tendency to fall of a cliff.
Which brings me on to talk about the other side of the coin; the self-organising, positive side. Having looked at what takes place in a ‘managed team’, we can perhaps postulate that the goals of communication and morale are actually emergent properties of a self-organising team. If you want people to go faster, i.e. developers to develop software at a faster pace, then let them self-organise. Let the team itself work out who is best placed to work on what, and of how it should be done. Empower the team to make choices, and to take responsibility.
Trust extended out to a team in this way can be a big ask, but one could make a straightforward case that what fundamentally makes or breaks the self-organising team is exactly the matter of trust.
And whilst trust from above is fundamental, there are other important pre-conditions that need to be satisfied in order for the self-organising team to prosper. A self-organising team will not simply just rise out of the ground of a group of people, rather like a seedling, it has to be nurtured, and it comes with its own specific needs.
Leaders
A team needs strong leaders. In the software team, leaders are required to set positive examples of how communication should be done (such as freely, openly and respectfully). Leaders are essential to generate and preserve room for the team to innovate and to grapple with issues of a technical nature head on. Leaders act as the buffer between the rest of the team and the greater organisation the team finds itself in; they are the damn holding back the water.
Experience
The best people to help make a team self-organise are those that have had experience working in one before. They will have context for what a team with good communication feels and acts like, and will encourage other team members to take ownership of problems and to take action. Like leaders, they are the ones to set an example. Having experienced, high calibre people on-board will help to assuage any managers’ concerns that the team is on-course, and they will in-turn be less likely to want to step in and take charge.
Encapsulation
As I wrote about in a previous post, we need to avoid ‘dev team leakage’. This is to say that the internal day-to-day activities of a team need to be kept in-house; inside the team. Against a contract of clearly defined inputs and outputs the team must have the space to get what it needs to get done in order to produce working software. In order for people to take ownership of problems and to deal with them quickly, we need to give developers the room to tackle impending issues without the need for tracking and reporting to the wider business.
Strong management
It takes a strong management team to sow the seeds of a good team, and then to stand back and watch it grow (and to be there providing help when needed). The team needs to be allowed some trust so that it can make some mistakes, as well as the space to be able to continually adjust to better meet the needs of the business. Managers will need a host of other skills too, such as strong people skills, and to be adept at thinking strategically over the long term versus the tactical short-term. Typically there will be those in the business wielding considerable influence who are strictly results-orientated, and who will want to see direct hands-on action leading to direct results. These stakeholders will need to be handled adeptly.
And of-course, the self-organising team is no silver bullet, and is no easy ride. Communication can quickly become robust, and it may appear to those looking in that situations are becoming over-heated. When passionate people are striving towards the same goal, that passion and drive to make things better will occasionally bubble to the surface.
Resources
The team needs to be of the right size. Judging the amount of people a team initially needs is crucial. Too many people can lead to a lack of communication, where there exist too many links in the system for there to be a shared vision and a collective ownership of problems. If teams are to be split, they need to be split as to be relatively self-contained. Teams that have integration points that are simply ill-defined or too numerous will be unable to generate self-organisation independently of each other.
The self-organising team is difficult to get right, and the devil really is in the detail. It takes hard work, a belief in others and above all a large amount of trust engendered from those responsible for putting the team together in the first place. The results, including that of heighted morale and communication makes the process of allowing a team to grow organically hugely beneficial. And not to mention that the in end, such a team will be far easier to manage.
Permalink
02.06.09
Posted in General, Java
at 2:18 pm
It’s a bit of an anti-pattern that I have observed and want to discuss. Firstly though, I want to cut straight through an analogy that I believe helps to describe the situation (curiously, I have received some feedback on my propensity for using extreme analogies from a superb linguist colleague of mine who later was inspired to write an article on the subject: http://siddiqui.saleem.googlepages.com/sublimeanalogies).
If we can see the dev team as an animal in the jungle (and so forth we have other ‘animals’ such as QA teams, BA teams, Project Managers etc), then ‘dev team leakage’ refers to the cutting open of such a large and volatile jungle beast and of letting it’s gooey entrails slide out and slither amongst the wider natural setting of which the poor animal finds itself.
Yep. Basically it’s about breaking encapsulation. In the case of a dev team, there are many inner workings that need not be externalised to the outside world.
Technical ‘to-dos’ are one such example. On a typical agile project, the technical team would have a series of technical tasks that are being raised and dealt with on a continuous basis. This is part and parcel of what it means to develop software. A smart dev will think of something that needs doing that is not directly in his/her line of fire, and will flag it up as a task for execution at a more convenient time. The anti-pattern I am discussing would occur here if this ‘task’ was picked up by the wider process, and managed like any other software requirement. Suddenly the inner-workings of the software development team are exposed and tracked.
In this scenario, the project will seem a lot ‘busier’ than it should be, with issues largely of a fine-grained technical nature polluting the wider process. Woods would become difficult to see through the trees, and the ‘bigger picture’ – that is the production of functionality the business really cares about – is obscured.
Additionally, we can see that important business stakeholders may be presented with new, heavily-detailed information that they will probably not understand or frankly care about. In this example, it is easy to see that some stakeholders could get disenfranchised pretty quickly, especially if they were asked to start prioritising what technical tasks they would like developed in a particular order. They may also start to see the stream of ‘techno-babble’ being directed at them as a sign that the wider team is not focussing on what really matters, and they’d most likely be right.
This is a singular example of dev team leakage. Others include the micro-management of how developers might ‘pair’, or of dev stand-ups being folded into a wider stand-up consisting of various differing teams (missing the opportunity stand-ups offer for devs to give each other a ‘heads-up’ about various technical issues). Furthermore, there could be no mechanism (such as focussed retrospectives) in place for the team to continually improve, as improvement is dictated from above.
In taking this anti-pattern to the extreme, one can envisage the real risk that the ‘team’ may not actually be a ‘team’, but a collection of people acting as cogs in a larger machine. All the really good and essential stuff we get from ‘tight’ dev teams, such as collective code ownership, and not to mention a real sense of purpose and morale, would be lost.
At this point, I must stress that in order to avoid ‘dev team leakage’ we are not required to treat the dev team solely as a black box. Whilst the team may want to shield the complexity of its inner workings from the encompassing project, it ought to be able to stand up to scrutiny, and to justify the behaviours it extols on the wider system (a case in point is of the team justifying why they need more time to focus on cleaning up the house first, before tackling some additional requirements).
Here the root-issue is transparency. There is a traditional tendency of software project management that places the requirement on development teams to ‘push’ out a whole host of data out to the wider process, that might otherwise be kept internal. In the ‘push’ model (as oppose to pulling out data as needed), there is the danger that such data may be used for tweaking purposes, and that micro-management will eventually start to sink in, leading to a ‘command and control’ style of project execution.
The development team is of paramount important to any software development project. It needs to be able to hold up its head with dignity and will require experienced leadership to actively safeguard its own integrity. Importantly also, is that there are people on the outside helping to nurture it, providing the team with the space and resources it needs to operate.
Permalink
01.18.09
Posted in General, Java
at 3:21 pm
It already sounds difficult doesn’t it?
A bureaucracy, as defined by Warren Bennis (1969) cannot cope with:
- Rapid and unpredictable change
- The increasing complexity of modern organisation
- Diversity of specialist experience required in many organisations
- Humanistic, participative management styles
But before we start weighing up if an organisation is a bureaucratic one, we ought to be able to envisage what’s over on the other side of the spectrum. Well, this then would be an Adhocracy:
Adhocracy is a type of organisation design with is temporary, adaptive, creative, in contrast with bureaucracy which tends to be relatively permanent, rule-driven and inflexible. Adhocracy is similar to the concepts of organic and integrative styles; bureaucracy equates with mechanistic and segmentalist approaches.
I would add that an adhocracy is an organisation that is adept at continually improving itself.
Adhocracy Vs Bureaucracy
As a software consultancy we’re often asked to ‘transform’ an organisation from using a set of traditional software practices to more modern ones that we know achieve better results. Taking up some of these practices has direct repercussions on the way that IT departments organise themselves. Having been involved now in a few of these ‘organisation transformation’ projects, I’ve become increasingly convinced that from the outset we really need to get to grips with knowing exactly what type of company it is that we’re dealing with.
For example, as consultants if we go into an idealistic adhocracy our ‘change objective’ is going to be a great deal easier. Largely this is due to the client being used to change anyway; in fact change is part of their way of life and is embraced as such. In this situation we can do what good consultants do best, which is to implement change via a participatory approach. We can engage with workers in the ‘trenches’, and the good practices that we introduce will naturally ‘bubble out’ in an organic way, delivering change across the organisation.
The reality is though that most companies will have some bureaucratic traits in them. In order to answer this, we need to examine the question of ‘how do we tackle organisations that are veering towards being bureaucratic?’
Some consultancies, particularly the one I work for, would wish to encourage a participatory, collaborative way of spreading change through an organisation. By working with employees on a day-to-day basis, we can foster relationships that engender trust, and pave the way for individuals to try out new ways of doing things.
However, we must acknowledge that in organisations veering towards bureaucracy – i.e. ones with virtual ‘walls’ in place that separate out segmentalist units – such ‘organic’ change isn’t going to spread very far. Rather, by working in conjunction with people in the upper layers of an organisation, we will have the ability to propagate change downwards, and to try and possibly move a company along towards being more adhocratic. We can factor this approach in along with the ‘organic’, ‘bottom-up’ one, and so long as we synchronise up our efforts we may get a little more bang for our buck.
Going further, some researchers – Dunphy and Stace (1990 and 1996) argue that incremental and collaborative or consultative modes of change implementation can be highly inappropriate. For the survival of an organisation, where rapid change is absolutely necessary, transformative approaches will be effective when carried out in a directive and coercive manner.
It makes a little bit of sense in the end, that in order to change a ‘heavy’ bureaucracy we have to first embrace what a bureaucracy actually is and to play to its strengths.
Needless to say, if we’re working closely with the upper echelons of an organisation to help plan out a ‘directive’ change strategy, we’ll need to have a robust, comprehensive plan in place. We’ll need to have drawn up a roadmap of actions based on the original business objectives for change, performed an analysis of the major stakeholders, worked out how we’re going engage with the various sub-sections in the company; it’s a big task. Simply placing consultants in varying roles throughout the organisation and letting them work their magic isn’t going to cut it. The approach needs to be cohesive and well communicated.
It sounds somewhat obvious, but it’s really worth stressing that we really need to know up front what type of company it is that we’re dealing with when we’re asked to implement strategic change. An adhocracy? Great. A bureaucracy? Hmm…
Permalink