The wrong type of glue?

I kept on hearing the same kinds of grumbles on the floor and in retrospectives. The team were basicaly saying, we are being forced to use the wrong type of glue. The team are a pasinate lot, and so full and frank debates would flourish on which was the best type of glue, and who knew how best to apply it.

a selection of glues

Which glue is best for Baths?

Because i’d heard these grumbles a few times, i started to wonder why my awesome team were still struggling over what seemed trivial to me, just choose one and try it, right?

That is until it dawned on me.  What on earth are they trying to glue back together?

The bath, as it turns out.

The problem with gluing the bath was explained to me in great detail, some glues would leave an ugly stain, while others were very messy to handle, some other types of glue would set before the bath was stuck together again, and in most cases the glue wasnt water proof and the bath would leak. Despite this, the team were determined to get this right, they would get the bath glued together!

a bath in two halves

How to best stick the bath back together again?

Why is the bath in two halves? Seems like an obvious question now, but somehow i hadn’t asked that of the team.

“We cut the bath in half because it didn’t fit, someone ordered the wrong size bath” came the reply. So focused on delivery, the team hadnt stopped to think about telling the customer the batch was the wrong size, they just reached for the saw and cut it in half.

Obviously we haven’t stopped writing code, and invested in plumbing, i’m using a metaphor that describes what we have been doing for the last couple of months really well. In fact i can extend it a little further.

When i asked one of the dev team leads why they cut the bath in half, they suggested that they had been told to do so, but had they misunderstood what was being said?

When they had told foggy, the tech lead that they had an issue with the bath, he focused in so tightly on the problem that he only suggested that their plumbing was very complicated and that complexity was storing up technical debt that would be hard to pay down later, began to show them how they should improve and simplify it, he missed the fact that the bath was in two completely. They took his ignorance of the matter as acceptance of the fact.

To compound matters further, when JRH one of the BAs, thought he was being pragmatic in his approach, the developers actually took what he was saying as, stop crying about the glue and just do it. It turns out the BA didnt know the bath was in two either. He had made the same assumption as me, what’s so hard about choosing a glue?

How did this happen? I’m not entirly sure, but i have identified several problems that have grown like mould on a loaf of bread, slow and sure until it becomes unpalatable.

The good news is that the team obviously want to work and want to deliver, so eager to do so, that they made a decision that would allow them to continue to work. In doing so they unwittingly slipped down the rabbit hole.

In my next post i’ll explain how we are dealing with the fat end of the Business Requirement funnel, and this is causing the team to thrash.

Life after ThoughtWorks Part Deux

Last year i wrote a blog post Life After ThoughtWorks and this year i was reminded of it by an (now ex) ThoughtWorker Chris Read.

I re read the old post and marvelled at how far i had come in twelve months, and also how my attitude towards TW has changed too.

Now, twelve months on from that last post and I’m older for sure, more knowledgeable too, but i’m still passionate about Agile software delivery. So passionate in fact it often leaks out into my daily life. I have jokingly called my self evangelical about it. I’m often challenged by people who have had a less than optimal experience with Agile as a software delivery methodology, and sometimes i can feel their hate and anger for this stupid thing called Agile that everyone is talking about.

So, first up an apology, to a good friend of mine Keith Henry. Keith was talking to me about this weird and wonderful stuff called Agile at least 6 years ago, and i dismissed him as a nutter, while he just nodded and grinned; he knew I would succumb eventually, then he could (rightfully) say i told you so. Keith, i’m sorry it was I that was the nutter.

Next up a thank you. To several ThoughtWorkers who have changed my perceptions, shared their wealth of knowledge with me, and listened to my many, many criticisms, scepticism and pessimisms. They taught me many things (often through observation and not directly), and so, in no particular order:

Luke Barrett – for many things, the consummate consultant and voice of reason.
Graham “Wookie” Brooks – for teaching me that you can teach an old dog new tricks.
Chris “Dude” Read – for the filth and the energy.
Tom “Boobies” Scott – for teaching me to get my game face on, and never high 5 in public.
Richard “ffs” Fillippi – for the “Victor Kiam” moment, classic.
Sam Newman – don’t over promise and under deliver.
Jo Cranford – for making nice story cards and making coke come out of Chris Reads nose.
Pat Kua – Agile and performance testing can work.

I worked with many, many more ThoughtWorkers, but those above are the few who have shaped who I am twelve months on.

The big Question – Are we coping?

So TW roll off, hows it all hanging, are we still Agile? I think we mostly are, there have been a few times were the edges became a little frayed, but I think that in the past we may have stood by and watched as the fabric fell apart. This time we were able to tell that we needed to act, and were able to put in place a fix that was secure enough to have the required longevity and light enough as so not to deplete us of time and resource, and of course, we left the repair until the last responsible moment.

Our big challenge is not staying Agile, but keeping one team, that is distributed across two locations in sync. More than that, keep the synergy. That is not a software delivery problem, that’s a people problem.

Life after ThoughtWorks Part Deux

Last year i wrote a blog post Life After ThoughtWorks and this year i was reminded of it by an (now ex) ThoughtWorker Chris Read.

I re read the old post and marvelled at how far i had come in twelve months, and also how my attitude towards TW has changed too.

Now, twelve months on from that last post and I’m older for sure, more knowledgeable too, but i’m still passionate about Agile software delivery. So passionate in fact it often leaks out into my daily life. I have jokingly called my self evangelical about it. I’m often challenged by people who have had a less than optimal experience with Agile as a software delivery methodology, and sometimes i can feel their hate and anger for this stupid thing called Agile that everyone is talking about.

So, first up an apology, to a good friend of mine Keith Henry. Keith was talking to me about this weird and wonderful stuff called Agile at least 6 years ago, and i dismissed him as a nutter, while he just nodded and grinned; he knew I would succumb eventually, then he could (rightfully) say i told you so. Keith, i’m sorry it was I that was the nutter.

Next up a thank you. To several ThoughtWorkers who have changed my perceptions, shared their wealth of knowledge with me, and listened to my many, many criticisms, scepticism and pessimisms. They taught me many things (often through observation and not directly), and so, in no particular order:

Luke Barrett – for many things, the consummate consultant and voice of reason.
Graham “Wookie” Brooks – for teaching me that you can teach an old dog new tricks.
Chris “Dude” Read – for the filth and the energy.
Tom “Boobies” Scott – for teaching me to get my game face on, and never high 5 in public.
Richard “ffs” Fillippi – for the “Victor Kiam” moment, classic.
Sam Newman – don’t over promise and under deliver.
Jo Cranford – for making nice story cards and making coke come out of Chris Reads nose.
Pat Kua – Agile and performance testing can work.

I worked with many, many more ThoughtWorkers, but those above are the few who have shaped who I am twelve months on.

The big Question – Are we coping?

So TW roll off, hows it all hanging, are we still Agile? I think we mostly are, there have been a few times were the edges became a little frayed, but I think that in the past we may have stood by and watched as the fabric fell apart. This time we were able to tell that we needed to act, and were able to put in place a fix that was secure enough to have the required longevity and light enough as so not to deplete us of time and resource, and of course, we left the repair until the last responsible moment.

Our big challenge is not staying Agile, but keeping one team, that is distributed across two locations in sync. More than that, keep the synergy. That is not a software delivery problem, that’s a people problem.

Skills not Roles – Communities not Teams.

When i decided to put this blog together, part of the impetus was using it as a historical repository. There are a great many of my posts on the internet today that date back to 1999. Ten years is a fairly long time in internet years, and looking back over those posts i can see how my understanding of different topics has evolved and how much I’ve learnt and grown. That said, its not going to work (a historical record) if i don’t post anything is it!

The reason i haven’t posted for quite some time is two fold. Simply put I’ve been too busy at work and too busy at home. That is to say, the blog has had to take a back seat. I’m sorry I’ll try harder.

OK on to the post proper.


So this post will differ in that i’m not going to discuss technologies like Twist or Selenium or WebDriver.

I want to talk about something that is currently crippling the project I’m currently working on.

For a project to be truly Agile and Lean it needs to be able to respond to the challenges that we face daily in IT and overcome the challenges without waste. So why then do we have to hand off tasks like deployments to another non Agile team? Moreover the handover is done via an abhorrent “work-flow” tool that admonishes the receiving team from any aspect of quality or responsibility “I’ve done my bit mate, its with team X now”.

I want to get rid of teams as we know and recognise them today and usher in communities. Yeah sure the name is a bit hippy-ish but then so is the ideal. Skills not roles. If someone within our delivery community has the necessary skills to deploy some code to a database or server then why do we have to interface with an external team? If we have the capability, and we are responsible, what’s the problem?

OK, sure, the guys who look after the production systems want to achieve 99.999% uptime (26 seconds of downtime a month), and often they are targeted on this so they become averse to change. After all any change increases the risk of a failure. However, if we have tested the code, not once, not twice, but umpteen times and more importantly we only compiled the code only once, and all previous deployments have gone without incident. You could be forgiven for thinking that the deployment could be considered as being safe for deployment. A non event. We should be able to deploy the code at 17:30 on a Friday afternoon and skip off home safe in the knowledge that the site is up and running, humming along like a well oiled machine.

However, those teams have become so averse to change or risk as they perceive it, that they actually start to display behaviours reminiscent of the 1970 trade union shenanigans that plagued British industry “you can’t do that mate, not your job. Not anyone can deploy code you know, oh no. where would we be if just any old tom, dick or harry could deploy code willy nilly”.

As an Agile commune focused on delivery of our project we would share the skills and socialise ideas. We need to create innovative environments that promote people trying new things. This aids the members of the community which therefore benefits the business. So not anyone could deploy the code. Only those people that had the skills and were responsible in the execution of their duties.

The more i think about this, the clearer it all becomes. I suddenly find myself questioning my own role as a “people manager” within such a community. After all my role as in its current shape would be wasteful. I should not manage the team (to be honest, that’s not my natural style) I should coach and mentor, not preach and target. I should lead by example, not autocratic rule. As Alan Keith of Genentech said “Leadership is ultimately about creating a way for people to contribute to making something extraordinary happen.”

I’ve run this idea past my peers. Old peers agree with me, they see it as a way to empower individuals, and therefore the community they reside in. But younger, less wise peers are worried. “How will we administer pay grades” they ask, “how will we hire people, if we don’t have recognised roles”.

Its really quite simple. Individuals are rewarded for the skills they have not their ranking within a role. Why should an experienced tester with polygot skills and several years domain knowledge be paid less than a BA with flaky knowledge of your technology platform? What because business analysts traditionally earn more than testers? For that matter why should a developer be paid more than a business analyst if the BA can also test? Two skills vs one. The current game is rigged and is demotivational.

Hiring is also easy. You want titles for your people? Call them analysts. Then all you need to do is hire analysts with the appropriate skills for your domain and your platform. Other companies call their staff “consultants”, and they hire consultants with the appropriate skills for the client they engage with.

Once you have a pool of multi skilled analysts, it would be easier to create a community that had the right skills required to deliver the project, instead of worrying about the interfaces to external teams or having a shortfall of a particular discipline within your community. You can select your community members based on their proven experience, their skills, their domain knowledge and the feedback they receive from the communities they have previously worked in. A community is unlikely to carry a lazy person who knows little about the domain and has few or poor skills.

Now i’m not saying we don’t need SysAdmin or DBA or networks etc. We need all those teams, and what they do is invaluable to the delivery of the project. But do those external teams need to perform what amounts to mundane tasks for us? Shouldn’t they concentrate on what’s important to them, the stability and performance of their area. Because as it stands today at the point we interface with those external teams for the execution of a task that could be carried out in-team by an appropriately skilled and responsible analyst, they become a blocker and they become wasteful. We sit twiddling our thumbs while we wait for those teams to follow their internal processes and use the infernal work-flow tool (and its only real purpose is to provide the business with yet more meaningless statistics).

When i have approached the external teams, i have found that they harbour a fear of “Agile” and i think this fear is the real problem. They feel uncomfortable, anxious, or inadequate. They worry that by allowing us to be responsible for our actions then they will be allowing themselves to be exploited and by denying us it helps protect their rights as an individual.

The business feels the same way. Despite the corporate line being “we are Agile, lean, innovative…” they fear change to the point that they have implemented a change management process, and a change manager and recently said we have to use sharepoint (ffs). But what the business hasn’t realised is that as a tester i am risk averse (no really its a curse), so we are actively baking the quality into our products and continuously inspecting them for that quality – through unit testing, integration testing, and acceptance testing.

It will be incredibly hard for the external teams let go, especially while the business is frozen with fear, but in the future they will have to. They will have to or we may as well pack up and go back to PrinceII – not while there is breath left in my body…

Skills not Roles – Communities not Teams.

When i decided to put this blog together, part of the impetus was using it as a historical repository. There are a great many of my posts on the internet today that date back to 1999. Ten years is a fairly long time in internet years, and looking back over those posts i can see how my understanding of different topics has evolved and how much I’ve learnt and grown. That said, its not going to work (a historical record) if i don’t post anything is it!

The reason i haven’t posted for quite some time is two fold. Simply put I’ve been too busy at work and too busy at home. That is to say, the blog has had to take a back seat. I’m sorry I’ll try harder.

OK on to the post proper.


So this post will differ in that i’m not going to discuss technologies like Twist or Selenium or WebDriver.

I want to talk about something that is currently crippling the project I’m currently working on.

For a project to be truly Agile and Lean it needs to be able to respond to the challenges that we face daily in IT and overcome the challenges without waste. So why then do we have to hand off tasks like deployments to another non Agile team? Moreover the handover is done via an abhorrent “work-flow” tool that admonishes the receiving team from any aspect of quality or responsibility “I’ve done my bit mate, its with team X now”.

I want to get rid of teams as we know and recognise them today and usher in communities. Yeah sure the name is a bit hippy-ish but then so is the ideal. Skills not roles. If someone within our delivery community has the necessary skills to deploy some code to a database or server then why do we have to interface with an external team? If we have the capability, and we are responsible, what’s the problem?

OK, sure, the guys who look after the production systems want to achieve 99.999% uptime (26 seconds of downtime a month), and often they are targeted on this so they become averse to change. After all any change increases the risk of a failure. However, if we have tested the code, not once, not twice, but umpteen times and more importantly we only compiled the code only once, and all previous deployments have gone without incident. You could be forgiven for thinking that the deployment could be considered as being safe for deployment. A non event. We should be able to deploy the code at 17:30 on a Friday afternoon and skip off home safe in the knowledge that the site is up and running, humming along like a well oiled machine.

However, those teams have become so averse to change or risk as they perceive it, that they actually start to display behaviours reminiscent of the 1970 trade union shenanigans that plagued British industry “you can’t do that mate, not your job. Not anyone can deploy code you know, oh no. where would we be if just any old tom, dick or harry could deploy code willy nilly”.

As an Agile commune focused on delivery of our project we would share the skills and socialise ideas. We need to create innovative environments that promote people trying new things. This aids the members of the community which therefore benefits the business. So not anyone could deploy the code. Only those people that had the skills and were responsible in the execution of their duties.

The more i think about this, the clearer it all becomes. I suddenly find myself questioning my own role as a “people manager” within such a community. After all my role as in its current shape would be wasteful. I should not manage the team (to be honest, that’s not my natural style) I should coach and mentor, not preach and target. I should lead by example, not autocratic rule. As Alan Keith of Genentech said “Leadership is ultimately about creating a way for people to contribute to making something extraordinary happen.”

I’ve run this idea past my peers. Old peers agree with me, they see it as a way to empower individuals, and therefore the community they reside in. But younger, less wise peers are worried. “How will we administer pay grades” they ask, “how will we hire people, if we don’t have recognised roles”.

Its really quite simple. Individuals are rewarded for the skills they have not their ranking within a role. Why should an experienced tester with polygot skills and several years domain knowledge be paid less than a BA with flaky knowledge of your technology platform? What because business analysts traditionally earn more than testers? For that matter why should a developer be paid more than a business analyst if the BA can also test? Two skills vs one. The current game is rigged and is demotivational.

Hiring is also easy. You want titles for your people? Call them analysts. Then all you need to do is hire analysts with the appropriate skills for your domain and your platform. Other companies call their staff “consultants”, and they hire consultants with the appropriate skills for the client they engage with.

Once you have a pool of multi skilled analysts, it would be easier to create a community that had the right skills required to deliver the project, instead of worrying about the interfaces to external teams or having a shortfall of a particular discipline within your community. You can select your community members based on their proven experience, their skills, their domain knowledge and the feedback they receive from the communities they have previously worked in. A community is unlikely to carry a lazy person who knows little about the domain and has few or poor skills.

Now i’m not saying we don’t need SysAdmin or DBA or networks etc. We need all those teams, and what they do is invaluable to the delivery of the project. But do those external teams need to perform what amounts to mundane tasks for us? Shouldn’t they concentrate on what’s important to them, the stability and performance of their area. Because as it stands today at the point we interface with those external teams for the execution of a task that could be carried out in-team by an appropriately skilled and responsible analyst, they become a blocker and they become wasteful. We sit twiddling our thumbs while we wait for those teams to follow their internal processes and use the infernal work-flow tool (and its only real purpose is to provide the business with yet more meaningless statistics).

When i have approached the external teams, i have found that they harbour a fear of “Agile” and i think this fear is the real problem. They feel uncomfortable, anxious, or inadequate. They worry that by allowing us to be responsible for our actions then they will be allowing themselves to be exploited and by denying us it helps protect their rights as an individual.

The business feels the same way. Despite the corporate line being “we are Agile, lean, innovative…” they fear change to the point that they have implemented a change management process, and a change manager and recently said we have to use sharepoint (ffs). But what the business hasn’t realised is that as a tester i am risk averse (no really its a curse), so we are actively baking the quality into our products and continuously inspecting them for that quality – through unit testing, integration testing, and acceptance testing.

It will be incredibly hard for the external teams let go, especially while the business is frozen with fear, but in the future they will have to. They will have to or we may as well pack up and go back to PrinceII – not while there is breath left in my body…