Rolling out a methodology is about design

Implementing a new methodology is a painful exercise.  Lots change, lots break, and lots of so-called “colateral damage”.  I have tried implementing new methodologies including XP and Scrum many times.  I have also witnessed a lot of attempts by other people, and been involved while others drove the initiative.  Every time, it has lead the organisation into a disruptive, stressful state.  The most common position taken by the implementors is:

Of course it is disruptive.  That’s part of the change-process.  We all knew that from the moment we started. How else do you think it’s going to get better?

In the past, I’ve been guilty of the same.  The end result is that I am left unsatisfied and unfulfilled, and so is the organisation. Yes, it may eventually get better.  Eventually I got sick of taking this high road.  Well, it only took two such situations a long time ago to realise that I was messing up royally.

In my quest to do things better, I drew inspiration from test driven development and dealing with old, messy legacy code.  Three very distinct things which are rooted in software development and changing legacy code is very, very apt.

  1. Rolling out a methodology is at the implementation level.  So, was there a design for the implementation in the first place?  Implementation without design always ends up in a mess.
  2. Even if we abstracted the design from one implementation, does the design support all implementations?  “Similar” does not equate to “same”.
  3. The existing methodology has a set of protocols by which the organisation functions, while the new methodology introduces a new set of protocols.  Just dumping down the new protocols is the equivalent of rip and replace – the grand rewrite without care for migration.  Is this the only way?

So, taking inspiration from code, here is something that you can try when attempting a new rollout.

Understand the existing implementation. Use a test based approach to concretely discover existing protocols within the organisation.  This may be as simple as playing out what-if scenarios that test the communication pathways.  Keep your eyes wide open for seams or boundaries.  These seams are candidates for incision points for introducing a new protocol facing in towards the area under change while honoring the old protocol facing out towards the other side that should not be changed (yet).

Design, design, design. Once you understand the existing protocols and how they behave under certain scenarios, you switch to design mode.  Look again at the dependency graph within the organisation for a particular protocol.  What is affected when a certain event occurs?  Then look at your candidate seams and incision points and design your wedge.  It may be a transformer that completely modifies information as it crosses over the seam.  Maybe it’s a buffer with a finite capacity that slows things down and trickle feeds info to the other side.  What about a filter that removes some info?  How about something that just decorates existing info with a just a wee bit more that is tolerable on the other side.

This design is mostly about designing feedback loops.  As such, you need to consider the temporal and synchronous aspects of feedback also. What is the expected latency when I stick in this new wedge?  Will it take one week or one day or one hour when something crosses this boundary?  Do we send off some info and wait for a response on the same pathway, or do we get informed of which other pathway to regularly check for the response?  Perhaps someone gets nudged when the response arrives.

Implement it test first. While it may seem like a lot of upfront work is necessary to get the ball rolling, it can be done in tiny steps.  You don’t need to fall into the analysis hole when looking for seams.  Nor do you need to get stuck looking for the perfect design.  It is better to remain concrete for long periods of time, than speculate at possibilities.  Doing a little bit at a time with some small tests helps you keep both feet on the ground.  For example, you want to switch from the old protocol of reporting progress with budgeted vs actual to burning down story points.  Some people still need to use the budget vs actual report and it is inefficient to have to maintain both (not to mention not DRY at all).  We need a way of transforming from burn down to budget vs actual.  Think about candidate tests that will shift you towards that goal?  Maybe it’s “I should be able to take existing budgeted tasks in a time frame and map it to tasks on the burndown”.  Perhaps it is “I should be able to introduce new time frames on the budgeted vs actuals that synchronise with new sprint boundaries”.

These are just some things that I think and try out.  It comes from me being sick and tired of subjecting people to stressful implementations and being party to messed up implementations too.  It’s just too easy to blame someone or something else for our own ineptitude.  I don’t take the high road anymore.  I take the middle road.  It doesn’t travel straight, and has branches with dead ends too, but it leaves me a lot more content.

You can’t let Scrum die

In my last post I said we should let Scrum die.  We can’t let Scrum die.  It doesn’t behave like that.  It will only die off its own accord if we die first and then it dies because it has no reason to exist.  So you got to kill it.  Here’s why (again?).
Software development is about people and the way people work alone and together.  People create code in software development.  Without that code, these people don’t exist; they have no purpose.  Code is the creation of the people, and people live off this code.  When the code is good, then life is good.  When the code is poisonous, then people start dying slowly.  When the smell of death is in the air, they look for help.  Some stare into the mirror called Scrum. They see themselves and the way they behave.  It’s an ugly sight.  They realise that they should behave better.  After all, software is about the way people work alone and together.

Regularly looking into the Scrum mirror, they improve their behavior over time, and everyone is happier than the moment before.  That’s a nice view.  Just look in the mirror and it looks good.  Very rarely do they also look again through the window into the fields of code that feeds them.  The poison is still coursing through their veins.  They will die, eventually … by the host that they created that was supposed to nourish them.  The only way to survive is to deal with the fields of code.  Get rid of the toxins.  There are two fundamental ways(*) that you can get rid of toxins: (a) eliminate duplication, and (b) make the code as you wish it to be.

If they just stare into the mirror and hardly ever look out the window, they will just exist on the plateau of complacency.  In order to avoid that state of being, they need to focus on the fields of code.  The urge to look in the mirror is strong, and as useful as it was, it becomes a very unbalanced state of existence.

So, look in the mirror, but look through the window too.  Create fields of code without toxins so that you provide nourishment for the next person.  That is ubuntu coding.

Actually, the only mirror you need is the person working next to you.

(*) Think deeply about these two fundamental things and try it out.  Everything else will fall into place from this. For example, the act of eliminating duplication forces you to consider where to locate a single piece of code, how it should be used and where it can be used, etc.  That is design and architecture.  With duplication, you don’t need to consider any of those things.  That’s toxic.

Let Scrum die

I live in Cape Town, South Africa.  Apart from the great beaches, a mountain in the middle of the city, good food, and good wine there is a feeling of enthusiasm for agile software development in this town.  It’s been around for a while but really started getting all hot and sweaty with the Scrum wave.  I estimate that it’s been at least 2 to 3 years since some teams in Cape Town adopted Scrum.  Of course, there are teams adopting Scrum in this community every year.  That’s all good, but I’m afraid it’s shaping to be just like Table Mountain.

Regardless of the hyper-performing tagline of Scrum, each team settles down to something with which everyone is comfortable.  The big change that has happened is that of changed behaviour.  Scrum does that – it alters behaviours.  When everyone plays by the rules (i.e. they behave consistently) then you don’t have chaos.  It’s better than better – it’s just nice!  It is very comfortable.  But I see signs of chaos not far away again.  This is what is happening and it is almost without exception here in Cape Town.  Some are off the table top already.

Let me make the Scrumvangelists feel better for a brief moment.  Scrum won’t kill you  – directly, but your adoption of Scrum can kill you if you ignore one thing – your code base.  It is a code base out of control that leads to certain death, and Scrum won’t be the saviour this time.  Bringing your code base under control is not easy.  It is all about architecture, design and changing your style of development to live the principles that end up characterising good code.  I don’t need to tell you what you need to do.  It’s been told so many times – TDD, refactoring, continuous delivery, single code base, etc.  At the code face it’s SOLID and DRY and lots more.

The plateau of complacency is an interesting place.  We may think we are collaborating but in reality we have just found a way to work together without causing chaos.  I call it co-operation.  It’s just keeping chaos under control so that we can make the sprint, again and again and again.  A sure sign of being on the plateau is when we can’t get rid of our Scrum master.  When we work the Scrum master out of the system, then the team will need to take on more on it’s shoulders.

A major limiting factor to get off the plateau will be the people on the development team.  Hyper-performing teams have talented developers(*) that are able to design and express that design in code without breaking their principles.  A team that is unable to bring a code base under control will compensate by leaning on a scrum master for support.

In the journey of dramatic improvements to bring your code base under control, there are few things that you should take notice off.

  • An architecture will emerge that supports the design of the resident parts.  Things fit together beneficially.
  • The code base will get smaller and the team will shrink to about 2 or 3 people.
  • Each developer will take on greater responsibility and will find it difficult to break core principles.  The act of living those principles will result in a values that don’t need to be listed on a poster on the wall.
  • The scrum master will become redundant.
  • The product owner will do more by working directly with the developers.

Then you won’t need Scrum, because the code base is under control, developers represent the interest of their customers, and the bottleneck is now at the customer.

Am I being idealistic?  No, it’s about pragmatic decisions and the pursuit of freedom.  It’s hippie Scrum.

(*) By talented I mean developers who have the ability to communicate, share, solve problems simply and elegantly, and can sniff out bad design and architecture.  Talented developers are not code monkeys that can churn out code.  Their single differentiating trait is the ability to design well and express that design in code.

The politics of software delivery

Software is all about delivering something useful to a customer.  That’s it – nothing else.  Politics is about acquisition of power.  Nothing else matters.  Now mix the two together.  How often have you heard a developer say something like “It’s not my problem, it’s just politics”?   That poor developer doesn’t stand a chance.  Imagine trying to deliver software while there is a raging power battle going on.  I don’t think software delivery stands any chance of success in that battle.  In fact, software delivery just becomes a tool for the politicians.
When someone is plotting for power, nothing else matters, not in the least software delivery.  I’ve been there and done that.  It’s just messy, soul destroying stuff.  These days, I look for the power battle and try to focus on software by raising the delivery stakes to higher than the power battle.  If I can’t do that, then the software was never the focus in the first place.  Then I recommend pulling the plug.  Regardless, that’s my cue to leave.  Not because I am a coward, lacking courage, but for the simple fact that those power grabs are completely meaningless, except for the power-hungry.

As long as there is a political game being played, you simply won’t deliver software on time, on budget and keep customers happy.  BTW you can just forget about collaboration too.  That space will always be filled with contempt.

Let me put it another way: Any attempt at being agile in a political environment will always lead to failure.  While you are trying to learn, others are trying to gain power.  It doesn’t work!

Hello World with KRS

Khanyisa Real Systems very kindly asked me to contribute an article to their December newsletter.  I happily obliged.  They’ve just started this initiative and I like it already.  Not because they invited me to write, but because the content is original, including the ‘toons.  In a world that is retweet mad, that says a lot to me – someone out there cares enough to create and gather original content and share it.  Read it for yourself, and if you like you can subscribe on their website.
And I’m dead serious about my message in that article!

A coach walks into a bar …

One day you are faced with a problem.  You succeed or fail in solving that problem.  It doesn’t matter.  Time passes.  You meet someone who paints a picture which has some parallels to what you experienced.  A few possible things can happen.


You tell them about your experience.  They listen. They ask questions, you answer, talk, listen, listen, talk …


You ask them a question.  They answer, question, answer, question, answer …


You chat.  It is not anything like your problem.  Chat, chat, chat …

Given each scenario above, when are you a coaching?  When are you being coached?

My view on coaching is simple.  We oscillate between knowing and not knowing so often that it doesn’t matter who is learning from whom.  It does not matter !!  In any given context, you are either a coach or being coached based on what you know.  You fluctuate between these extremes many times in a conversation, in an hour, in a day, in a lifetime.

This is part of my quest for balance through the work that I do.  “Coaching” feels one directional, a fabricated “us and them” labeling of people. That is an unbalanced state of being.  Learning is a balanced way of living.

And if you have not yet figured it out  … agility is about learning, learning is about living, living is about being in the present, being in the present is about embracing change, embracing change is about being agile.

RESTing at Øredev

There was quite a bit of REST chatter at Øredev last week.  I sat in on the REST in Practice tutorial by Ian Robinson and Jim Webber (if you have not read the book they co-authored, then do – it’s really well written).  There were a couple of things that these two guys cleared up for me, in the tutorial and in conversation during the week.

Application state is in the head of the consumer, not the provider of the resources.  This suggests that we should be able to recompute the state of application at any time.  If we can recompute the application state, then we don’t need to explicitly implement the entire application state machine in the provider, nor the client.

You may start off with modeling an application state machine on paper and discover the life cycle of resources.  Implementing this is then simpler because we are only need to implement the lifecycle of the resource, not the entire application state.  The way the consumer drives the state machine is just be reacting to available transitions in the representation of a resource.  Now you give the provider the freedom to change the application state machine and the consumer will react to the new state machine by discovery. That is significant.

Use hypermedia to refer to yourself. This came up in the tutorial because I objected to a resource including a hypermedia link to itself, regardless of its state.  To me, it seemed to have little value because you already have the representation of a resource in a particular state, so why include hypermedia for itself.  For example, this is what a resource will look like without a link to self.

    <link rel="pay" href=""/>

Now, if I want to GET the original order resource, I would need to know that there is some URI that includes the id of the order.  And, so, we end up publishing a URI template such as


If we include a link to self, then the representation looks like this.

    <link rel="self" href=""/>
    <link rel="pay" href=""/>

Look Ma!  I don’t have to expose a URI template anymore.  It’s all discoverable.  That is significant.

REST support in WCF is heading in the right direction. I also listened to Glenn Block’s talk on his team’s work on HTTP and REST support in WCF.  It’s still early days but I think they are paying attention to experts in this space and giving priority to the developers that will use it.

In the past you would have to map a very specific, template based HTTP GET operation to a method like this (excluding the additional endpoint configuration too!)

[WebGet(UriTemplate = "{id}")]
public Contact Get(string id, HttpResponseMessage resp) { ... }

What Glenn showed was a method signature that resembled the HTTP operation on the resource.

public Contact Get(string id, HttpResponseMessage resp) { ... }

Sure, it’s using a lot of convention over configuration to get rid of the attributes.  Now that may not seem like a big deal, but I do think that it is moving the HTTP abstraction down to a level that is more resource friendly.  When you are building a RESTful architecture, then you do think quite naturally in terms of the resources and their allowable HTTP operations for obtaining state or triggering a state transition.  By moving away from mapping HTTP operations to a service contract, it introduces the necessary mental shift from RPC to Resources.  And that is significant.

Practical Scrum with Kent Beck

SD Times has started a series of Leaders of Agile webinars.  The last was on Continuous Delivery with Kent Beck facilitating a discussion with Jez Humble and Timothy Fitz.  The next in the series is on Practical Scrum which will, again, be lead by Kent .  I think it will be a interesting perspective coming from the person that brought us Extreme Programming and so much more.
Sign up, it’s free.

This mess started long, long time ago

My son borrowed Asterix and Cleopatra from Claremont Library last week.  It’s been ages since I read anything from that series.  But page 2 really had me chuckling.  There is an image of the page online, but it’s bit hard to read.  So, here’s the dialog.

The scene: Cleopatra has been challenged by Julius Caesar to build a grand palace that will prove that the Egyptians are an advanced nation.  She summons Edifis, her architect.

Cleopatra: Edifis, I have summoned you because you are the best architect in Alexandria – which is isn’t saying much.

Edifis: Oh!

Cleopatra: Don’t answer back! Your buildings are flimsy.  You can hear every word the neighbours say.  The ceilings fall in!

Edifis:  It’s these modern materials… Actually, what I really want to do is build pyramids and …

Cleopatra: Silence!  You have just three months to make good.  You are to build Julius Caesar a magnificent palace here in Alexandria.

Edifis: Did you say THREE MONTHS?

Cleopatra: If you succeed, you will be covered in gold!  If not, you will be thrown to the crocodiles!  You may go.

(Edifis walks out)

Edifis: (thinking) Three months!  I’d need supernatural powers to do that!  I’d need someone who can work magic.

Edifis: (shouting) Got it!  I know the very man!  He can work magic!

Now, where have we seen that before?

(And just get the original book and read on about mule-driving the slaves to haul huge blocks of stone … classic!)