Tag Archives: agile

You can’t let Scrum die

Posted on by

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.

The politics of software delivery

Posted on by

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!

Practical Scrum with Kent Beck

Posted on by

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

Posted on by

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!)

What freedom?

Posted on by

At the Scrum gathering I had a tiny little conversation with Lorraine Steyn of Khanyisa Real Systems and Henrik Kniberg of Crisp about some of the values in our organisations.  At the top of Henrik’s value list was Freedom.  It seemed straight forward enough, until I started thinking about what freedom means to me.

My early perspective and experience on (the lack of) freedom is based purely on oppression of apartheid.  Ok, that’s over, so I am now free. Right?

Then John Lennon’s Imagine lyrics sang through my head.  If we’ve nothing to kill or die for, will we have universal freedom?

Hold on, what about when Janis Joplin sang Me and Bobby McGee – “Freedom’s just another word for nothing left to lose”?  That sounds too dreary for a concept that should make me happy.

Tonight I saw a quote by Maria Montessori on the wall next to my wife’s desk at home.  It’s been there forever and it says:

“The  essence of independence  is to be  able to do something for one’s self.”

I like this the most.  Be able to something for yourself and you will gain independence which sets you free.  It also reminds me of the self-organising mantra in Scrum-land.  Self organising implies that the team wants to be able to manage themselves so that they achieve independence (freedom).  But, there is a little spark of conflict in here.  As individuals we also have priorities and values, which is not necessarily aligned with that of the team.  Is it acceptable to compromise just to subscribe to the homogeneity of the team?

I think it’s a long walk to freedom.

Modeling out Loud

Posted on by

I will be running a 6 hour long session at the Scrum Gathering in Cape Town in September titled Modeling Out Loud.  I’m now convinced that the Scrum tribe are weird.  They call these sessions Deep Dives.  Presumably, you need to carry enough oxygen to survive the session.
I think I’m going out on limb here because I will be challenging the value of Product Owners writing stories.  I’m also suggesting that when Product Owners write stories riddled with behavior then developers are disconnected from domain experts and you regress into a waterfall mode of execution fronted by a Scrum Board.  So be prepared to experiment with me and turn up your self-reflection to maximum level because we will challenge many assumptions.

Architecture in an Agile World

Posted on by

Next week, I will give a talk at the JCSE Architecture Forum entitled Architecture in an Agile World (or maybe it’s the other way around). It’s not a new topic but since I visited it at a MagmaTec conference late last year, I have updated my thoughts a bit.  The angle is also different because I want to explore what it means to be agile in process, and agile in practice and how that relates to understanding a problem and carving out solutions.  Often, it is actually a choice to find a solution that is just and that is able to balance the various tensions.
But, I think I am equally excited at the possibility of seeing some familiar faces again in Johannesburg.

Beware the Big Industry Specification Up Front

Posted on by

If you have done any development in Java-land, then surely you came across the dreaded three letter word EJB.  And you were most likely duped into thinking it was great.  I did!  Then I realised it was just a specification.  It was a great big, furry, non-executable PDF.  A specification for managing objects but the creating of these objects were just horrid.  EJB3 was a clean-up exercise, but still far from nice.
A couple of months ago I ran into OSGi again, but with SCA on top of it.  Horrid!  SCA is yet another warm and huggable specification.  But it’s so ugly to work with.  Everything feels so over the top complicated and restrictive in expression.  And the tools that I saw built on this SCA implementation were just awful.  Beyond being buggy, the enforced paradigm was just counter-productive.  When will tool vendors realise that talented developers do not want a diagramming interface to write code?  But the root cause is that the SCA specification describes the diagramming notation. Yuck!  Same reason that I do UML sketches with a lot of bastardisations with no tie-in with my code.

And let me not go into domain specific big vendor specs, designs, blue prints, etc. like IBM’s Insurance Application Architecture (IAA). Nasty stuff.

More commonly, I see so many self-confessed agile teams fearing the dreaded big design up front, and the big requirements up front document thrown over the wall.  If there is such a fear for big-x-up-front, why is there no fear for big-industry-and-vendor-specs-up-front like EJB, SCA, IAA, etc?

Why?

There are deep lessons and principles lurking beneath this surface.  Agile demands you to be a lot more aware of actions, decisions and consequences.

So why do you choose not to be agile when you are trying so hard to be agile?

The Last Sprint Challenge

Posted on by

In agile economics we often talk about stopping the project before it 100% complete; when you reach a point of diminishing returns; i.e. that agile fail-safe point when the cost of producing software is greater than the value of the software itself.  Kind of.
So let’s try a weird-ish thought experiment.  You’re in such a project and you’ve reached this point.  You are about to start the dead last sprint and then it’s over.  The team will be disbanded, but the software will live on.

You have just one more opportunity to work on this product, with this code base, with the people on this team.  Your legacy is in this software.  Every decision you made is sitting in a vast time line of deltas in your version control repository, all the way back to day 0.

What do you choose to do in this last sprint?