Tag Archives: agile

James the Shoe Shiner

Posted on by

A few weeks back I was humbled by about 100 graduates.  They attended an event called Level Up hosted by ThoughtWorks in Johannesburg.  I was speaking last and everything that I wanted to say was said by the time I stood up.  So, I went impromptu and spoke about why we change jobs, that a focus on design will see you through in the world of software, and that life is a cycle and we will do well to do the same as is being done to us right now to start our careers.

Then I rushed off to the airport, and the content of my improv talk hit me fully with stark reality.  When the airport is quiet, like it was that Saturday evening, I know that business is bad for the shoe shiners.  Here was James, the only shoe-shiner around.  It was 6.30pm.  He finishes work at 7pm.  I asked him how much short was he of his daily quota.  It was a slow day, he said.  I opted for an expensive shoe shine so that James met his quota.  I know that if James didn’t meet his quota, it is taken off his weekly wages.

James, it turns out, is from the Eastern Cape.  He graduated last year with a Diploma in Electrical Engineering.  He came to Johannesburg to get a job.  It is a tough job market, but he was finally offered a job.  But he couldn’t take it because the job required him to have a driver’s license.  Now he shines shoes to save money to take driving lessons, then he enters the job market again.  That job won’t wait for him.

My talk from half hour before of why we change jobs hit me hard.  In John’s mind, the only thing he needed was an education, and everything will work out.  Then he discovers these hidden constraints.  He changes jobs – temporarily, he hopes.

This moment has lingered with me for weeks and it clarified three things only today.

  • Indignity is imposed, humility is a choice.  To make a person kneel before another to polish shoes is an indignity.  That a person has chosen to polish shoes as the needs to an end is humility.  The work we do is not what defines us.  We define our work.  I have heard several agile coaches telling people that if they are unhappy, then they should change their company or change their company.  Most have changed jobs feeling an indignity that was imposed upon them.  I wonder, though, whether life would have been better when that same “horrible” job was embraced with humility.  I know sometimes we have to flee.  In my life, when I fled too quickly, the real issue was never resolved.  It just surfaced some time later.
  • Living in the promise of the future or the longing for the past is to live in limbo.  The past ends in this moment, and the future starts in this moment too.  We live in the present.  That is part of being truly agile.  Just changing jobs because of something in the past or the lure of the future somewhere else is to lose what we have in the moment.  It is not enough, though, to live in the moment.  To be in the moment demands an awareness.  Adjusting a course based on awareness beats reacting to stimulus.  Reacting to a stimulus puts us into a fight or flight choice.  Adjusting with awareness keeps us in a contemplative place.  Agility is about continuous transitions, each so tiny, that we can’t see the jagged edges over time.
  • Unexpected constraints take us into uncharted places.  James needing a  driver’s license is his unknown constraint.  Now he shines shoes.  We don’t know who he might meet shining shoes that may take his life on a different path.  Similarly, the truly agile team will embrace an unexpected constraint and look for opportunity in the uncharted beyond.  The process religious agile team will try to reject the unexpected constraint, fearful of the great beyond – like anti-bodies fighting a virus.  To be truly agile, we need to just embrace the unexpected as it pops up.  I see many teams attempting agile software development by just tweaking settings on known constraints.  That works for a short time only.  Our  software, after all, is only one requirement away from being hopelessly invalidated.

One shoe at a time, James’ life is changing.  James is agile.  Working with humility, embracing the unexpected constraint of needing a driver’s license, living in the moment, being aware of an empty airport and short of his daily quota.  That is how we should build software – living in the moment with awareness, letting it change our life daily.

I believe this is possible.

Many teams co-operate, not collaborate

Posted on by

At Agile Africa 2013, I presented a session about lessons learned living through apartheid to democracy and how this manifest itself in teams in which I found myself during those times.  Each period has many little stories, all relevant to the way we behave when we work together, especially in quite diverse teams.  I’m not going to focus on these stories, but rather on the main theme of that talk.  The slide deck for this session is available here.

The first time I spoke about this publicly was in 2010.  It’s taken me a while to articulate this particular aspect.  This is the first time I’ve written about it and I want to share that.  It is my take on a concept that I find is handed out too easily in agile software teams – collaboration.  I have chosen specific words to describe different kinds of relationships.  My usage might differ from their dictionary meanings.

Now let us start with the first period – the days of apartheid.

ContemptContempt

In the apartheid years of S.Africa we had a distinct “us and them” political and social structure.  It was whites holding a superior position over blacks.  It was only beneficial to one – those that held the superior position.

I call this kind of relationship contempt.  There is no trust between people and no shared values too.  The only value system that matters is that of superior.  This is a case of oppression.  It is the oppression of another’s values and identity and of freedom of choice.  Hence, we feel imprisoned.  The consequence of this is the under development of the oppressed.

When have contempt, there is no chance of working for mutual benefit in any kind of way.  It is just enslavement.  In software teams, I’ve experienced this overtly, without any facade or subtleties.  Some have been extreme cases, reflecting the bitterness of racism entrenched in our bigger society.  More common, though, are subtle situations of contempt.  For example, a developer considers another developer as less skilled – stupid to be precise – then we have relationship of contempt.  Architects and developers, managers and team – these are instances of “us and them”.  We can have such titles, but it is the attitude that arises when we build a culture where one holds themselves superior to others.

Co-operationCo-operation

In the early 1990’s South Africa entered a period of transition.  We were dismantling apartheid and building a new political and social system that ensured that we never go back to subhuman bondage.  This required enemies to find a way to work together for the survival of both.

I call this a co-operative relationship.  It is when both sides still retain their own values, but find a way to fulfil a common objective.  To achieve this common objective requires them to build trust.  I imagine trust as the payload carried in every action.

I sometimes explain it like this.  If we were renovating a kitchen, then the brick layer, the plumber and painter need to co-operate in order to complete the kitchen on time.  Each of them have their own work ethic, which is largely tucked away and insulated from the rest.  They need to agree on certain things like the bricklayer will complete the kitchen before the plumber can put in the taps, and the carpenter waits for the plumber before building the cupboards.  Should one not honour their commitment, then trust is destroyed because it affects the integrity of the others as seen through the eyes of the home owner.

This is the most common type of relationship that the majority of software teams practice.  We only need a co-operative relationship to build a reasonably efficient cross-functional team. Unlike contempt, people are no longer treated as inferiors.  Instead, everyone stands on their own pedestals of similar height.  The only thing that binds the team is the trust that comes from executing specific actions to achieve the common goal.

Most people call this collaboration, but I call it co-operation.  I can understand why we consider this collaboration.  It is the degree of trust that is necessary for this to emerge.  It is also reinforced by giving a team a name as a sense of common identity.  For me, that kind of naming leads to tribalism.  We gather to paint our faces in familiar markings, exhibiting the same brand.  Our behaviour becomes one of exclusivity than inclusivity.  It reminds me of the tribes that formed in the somewhat controversial book Lord of the Flies.  Pretty soon, we have intertribal tension.  This actually pops up quite quickly in multi-team Scrum implementations where all teams are working of a common backlog.  That backlog introduces real or invented dependencies between tribes, and so the tension starts emerging; just a shadow of first but easy enough to envelope all in darkness.

So, what then, do I consider collaboration?

collaborationCollaboration

After South Africa ushered in a new constitution, and successfully held its first democratic elections, the cracks started to appear.  We heard words such as “we need nation building”, “we are a rainbow nation”, and more recently “everyone can lead S.A.”.  All these words refer to one thing – we need to share a common identity.  That is what collaboration is for me – we have trust and now we focusing to share a set of values that exposes a powerful new identity.  It does not mean that we ignore or assume the presence of trust.  Our actions still carry a high payload of trust.  That never stops.

Building a shared value system is not easy, nor quick.  It is a challenge because each of us in this collaborative relationship have our own hierarchy of values.  Now we are being challenged to reconfigure personal hierarchies to overlap.  When we identify those intersections, then we are standing on the same pedestal.

When we work of a common platform – of even just one common value – then our basis for existence changes.  We stop becoming exclusive and starting behaving inclusively.  When a “stranger” walks in, seeking participation, then we look for that tiny tendril that allows them to plug into our shared values. Over time that tiny tendril grows stronger, and deep roots are planted.  Sometime the new person enlightens us and we expand our value system too.

What happens if that new person does not have that thin tendril that we can plug in?  This maybe a meta-value.  The one value that is necessary for collaboration to take root is that we respect all values; being prepared to explore the adoption of any value.  If we don’t have this single meta-value then we can’t bootstrap collaboration.  Without this meta-value we are unable to explore any value.  Collaboration comes to a halt.

The good news is that the each person does not have to have deep roots into the value system.  Tapping in lightly is enough.  The depth of the roots that are grown is tied to each person on that platform.  Those with shallow roots will move on to other teams that allows them to grow a deep root.  The period of time when they planted that root so shallow is still a wonderful time because we shared an identity.  That we cannot take away.  Inclusion is a way of growing.

When people anchor themselves deeply into the value system, we will find that those teams have a longer life. This is because we have a pathway to succession.  Having strong roots means that we create sufficient time for others to grow strong roots too.  In this collaboration, our sense of tribe is meaningless because the values will nourish and support generations of people.  Having a name becomes a label for the values that define us.

A closing thought agile adoption

I’ve tagged this with XP (extreme programming) as well as agile, and ubuntu – the zulu philosophy.  XP is what made me aware of the power of values in a team.  In my ignorance, I often attempted to instil values very early in a team.   I thought that I needed to build from a solid foundation.  It never worked.  I found that building a collaborative team is inverted.  We build the walls and the roof before we build the foundation.  The walls and the roof is trust that is needed, and the foundation is the values that are nurtured.

A collaborative team, as I describe it, is rare. It may take years to establish that foundation, with lots of corrections along the way.  That is ok.  That is the journey.  Enjoy it for exactly that.

Extreme Programming is as relevant now as before

Posted on by

Extreme ProgrammingLast year I met a few people that had never experienced a waterfall project.  Their first software project was with Scrum.   What stood out for me was that these developers had not read Kent Beck’s Extreme Programming.  I also discovered the same for several that were years into their agile development journey – never read the XP book.

Perhaps we are past the sceptical stage, and the notion of working in 2 to 3 week cycles is not considered so extreme any more.  XP may not be as popular as Scrum and Kanban at the moment, but it is still intrinsic to successful agile software development.

I confess that I find a lot of the XP practices are difficult and I have certainly not mastered any.  I think it might be simply that software development is just difficult.  Another reason may be that XP warrants that I change my approach, shifting my attitude to software development quite fundamentally.  That is the extreme part of XP for me, not the 3 week cadence.

Here are a few aspects of XP that I have grown to appreciate over time.

XP makes being a decent human explicit

XP has a lot to offer for the welfare of each person, and for our collective welfare too.  In a software world where we are learning to embrace our diversity, these insights are valuable for nurturing what is still a comparatively young sector.  Certainly, XP offers values.  However, just declaring a set of values does not mean that we live our values.  That’s where XP’s principles and practices kick in.  These exist to nurture those values.  Having a shared set of values and principles is essential in a team, because we use these to help us eliminate options and make decisions.  Value based decisions always seem like choosing the harder option, but the payback is often greater.

XP is about fine grained feedback

XP introduced me to the idea of feedback and made me aware of the theory of constraints – that we just shift problems around when we introduce or remove constraints.  Now we see the rise of lean which focuses on one piece flow, not short time cycles.  That is a different constraint and we have new feedback points like pivoting and waiting until  the last responsible moment.  All these require explicitly designed feedback paths.

Producing a piece of software with one piece flow means that we must bake the feedback into the software we produce.  For example, if we redesign the landing page for a web site, then we need to bake in measuring page views and time spent on the page as part of the release.  Without explicitly thinking about how we receive feedback, we just end up producing a chunk of software that has very little value.  Once we have feedback loops baked in, we are back to observing the shifting of constraints.

XP practices such as continuous integration, collective code ownership, simplifying vigorously, small and frequent releases all aid in building precise feedback loops.  These practices directly support one-piece flow, devops, and continuous delivery.  Yet, most people are unaware that some of these practices are there to increase collaboration.  For example, when there is a problem in the build pipeline, then people will swarm to fix the problem.  It is the high signal conversation after the failure that is valuable.  XP helps increase the signal to noise ratio in our feedback  loops.

XP is not just process centric

As a developer, I am yet to find a set of practices that appeal directly to my work at the most basic level – working with code.  I’ve noticed that many teams that embark on an agile journey tend to focus more on an agile process, than their code base. After a while their code base becomes their biggest bottleneck.  Not obvious is that the potential to regress to a waterfall-like development process is high.  When we have little control over the code base, then we may well reach for more grand planning upfront, less frequent and larger releases, and longer testing cycles.

The code base becoming a bottleneck is not an event that suddenly happens.  It is an accumulative effect.  It sneaks up on us.  Some symptoms are a drop in throughput; it becomes more painful to build, release and deploy; and introducing a new feature needs design contortions.  I’ve referred to this before as “trying to sprint in mud”.   We expend a lot of energy, without going far.

The consequences of a code base out of control is the real kicker.  The code we write affects everyone, not just developers and our customers.  It introduces stress to everyone associated with the software – analysts, managers, customers, family and friends too.  That’s why in XP there are practices that help us keep the code malleable, interwoven with practices that deal with our collective welfare.

With a code base out of control, we can forget  about one piece flow, lean style.  The same goes for continuous delivery and devops too.  Even with the best build pipeline tools, a badly managed code base will not make life easier.  It is like using really bad quality ingredients to make an exquisite meal.

XP keeps a focus on design all the time

XP introduced us to test driven development and continuous refactoring to keep our code bases under control.  Some people use test coverage as measure of that.  I don’t subscribe to coverage as a measure of control.  I prefer weighing up the cost of defects against cost of releasing late.  For example, if getting a feature out means securing a market position, then I would go for lower coverage because releasing late will hurt more than releasing early with defects.  This might be a controversial statement but it is still a viable feedback option.

By the way, it is worth noting that TDD does not yield good designs.  Instead, it raises warnings of problems with our design.  Good design comes from another XP practice of always aiming for simple designs.  Simplicity comes when we gain deep insights into the domain.  Acquiring knowledge takes time – it is a slower feedback loop.  Consequently, achieving a simpler design occurs slower than churning out software at the end of each cycle.

XP allows for code first agile adoption

I prefer to emphasise getting the code base under control as my main target in an agile adoption.  I lean on XP heavily for achieving this goal.  Along the way, the people and process aspects slot in quite naturally.  As the code base is brought under control, it creates breathing room to introduce other non-technical practices.  I’ve found that it is less painful to focus on the code base first, XP style, and slot in other practices along the way.

When I’ve tried it the other way – process before code – I’ve experienced a kind of agility that is only skin deep.  The reason is that the act of adopting the code centric practices requires significant change in developers.  Until developers embrace changes in themselves, in the way they approach coding, the agile adoption will remain superficial.  By “superficial” I mean that it does not penetrate down to the code itself.

Superficial agile is not a bad thing.  I know of some organisations that will benefit from this approach, but only for a while.  For some, that is sufficient.  If we really want to go beyond skin deep agility, then I think it is necessary to reach for XP’s practices that deal with code.  There really is nothing else that deals with writing code in short cycles or one piece.

Should you read Extreme Programming?

My answer is a resounding yes.  It is a wonderful book, written with a lightness and easiness.  Yet is dense with deep insights in every sentence.  The one last aspect of XP that I cherish is that I could ease into to it slowly and deliberately.  I did not have to apply the entire body of work instantaneously, in one huge swoop.  And I am still easing into it.

Why am I poking SUGSA?

Posted on by

I’ve been taking a poke or few at SUGSA on twitter in the last few weeks around the2013 South African Scrum Gathering.  It’s time to put it into perspective.  My proposal to present a session at the conference been accepted and I have declined this acceptance.

This is not news to the SUGSA committee.  I have communicated my
decision and my reasons to the SUGSA committee.  I have also had
one-on-one discussions with a few committee members.  I am satisfied
that the committee has received and digested my reasons.  Individuals on
the committee have assured me that my feedback is in line with their
values and that they aim to address it in the future. 

My poking is just me pressuring SUGSA to recognize a few issues which I believe are important to our community, and to force the committee to address us on their position.  Tell all of us, not just me, of your position and we shall listen.  That is all, no more, no less.

These are the issues that I raised with SUGSA.

  • African conferences need to be representative of our community.  One way is to nominate an African keynote.  It will take a courageous decision but it can still happen.   Agile Africa responded symbolically very late and it was fantastic.
  • We must embrace our diversity and find ways of breaking the polarised community that exists in Cape Town.  I think the people from Cape Town that attended Agile Africa in Johannesburg were surprised by the diversity of speakers and audience at that conference.
  • Be transparent with the review process.  The committee needs to maintain its independence and having committee members occupying several speaking slots sends the wrong message.  I’ve seen that in other communities where the committee became the soapbox for individuals.  If I was on the committee, I would withdraw my proposal on principal.  I know of one committee member that did this.  Thank you for taking a courageous step.
  • I also questioned the expertise within the committee, especially for technical submissions.  That is my perception and there is every chance that I might be wrong.  I welcome the correction. 

This is not a boycott.   I will still attend as a paying conference attendee.  I appreciate the
learning I receive from this community and look forward to more of the
same.

I believe my issues have been heard and my actions, seemingly harsh to some, was necessary.  I still want SUGSA to take a position publicly and I leave it them to figure out when and how.  The SUGSA committee have invited me to discuss this further and  I look forward to that.

Thanks go out to Austin Fagan, Sam Laing and Karen Greaves who gave me perspective to resolve a few internal conflicts, and shape my thoughts on why I am doing this, and what I expect out of it.  Had they not given input, this could have been unnecessarily ugly.

Live with it for a while

Posted on by

Before I rush off and refactor my code, I like to live with my code for a while. The refactoring I do in the TDD cycle is to get rid of trivial duplication and, perhaps, some better naming. I deliberately delay extracting methods and classes and pushing up or down. For me, those are quite important design choices, and I want to make those decisions only when I have a good understanding of my problem.

What do I mean by “live with it for a while”?  Literally, I leave it alone and move along to something that is in it’s vicinity.  I choose something that is close enough that will need to interact or modify the “living-with” code.  This new use case, scenario or question is to further my understanding of the problem and  I choose it deliberately. If it turns out to be tangential, I don’t sweat it. I just pick something else that will move me closer.  The fact that my first choice was poor is always valuable insight into my lack of understanding of the problem.

Aside: The
simplicity of my solution is directly related to my depth of
understanding.  The deeper I understand the problem, the simpler I can
potentially get.  Shallow understanding leads to more complex solutions. This takes time, and “living with it” gives me freedom to play with the problem from several angles.

I don’t mean “ignore it after a while”.  Ignoring it is like noticing a crack on your lounge wall and after 2 weeks of doing nothing about it, you don’t see it anymore. So, living with my code is not giving myself permission to be sloppy.  It’s deliberate choice to look for a better, simpler solution as I increase my knowledge. Once I have a bit more knowledge, I can start making more adventurous design decisions.  I think it’s almost impossible to find a simple solution if you don’t have deep domain knowledge.

It means that I refactor a little at a time frequently.  Even if I know my code is not clean, I’d rather have a pulse for my code, and let it beat weakly.  All I’m doing is constantly looking for little things that will make that pulse beat a bit stronger.  I now realize that I refactor a little at a time, but almost continuously. I’m not searching for clean code. I’m searching for markers in the domain that confirm or refute my understanding.  The clean code will come with time.

Living with my design for a while has saved me lots of time, especially when I’m not confident of my knowledge of the problem.  Give it a try and let me know whether it works for you too.

Cape Town’s latest agile development course

Posted on by

I got my first break as a software developer about 20 or so years ago.  It was the first time I heard that a table can have keys. That start put me on a career path that I never anticipated, but is thoroughly enjoyable.  And now, finally, I’ve finally got a chance to give back in a way that shows my appreciation for what was offered me all those years ago.  For those of you who know my history (or just peeked at my LinkedIn profile), you know that I’m talking about KRS.

So, I’m quite thrilled to be a contributor and collaborator for their Advanced Agile Developer course.  The inauguration course happens on 19 November. That’s not much time, so book a spot quickly.  I don’t want to give too much away, but I can tell you that it’s going to be fun, intense, and inspiring – and seriously code centric.  There will be times when you will feel like you just don’t know how to code anymore, and then feel like you can conquer the world.

I think this is a course with a difference.  We want to bring together developers that are already competent at writing code and want to become proficient at being agile developers.  We made a big decision to go deep, and not skim the surface of lots of topics.  The result is a course that is very code centric, working at quite an intensity that passionate developers will find inspiring.

Working with Lorraine Steyn and team KRS has the same warmth, openness, and security from 20 years ago. This is something that I know they will bring to this course in a way that I can only hope to, someday, emulate.

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.

Product Ownership Webinar

Posted on by

On 12 May 2011 I will be joining Kent Beck and Henrik Kniberg in a free webinar hosted by SD Times to take a deeper look at product ownership as described by the Scrum methodology.  I think we all have a lot of questions, especially Kent, but I will also put forward some things that I have tried and some opinions of what I think should be tried. As usual, I welcome critical comment.
For a long time I have been wary of the way product ownership is “taught” in CSPO courses, and the way it is implemented in Scrum teams. I think the fundamental tension of product ownership is not being addressed.  So, at the heart of my talk, I want to explore the tension that a product owner needs to resolve and, maybe, some ways of resolving that tension.

Regardless of whether we offer workable solutions, I think the webinar will raise questions that are well worth discussing in larger groups.

Rolling out a methodology is about design

Posted on by

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.