What’s the point in Scrum?

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.

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.

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!

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.

(A)

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

(B)

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

(C)

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.

Readability is the real (re)usability

Last week on the factor10 DDD course in Cape Town, the question of reusability came up again.¬† It’s the same old object orientation promise of “Just do OO and you get phenomenal reuse for free”.¬† Today, I was refactoring some code with another developer at a client and I extracted some lines into a few private methods just to clean up a really fat loop.¬† The initial reaction from the other developer was “That’s an overkill because you won’t reuse that method”.¬† My spontaneous reaction was “Readability is the real reusability”.
It’s true, the method won’t be reused.¬† It’s also true that most us were taught in some Programming 101 course that you should create a method, function, procedure only if you are going to call it more than once, otherwise just leave it all inline.¬† I value ubuntu coding, and so I have learned to unlearn that naive rule.¬† When I make my code more readable, I get more reuse out of it.¬† The reuse I value is not really about the number of repeated method calls or number of inherited classes.¬† I value the increased reusability that is achieved when more developers are able to read my code and walk away understanding my intention, clearly and unambiguously.

Let me put it another way.¬† Your code is a representation of your model.¬† Your model should be used to drive all collaborative discussions about the solution.¬† That’s where you get the real reuse in your model.¬† If people can’t understand your model, then your model can’t be re-used for further discussions.

Ubuntu Coding for your Friends

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

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.

Wanted: Muse. No experience needed.

Artists have muses.¬† Muses are their creative inspiration.¬† The Greeks also called it a daemon – that mythical thing that gave magical creativity.¬† It’s actually their genius spirit that helps them when they’re stuck in a metaphorical tight corner.¬† Same thing, I think.¬† So when did we stop having geniuses and became geniuses?
I think I am actually searching for a muse.  Something that will be my creative genius.  I gave up trying to be a genius a long time ago.  Now I just want to learn from those that are better than me, whatever the context.  Maybe my muse is the sum of every engagement with the genius in each person with whom I work and live.

Continental Shifts

I see many people freak out at the mention of any change.  I often do that too.  Why?  Because it forces me out of my comfortable existing neural wiring.  Now I try to view change as a contextual adjustments and a little bit of re-wiring for comfort sake.
Hmmm, as I age, I think the slight contextual shifts that I go through now feels less like the massive catastrophic continental shifts.  Much nicer.

Learning Rules for Noobs

The unfortunate human characteristic in all of us is that we like rules when we’re in a new and unfamiliar situation, and hate them the moment we think we are experts. ¬†The problem is that rules are great for creating concrete things. ¬†If you want to¬†build this then: do a, then b, if you have a c then do d otherwise do e. ¬†But it does not work with creating abstract things. ¬†And¬†software development is all about building abstractions.
In the past few weeks, I’ve had a few instances where I¬†realized¬†that some people were, ¬†basically, asking me for DDD rules – steps for building an aggregate, when and how to use the specification pattern, etc. ¬†There are no rules for the noobs for these things. ¬†But I think I can constrain the environment so that the noobs can focus a bit more intimately with these aggregates and specifications. ¬†¬†¬†One rule I put down was “When working with the following … don’t work outside of this Java package”

Essentially, my proposition is that rules for noobs should constrain the learning environment, not the subject being studied.