Tag Archives: balance

What’s the point in Scrum?

Posted on by

Scrum people like to use points for estimating and measuring velocity.  I won’t go into detail about how points work and how to play those poker estimation games.  Just search around and you will find a ton of stuff.  So, back to this points stuff.  I have a divided relationship with the humble point.  I like it when a team switches to using points for the first time, because it gives them a chance to think a little bit deeper about what they want to do.  I don’t like it when we start inventing rules around points (and you can lump guidelines and best practices into the rules pot too).  When the rules appear, the thinking disappears.
In every team trying Scrum, there is bound to be a rule about points.  I dare you to put up a hand and say you have none.  These rules are things like “We can’t take anything over 13 points into a sprint”, “Our epics are 100 points”, “The login screen is our baseline of 3 points”, “Anything over 40 points must be broken down”.  So, I double dare you 🙂

Sprint backlog shape with high shared understanding

I have different view of the humble point. A point may seem like a one dimensional thing, but it has a some facets built into it.  One facet is the “amount of effort to build something”.  Another facet is “amount of ignorance” and this has an inverse – “amount of shared knowledge”.  Sometimes I find it useful to make a judgement based on what I don’t know as opposed to what I do know.  Regardless of whether I choose to view the cup as half full or half empty, I cannot estimate effort to build something based upon what I don’t know.  So, effort tends to track the amount of knowledge, not ignorance.  As knowledge increases, my ignorance decreases and each point starts representing more and more of pure effort.

However, if I am in a state of complete ignorance, then it is completely impossible for me to make any judgement on effort to build.  I’d be simply speculating.  What I can do, though, is create a time box to explore the unknown so that I can start moving out of my state of ignorance.  This is also an estimate and I am not making an excuse for non-delivery either.  I need to understand some things and also show my understanding in some code.  Yes, the code that I produce may not have a visible user interface or some other convenient demo-friendly stuff, but I need to carefully plan my sprint review to express my understanding.

It’s all about gaining a SHARED understanding. This understanding is body of knowledge that I have learned which I need to confirm with others.  This act of confirmation can happen in several ways.  I can have a conversation and explain what I understand, I can draw a blocks and lines picture, or show a spreadsheet, and so on.  Regardless of the method of communication, I still use the opportunity of discovery to express my understanding in code as tests.  Another powerful way of expressing my understanding is to write out a story and a few scenarios.  Using BDD style grammar can be a great way of concisely expressing some things, that can be easily shared.  Yes, you heard me correctly – as a developer, I write the stories and scenarios.  When I am given a story and scenario by someone and asked to estimate, then I am attempting to estimate based on  another person’s expression of their understanding and my assumed understanding.

In a recent discussion with Jimmy Nilsson, he said that he prefered to call scenarios “examples”.  That really resonated with me.  I also do a lot of discovery by example, and then gradually introduce more a more into the examples, as I get more and more confident of my knowledge.

How do I know how much I don’t know? That’s a tough question.  What I do comes straight out of my TDD habits.  I create a list of questions – my test list.  For some questions, I will know the answer easily, some not all, and some are debatable.  The more that I can answer, the better I can estimate effort.  I can then turn the questions that I can answer into statements of fact.  The more facts I have, the less ignorant I am.

Recently, I worked with a team that wanted to get TDD going, and the most significant change that I introduced was in backlog grooming and sprint planning.  During these two ceremonies, we (as a team) threw questions madly at a requirement, regardless of whether we knew the answer or not.  We then worked through the questions (as a team) to establish how much we could answer.  The trend that emerged was that the original estimates where either half of the new estimate or double of the new estimate.  When they where halved, it was generally because we were able to negotiate some of the unknowns (the ignorant areas) to a future sprint with the product owner.  In some cases, the product owner was equally ignorant, and was reacting to the “business wants the feature” pressure.  When they were doubled, it was so much more was discovered than originally assumed.  At the end of the session, we always asked the meta-question “If we answer all these questions sufficiently, will we be done?”.  I call this style of working “test first backlog grooming” or “test first sprint planning”.

Often I discover more things I don’t know. Annoyingly, this happens in the middle of a sprint, but if it did not happen in that phase of work, then perhaps I was not digging deep enough.  When this happens, I just keep on adding them to my list of questions.  These new questions are raised at any time with others on the team, the customer or with whoever can help me understand a bit more.  Sometimes, it’s put on the table for negotiation to be dealt with at another time.  Nevertheless, standups still seem to be a good time to put new questions on the table, for discussion later.

There are several ripple effects of thinking about points in this manner – this notion of ignorance and shared knowledge gauges.

The first is about the possible shape of your sprint backlog. If you have deep understanding, then it is likely that you will be able to decompose complex problems into simple solutions, that take less effort.  The effect is that low point stories are in greater number in a sprint.

If you are highly ignorant, then the estimation points reflect that and there are more medium to high point stories in the sprint.

The second is about what you value in a story. You will find less value in the ontology of epics, themes and stories.  It is no longer about size of effort but degree of understanding or ignorance.  Instead, the shape of the product backlog is something that is constantly shifting from high uncertainty (big point numbers) to high certainty (low point numbers).  That’s what test first backlog grooming gives you.

The third is about continuous flow that is the nature of discovery.  When you work steadily at reducing your degree of ignorance, then you are steadily answering questions through answers expressed in code, and steadily discovering new questions that need answering.  This process of discovery is one of taking an example based on what you know in this moment and modeling it.  Then expanding that example with one or two more additional twists, and modeling that, and so it goes.

It also touches product ownership and software development. When you work in this way, then explicit estimation of effort becomes less significant.  Moments that have been earmarked as important  points in the life of the product become more significant.  Call them milestones.  These milestones are strategically and tactically defined, and become a dominant part of product ownership.  Software development becomes the act of having long running conversations with the customer.  Those milestones give context for the content of those conversations.  Ultimately, those conversations are then expressed as a set of organised thoughts in code.  If your code is not organised well, then perhaps you also don’t understand the problem or solution or both.

This is a long story for a short message. A high priority is to resolve the tension that exists in an estimation in the form of knowlege/ignorance fighting against effort.  When you release that tension through shared understanding, then you can deal with the tension that exists in the act of creating those significant milestones.  In my opinion, that’s the real wicked problem.

Pass the Parcel

Posted on by

Fiona and I are planning Lia’s 5th birthday (27 July!) and a favourite kids’ party game is Pass the Parcel.  Kids sit in a circle, and there’s a surprise package with wads and wads of wrapping.  Music plays. Kids pass the parcel around. Music stops. Kid with parcel removes one layer of wrapping.  Music plays, pass it again.  And the last layer removed reveals the prize and that kid gets to keep it.  Do it once for each child, carefully timing the music and every kid is a winner 🙂
It reminded me of this business of tossing artifacts from once person to another in a development team.  In waterfall, it’s obvious who has what and what layer is peeled off when.  In fake agile(*), it’s not so obvious.  You know the music is playing when people ignore responsibility and toss it onwards or backwards.  The only difference, is that the party game everyone wins.  In the software game, everyone loses.

A few years back I sat in a class where Kent Beck explored XP with ten of us for a day.  For the first time, I realised that XP was less about coding practices and more about being decent people.  If I wanted to write quality software on time, on budget, etc. then I needed to have courage to accept responsibility for everything.  I don’t need to do everything, but I needed to feel responsible for everything.  No more passing the parcel, when it was convenient for me.  To do that, you need courage and respect.

Somehow, it feels like an Ubuntu coding thing again.  If you pass the parcel, make sure the receiver has good chance of winning the game.

(*) When the teams says they’re agile, practice agility mechanically, but don’t live by the value system which will make them agile in their heads.

Ubuntu Coding for your Friends

Posted on by

Last week I gave a domain driven design course and one slide I put up was titled “Coding for Friends” with a single message “Avoid conceptual corruption”. In other words “Code so I can understand you and you don’t screw up my mind”.  I did not realise the significance until I started working through the practical exercises with the groups and kept on referring back to this simple idea.
So often we write code in isolation and the code reflects our personal interpretation of the problem and a personalised solution too.  We easily forget that other people will execute this code, modify it, and, at the very least, read it.  Coding is a social exercise first, then a technical exercise.  We have a responsibility towards increasing the probability of success for the next person or team that will work this code.

We can write code in isolation that is of high quality, focusing on self and metaphysics of quality, etc.  That’s a zen view and it is about you.  I like to think (believe?) that Ubuntu is zen for a group, not for an individual.

In Zulu, the Ubuntu philosophy is summed up as

Umuntu ngumuntu ngabantu

which roughly translates to

A person is a person through (other) persons

And in geek-speak it is

A developer is a developer through (other) developers

I get better because you make me better through your good actions.  And the opposite also holds true: You get worse at what you do when I am bad at what I do.

How do we write ubuntu code?  It’s not hard.  It’s based on “old” principles and wise words of many people.  It’s old material but worth revisiting with ubuntu glasses on: when you think about what the effect is on other developers and what the reciprocal effect will be, back onto yourself.

Reveal your intention, not your implementation. If you have designed a project management app with tasks and decided to implement it as a graph, call the class Task and give it a method called resolveCyclicDependencies().  Don’t create a class Node with a method called topologicalSort().

Avoid side effects. Let a method do one thing, and one thing only.  It’s frightening how many developers don’t do this.  For example, if you add a line item to an invoice, don’t update the total.  Have something else that calculates the total.  Basically, be boring and predictable.  I long time ago a SQL guru looked at my code and said “The optimizer does not like fancy code”.  Same thing.

Broken metaphors. Metaphors exist for conceptual understanding.  Once you get the conceptual break through, leave it.  It’s ok! Trying to build an economic model with a metaphoric model of fluid flows (or bears and bulls!) will just create havoc downstream.

Where am I? Figure out where you are in the bigger picture.  Are you upstream or downstream?  Is someone going call my code to create that Book object? Am I going to call someone else’s code to get the Customer object?  In other words, know what you supply and what you consume.

Fail fast. Assert! It’s allowed in production code too.  I would rather fail quickly and dramatically than delay the effect until it is obscure.  More importantly, when I read an assert then I know that the particular condition is critical.  It is an invariant that must be honored.

Pairing. Programming in pairs is an active exercise, not a case of a second syntax checker.  I see many teams that pair mechanically and it does nothing for increasing code quality at all.  If you practice active pairing, you are closer to ubuntu coding.

There are other techniques which increase the collective responsibility of your design and code such as context maps in strategic design, values and attitudes such as responsibility and feedback.  I’ll deal with those on another day.

But for now, I think that

Code is code through (other) code!

Do you have any other ubuntu coding techniques? Attitudes?

One Hundreth Away from Fame

Posted on by

I read an article on the strength of the Finnish schooling system yesterday.  It’s considered as the best in the world with a 4% variance between the best school and the worst school.  How did they achieve that?  They give a lot of focus on the bottom 99% of kids in the classroom and not the top 1%.
I have a fear that as a community we promote the top 1%.  I hear developers being labeled such as rock stars and ninjas.  It’s no different to junior developers and senior developers.  We find all sorts of measures to be in the top 1%:  Twitter follower-count, Facebook friends, LinkedIn connections.  I think such labels and measures create an air of exclusivity and elitism to the detriment of 99% of the people.  NINETY NINE PERCENT !!

My 1% rankings have always been nothing more than a fleeting moment.  Once I won a book prize at school and I got an award for some design in university and meal voucher or two for a job well done.  It was meaningfully great in that context, relative to the others in that context.  But it was perceived as such by a few at that moment in time.

Looking back, I feel sad.  Not because of the scarcity my top 1% ranking, but by the reflection that those fleeting moments did not have lasting value to those that were in that context with me.  I should have made it count more significantly.  These days, I want to do things that touch others meaningfully.  Is my my code worth reading and from which you can learn?  Did our conversation over coffee move us closer to understanding each other?  And I want to be affected similarly too, by 100% of the people, not just the 1%.

Sometimes you’re in the top 1% and sometimes you’re in the bottom 99%.  But you will always be part of the 100%.  I am nothing, yet I am everything.

Writing Specs is Writing Code is Designing

Posted on by

A team that I am coaching has settled on using BDD stories and scenarios for describing their requirements and specifications.  They’ve also chosen cucumber as their acceptance testing tool.  All well and good, but they are making very slow progress and seem to be really struggling with the change in workstyle.  I think I’ve spotted the reason for this.
The feedback loop is missing.  They view the stories as a spec that has been handed down.  And they have not made the connection that spec writing is design work that is intended to clearly illustrates concepts in a domain.  It is a form of writing code.  But it’s just that this code is, maybe, non-executable.

Here’s my workflow and how I close the loop.

  • write story and scenario
  • Sketch a design if needed – helps when pairing to be on the same page.
  • Start writing test for scenario
  • ooops … test is getting complicated? stuck?
  • maybe the domain is not understood enough? Dig deeper, improve scenario, design (as needed) and continue writing test
  • or maybe the scenario was badly written? Ignore scenario structure, continue writing test.  Refactor scenario later.  We’re in deep discovery mode here.
  • get test to pass
  • refactor code
  • refactor scenario
  • … cycle the red-green-refactor until happy.

Acknowledging when you’re in discovery mode and knowing that you are allowed to refactor requirements is the trick.  Nothing is cast in concrete.  That’s why I like frequent feedback loops with tight turning circles.

No feedback loop, no progress.

BTW, I really don’t like explaining such things as flow-charts and sequences.  You got to find your own style.  It’s not a recipe or rules thing.  The above is something that is about as close to what I do but it changes when the need arises.  That’s also another key feature of being agile – adapt or die in the waterfall.

Ambler, Hundermark and now my Two Cents

Posted on by

Peter Hundermark has a nice summary of the talk on Agility at Scale that Scott Ambler did in Cape Town a few weeks ago.  And Scott had the courtesy of straightening out some thoughts on Peter’s blog as well.

Padding End Dates. End dates exist because of our immense desire for closure.  We cannot tolerate the thought of not knowing when something comes to an end.  So we would rather stick in a fake end date than no end date.  Are you prepared to stick an end date on your life, just so that you can create a finite sense for someone else?

Optimizing the whole. For me “whole” means everything, your workflow, your thinking, your architecture, your code, your communication, … everything.  But just drop into the code bit for a moment.  The reason TDD works is because it gives you feedback quicker.  It is not about the red-green-refactor process alone.  You have to be agile in your code and design too.  And linear problem solving results in linear code styles and mindless red-green-refactor results is not agile unless you are 100% immersed in the moment of exploration and discovery.  Overall, I think optimizing the whole, getting rid of wastage, lean, etc is all about finding the right balance – at that point in time, in that context.

BDUF. How much of upfront design is big design up front?  It depends on the context and the principles on which your software development is based and also who is affected by the software that is produced.  I like the phrase “little too much design up front” and “little too little design up front” which I picked up in this post by Kent Beck. (Please don’t acronymize that!).  That particular post was simple and extremely profound view, for me at least.

Just when I thought that I am making progress, I feel like a noob again.

Zen and the Art of Deck Building

Posted on by

Amazing! I just read Scott Hanselman’s blog post on finding geek balance outside of the geek world.  I started commenting on his blog, but realised I was blogging on his blog.  Here’s my own lumber-yard, geek-balance experience.
Just before Christmas, Fiona and I decided to have a deck built in the back yard.  I tossed the contractor’s quote out and decided to build it myself.  Why?  Same reason as Scott and I also specifically wanted to try my own personal Zen and the Art of Deck Building.  Fiona was naturally skeptical but indulged my mid-life crisis moment.

An apprentice in a world craftsmen.

DIY shops are intimidating.  I was an apprentice in world of journeymen and craftsmen.  I eventually found a benevolent craftsman who was humble enough to help me without judging me.  His ideas helped me simplify my design considerably and, more importantly, gave me some confidence.

Really listening to feedback. My paper design was a BDUF :-).  The moment I placed the wood on the ground, Fiona suddenly changed the location of the deck.  Short tale:  I am still building – new requirements still emerge from my main user.  Early on, I resisted every change with enormous annoyance which resulted in huge arguments.  Then I realised that the needs were real and the new requirements came from seeing how the deck looked with each step of construction.  I had an abstract BDUF and Fiona was taking in real feedback –  being agile!  And I was being rigid!

Living in the moment. I tried hard to live in the moment.  When I was digging a hole, I dug the best hole ever, deep, straight and true, until I hit a concrete block in the way.  Then my beautiful hole was a mess and I was angry at this block and tried to get past the block and continue digging my hole.  Zen moment – the task had changed.  I focused on the concrete block. Chipped away one tiny piece at a time, eventually it fractured and I could continue digging my beautiful hole.  I was focusing on the future, not the present and that screwed up my productivity.

Conflicts in collaboration. So I tried to live in the moment with everything from that point onwards.  When I was cutting wood – I cut wood and tried to get the best cut ever – to find beauty in the cut.  The one day my son, Khaleel, helped out and I got annoyed that he was messing up – it was not as beautiful as I wanted it.  After calming down and living a moment of fatherly guilt, I let him help me dig another hole and I just let him … to live in his moment.  He loved the texture, smell, etc of the sand and dirt.  I imposed my own hang-ups of not wanting to get really dirty.  I realised that he was more into having fun and I was messing up his fun – until I decided to live in the moment with him – by his values.

Finding the balance. Building the deck has been one of the nicest non-geek experiences in recent times.  It made me think differently, behave differently, regard people differently and maybe, one day, it will quietly help me build software better.  I think the trick is to find a place where you will always be the traveler in a world of benevolent journeymen.  And when you can’t find that world, then just be a benevolent journeyman in world of travelers.

Balancing craftmanship and methodology

Posted on by

Carlo Kruger commented on my last blog post with reference to Martin Fowler’s blog post which is a concise view of a crazy blog and twitter war around software craftmanship.  For some reason, Carlo thinks that my last two blog posts (here and here) fall into this space. Either Carlo is baiting a hook for fun 😉 or he misunderstood me. Nevertheless, my dear friend, I shall reply.
Martin Fowler and Dan North put the customer’s derived value from the software as the focal point.  The craftmanship movement puts the code that derives the value as the focal point.  I don’t feel comfortable about either.  It is unbalanced.  We always need balance.  So, what will provide an equally powerful balancing force to either of these two focal points?  I think it is the economic viability of the code base.

In Let scrum die, the key message is that Scrum should not be the end goal but a means to get somewhere better.  At some point it will outlive it’s value and I propose a moment in time when that will happen, and one way to force this (i.e. plan the exit of the Scrum master).  I also describe “talented developers” which, perhaps, feels like a craftmanship-esque thing.  It’s not about that at all.  It’s about the balance that is described in the next to last paragraph: developers will represent the interest of the customer, and the code base is under control (i.e. it is economically viable).  Balance the focus of methodology with an the economic viability of the code base.

In You can’t let Scrum die, I draw attention to this lack of balance that leads to complacency.  I mention two craftmanship things to do with the code – remove duplication and express intentions.  Again, it’s not about this alone.  It’s about the balance that is needed.  That balance is described in the next to last paragraph: look at yourself and look at what you create (i.e. the code base).  The reason why I say look at the person next to you is because the economic viability of the code that you create will affect that other person also, including the entire organisation and its customers.  Balance the craftmanship with the methodology which is balanced by the economic viability of the code base.  This reduces to balancing craftmanship with the economic viability of the code base.

There is one area where I don’t know of a powerful enough balancing force.  In Politics of Software Delivery, I draw attention to organisational power grabbing that will always result in non-delivery.  I suggest raising the importance of the delivery value.  But I think this is still too weak a force to balance the power battle.  I don’t know how to fix that one.

Footnote: Jimmy Nilsson reminded me of an article he wrote about why TDD, Refactoring, DDD, and all such things matter.