The Anti-Programmer

When I think back to my more hands on development days earlier in my career, if someone asked me what my job was, amongst other things I would have said….


  • Add features that provide business value
  • Write code to provide solutions to customers problems


Both of these statements include adding something or providing my input in order that someone else (the customer) gets value out.
This is not what I have been doing more recently. In the last couple of weeks and ongoing I have been removing something or retracting someone else’s input in order that someone else (the customer) gets value out.
Surprisingly and maybe counter-intuitively this has given me great pleasure.


  • I have been deleting code.
  • I have been removing excess complexity.
  • I have been reducing the number of features in a product.


This is why I have been an “anti programmer”.
This is certainly what all programmers or engineers of any system should be doing, and this gives me as much pleasure as adding to it does.
This process still involves the same amount of rigour and control. Whether you are adding or removing code you are still making changes to the system so you need to have the controls in place to ensure that you haven’t changed the system in a detrimental way.

This process has benefits both internal and external to the business.



All code that exists contributes in some way to its complexity. When a developer comes up to speed on an area of the product or code base they will have to understand why that code is doing what it is. Hopefully this will be fairly easy to understand but there will be a degree of ramp up. Less code can mean less to understand and therefore less complexity.
The testing of this code manual or automated will also incur a cost. Manual testing will involve the team understanding the feature from a users point of view and even automated tests however quick will add some delay in the feedback loop in the time it takes to exercise those tests.



The customer sees this feature and wonders how it would be useful to them. “How can i use this software to add more value to my business?”If there is more than one way to solve a problem using your software they may spend time deciding which one is best.
Pruning your product should be a constant process. A feature may have had been adding value at some point but as the software grows over time this may not always be the case. Constantly looking and measuring your customers usage of your product overtime will hopefully highlight areas that are no longer needed or marginally used. These unused features become a from of waste like the dead heads on your rose bush. These should be pruned/removed/retired/culled however you want to phrase it.

There’s a great sense of relief in removing unused features and it should be encouraged.

Keep it Lean.

Outsourcing Recruitment, a Necessary Evil


There’s sometimes a bad feeling about having to outsource your recruitment. Maybe a feeling that you’re paying for a service that you could be doing yourself, and that you’re paying over the odds for it with fees. I have also heard people equate their relationship with recruitment agents to their negative experiences with Estate Agents. As a middle man trying to get the best for both sides and take something for themselves, there’s often a feeling that nobody wins.

With all the trepidation comes a reality, a reality that your business has decided to take this option and there maybe many perfectly valid reasons why they have chosen to do this.

  • Your HR department do not have the capacity or skills in your industry to effectively bring in the right candidates.
  • You need to scale particularly quickly and you need access to candidates on the market fast.
  • You’re looking for a niche or high end market of candidates which is expensive in time to find.

I’ve seen may people take this common approach to scaling their teams but they have failed to invest further time in making it a success. Upon taking this approach and receiving the wrong candidates or getting a lack of talent through the door they have laid the blame firmly with the recruitment agent further perpetuating the bad feelings of this experience.

I think this is wrong.


You only get out what you put in.

If you’re looking to outsource you recruitment because people aren’t breaking down the door to get a job with you then its likely you’re operating in a competitive market. As the agent is representing numerous other companies possibly in your space what are you doing to make sure that when they find a good candidate they are promoting your business over everyone else? Equally, with several options on the table for a good candidate what are you doing to make sure they come to you?


Build a Relationship

Getting to know your agencies is very important. Most of your relationship like many suppliers will be conduced by phone or e-mail. An initial meeting is essential. This is often done over the phone, but I think to really build this relationship you need to meet the them face-to-face. Putting a face to a name for all those e-mail, phone, faceless conversations is paramount. If this is geographically not possible, then use Google Hangout, Lync, Skype with video to ensure they know who you are and build that rapport. This meeting should not only be a chance to find out what they can do for you and how you can best work together, but also your chance to sell. This might seem counter intuitive as you think they are the one vying for your business and maybe this is the reason why it falls down so often.


Sell, sell, sell

It’s time to differentiate yourself. Why is your culture, company, position worth the best candidates. Think outside of the specific role for which you’re hiring. What is it about the department in which the candidate will work that makes it attractive? what about the company as a whole, what’s the strategy, growth, the future? All of this may seem overkill, but if you can enthuse and sell your company and the role as a great place/position to work to the recruitment agent then they will find it very easy to sell it to your potential candidates.



Now the recruitment agent is singing from your hymn sheet and your biggest promoter there’s still more you can do. Give the agent the tools to allow them to sell your position and company effectively. What marketing material can you provide? Company blogs, recruitment video, team social media handles, biographies. What can you provide the candidates that will make you stand out and for them to remember you?

All of this maybe redundant if the candidate is not what you’re looking for, but its worth using the recruitment agencies to do your marketing for you. What if that candidate went away and grew their skills and became what you always wanted? Why would they remember your company and why would they want to re-apply?

All of these suggestions might not be possible. You may not be prepared to invest the time in this process, and if you don’t, don’t expect to get as much out. You need to find what’s right for you in terms of cost and effort, but the chances are you should and can be doing more.

Give me some slack

I caught a great interview this week with J. B. Rainsberger. In this interview he gave to Marko Keba of, J.B. talked about managing slack. Naturally this got me thinking about what I do within my team to create this slack. If you want to listen to the interview that inspired this post then it may still be available here and its well worth a listen.


Why slack off?

In the interview J.B Rainsberger spoke about how creating slack and performing tasks that are not directly attributable to features with business value can help reduce volatility in the cost of adding features of time. By working at full capacity continually your teams will not have time to improve or maintain their productivity. The code design if not maintained and nurtured over time will exponentially decrease causing features that seem relatively simple in complexity to become bloated and far more difficult to implement than expected. This will clearly effect both developer productivity and your teams ability to react to the market, delivering business value into production quickly.


What slack should consist of?

J.B  doesn’t go into details around what practices or tasks should be performed within the slack as these will be specific to your environment and business but he does mention techniques such as Value Stream Mapping to identify where the problems are, where the bottle necks occur and where the extra work is hiding.


How we negotiate managing slack

The tasks that you perform and how much time you spend doing this as developers should always be negotiated. You will need to justify your investment in these tasks and learn how to sell these ideas to your Product Owners. Hopefully your Product Owners will already have an awareness of the pay-off that this can give but just in case, you will need to be prepared. This may be a challenge as the immediate paybacks may be difficult to see.

My approach to this was to negotiate a percentage of time each sprint, creating slack to perform these tasks. By doing a small amount every sprint you reduce the impact on your teams velocity as the velocity will naturally balance to the incremental effect. This also brings about a metronomic habit to continually take care of your code base, call it gardening if you will. The iteration based pruning is far better than a big bang approach wiping your team out for an entire Sprint as the big bang approach is not sustainable and the important part of providing slack is that it is a continuous process. Additional benefits come naturally with all processes that we do in small batches.


What activities are we doing when we are slacking off

As the team go through their daily work they should be automatically recognising work items that would be considered technical debt. These items often build up as a result of not having any slack, going too quickly or a concious decision to take short-cuts in order to deliver on schedule. (Reduction in quality over time or scope) These items are prime examples to improve given some slack. Your team may already have a backlog of these items.

In the same way we refine the backlog our team refines the event log messages. The event logs are one of our views on the health of the system so it is important that we can judge this at a glance. Removing false positives and re-prioritising warnings to errors and vice versa are all things that can be done to improve the system both for developers and for our operations team. (DevOps). Refining these items highlights work that needs to be done. This work is not always seen as being directly attributable to business value and is therefore a great item for slack.

Tests should always be considered production code and in the same way you will build up technical debt in your test code f you don’t continually take care of it. During time set aside for slack testing is a great spot to tackle. Improving the readability, reliability, coverage or general design are all must dos when slacking off.

The more often you give yourselves time improve the easier it will be and the less likely you are to fall into the trap of bloated estimates and never ending stories.


Tasking Stories

I had an interesting conversation last week about what our teams perception of a task, story and chore are and the differences between them. This then led to a discussion around task breakdowns and whether these were necessary.

This got me thinking………I’d never even considered this before, breaking a user story down into tasks is all I know. It’s like I’ve grown up with it. I never like to do things just because that’s the way were always done, like in the Pot Roast Story, so this gave me the ideal opportunity to lend it some thought and consider why I think breaking down a User Story into tasks is important.


What is a task?

A task is a small unit of work that can be literally or theoretically sized between minutes and hours. (I won’t cover the pros and cons of sizing tasks in this post) The task falls at the bottom of the natural breakdown hierarchy

Tasks make up the smallest visible piece of the puzzle. It’s important to note here that tasks do not form any unit of business value, they are a list of practical things that need to be done in order to deliver the User Story as a unit of business value.


How does it fit into the Story process?

As the smallest piece tasks form the final piece in terms of identifiable work, therefore they often come at the last most point before work begins. This maybe at the iteration/sprint planning or may take place at a User Story kick off meeting immediately before the first task would begin.


Who does it have value for?

The mere existence of tasks has value for everyone immediately involved in the process including the developers, testers, scrum masters, product owners. This may also apply to any stakeholder depending on how close they are to the process. You may think that this is odd and that the User Story breakdown has no value for anyone other than the people working on the User Story, but there are 2 sides to this; the act of breaking down the User Story and the Visualization of this broken down work. Each side will have benefits to different sets of people.


Breaking down a User Story

The process of breaking your User Story down into tasks provides a collective and common understanding of the work that needs to be done. The discussion and review of the tasks can create further conversation on the scope of the work. If you choose to estimate tasks, whether or not you use that for planning or not, this may also give you an indication of how valid the estimation for your User Story was. This process add value for your team and the Scrum Master.

Tasks can also form non-code-specific items such as questions that need answering, assumptions that need validating or business as usual operations that you want to remind yourself to do as part of your delivery process. Tasks are a great way to achieve your definition of done. Without noting all of these things down whether they be on stickies or part of a check list they are a great way to make sure you have not forgotten anything.


Visualising your work

The second part of this process is visualising your work ( a key tenet in Kanban). By displaying your tasks in a visual way you are able to see the progress of the story as it moves through to completion. This is effective whether you’re using a Scrum Board or a Kanban Board.

The granularity of the tasks enables a Scrum Master to aid the team with their impediments and recognise bottlenecks without the need to rely solely on the teams feedback throughout the day. The board is always in the same place (hopefully) and your team as they move around and collaborate are not.

If you’re using physical boards and stickies the tasks also allow conversations to arise during the stand-ups where, just like index cards, team members can point, move or generally gesticulate at the specific items they want to talk about making it clearer to the rest of them team.

There are other ways of showing the progress of a User Story and maybe questions about whether people need this information at such a granular level, but on an information radiator this information is made available to all stakeholders and gives clear transparency whether they choose to use it or not.

Tasks are not compulsory by any means. They have some great benefits with little overhead and it works for me.

It’s not what you Scope but what you don’t Scope

The following post was originally published on an internal blog on Aug 15, 2013

“Music is the space between the notes. It’s not the notes you play; it’s the notes you don’t play.”
—Miles Davis

This quote came to mind recently when I was reading an article on the Agile Warrior blog. The post talks about a tool claimed to be developed at ThoughtWorks called the Inception Deck. This tool provides 10 questions to ask at the start of your project to set it up for success. Think of it as a process to gain clarity on why you’re doing the project when chartering and making sure you have the right people and objectives in place.

Although this tool maybe more applicable to an Epic or high level programme management there was one point that struck a chord with me and something which I think we overlook when planning a story in a Sprint.

Something I have seen reoccur are bugs being raised or Stories being rejected due to a confusion or a lack of cohesive thinking on what a feature should and should not do (Its Scope). We all approach the story definition with a range of assumptions and these assumptions are often around what the feature should and should not do and here in lies the challenge.


How do you remember to write down everything a feature should do?

One of the ways in which we can do this is by pining down the “Can Do’s” by defining the “Can’t Do’s”. By doing this we set a perimeter, defining the boundary, making it clear where the “can do’s” end and the “can’t do’s” begin. When we plan a story or define scope it’s not necessarily what the feature can and can’t do but what should and what should not be in scope. After all, if everything else is fixed, scope is the one thing that can be flexible. What aspects are you planning to change in the given piece of work? The Inception Deck describes this process as below.


Saying yes is easy. It’s saying no that is hard. The NOT list starts to put some stakes in the ground and to set expectations around what you are not going to be doing as part of this project. Saying what you are not going to do is powerful. It eliminates a lot of up-front waste by letting the team focus on the stuff that is clearly IN while ignoring everything that is OUT. It is from the IN column that all of your high-level user stories will flow. Also, it’s not uncommon to have a lot of things that could be in scope but for whatever reason (usually time and money) aren’t. Better to resolve these now than to leave them till later.”


The idea is that you draw 2 circles, 1 for IN and 1 for OUT (of scope). During the discussion people pitch in elements of the feature that they think are relevant and you place them inside one of the circles. If there are area’s or elements that are unknown or are a risk you can place them outside of the circles as a reminder that these need to be followed up on.


I thought this was quite powerful and useful for Story Kick Offs or Story Planning. I can remember times where we have wasted time replicating, repeating and raising bugs in area’s that we never meant to be changed and after a conversation around a pink sticky (for Story defects) on the board the following day, agreed that it was never in the scope of that story. This was clearly a form of waste which we could have prevented by communicating more clearly.

This aids in supporting Mike Cohn‘s 3 C’s of story writing:

  • Card
  • Conversation
  • Confirmation

The realms of what is not in scope are potentially infinite so there is still a level of assumption or rather common sense involved. However, writing this down and making it explicit appeared to be a much better communication of what we were setting out to achieve within a Story. If you decide to give this a go let me know how it turns out and what improvements or tweaks you made along the way to improve it.

Happy, Sad, Ideas, Thanks – A Retrospective

2014-03-28 11.20.39

I’m lucky enough to be part of a team that are open and honest. That’s not to say there’s not room for improvement, but they’re open and honest enough to tell me that our retrospective format is becoming a little stale. In theory I should have known this already. Alarm bells should be ringing when the actions for improvement start to dry up. I could have abandoned retrospectives altogether claiming that the team couldn’t possibly improve any more. Instead I tried some new ways to get the team more engaged and varied the format a little. This week we tried the Happy, Sad, Ideas, Thanks format.


The Setup

Using a whiteboard, flip-chart or large piece of paper on the desk, divide the area into 4 with perpendicular lines. Label each quadrant happy, sad, ideas and thanks. To clarify these are:

  • Something that happened that made you happy.
  • Something that happened that made you sad.
  • Ideas you have to improve the process.
  • Thanks you want to give someone for something they did.

I asked the team to write stickies and place them in the relevant quadrant. The team generally know what things to write on the stickies but if your doing retrospectives for the first time you may want to place constraints around what is suitable offering examples as guidance. In this session I gave the team the freedom to add as many stickies as they wanted and did not specify any limits on each quadrant.

We then briefly went through each sticky on the board allowing the team to clarify what they meant and why they placed it in the given quadrant. This gives the team the opportunity to have a shared understanding of each of the points. At this point we didn’t go into too much detail and discussion, but just enough to know what each sticky was about.



There were a few things I tailored in this format to suit our team needs. Firstly, I asked the team to dot vote the stickies to ensure that the ones we talked about were the ones most important to the team. Depending on how much time you have and how many stickies you need to get through, you may want to do this. I then ordered each sticky in priority order within each quadrant.

As well as prioritising which ones were important to the team, this also allowed the team to get up and get moving around by adding their dots to the stickies creating any further clarification amongst the team that was not covered earlier.

2014-03-28 11.12.40

The other tailoring was excluding the ideas quadrant from the dot voting. The ideas I wanted to make sure we discussed so these were automatically put to the top of the priority list. The ideas quadrant give you your best chance at coming up with concrete actions to improve the process.


What went well?

The one part of this I really liked is the quadrant for saying “Thanks”. It is often assumed that this naturally happens amongst the team, and sometimes it does but this allows a great opportunity to give direct feedback to your peers and recognize them for something they have done. The recognition is a great way to encourage your team to say “Thanks” more often, but also to encourage the continued behaviour that led to the “Thanks”.

This format is easy to set-up and facilitate so makes it easy to run and is a great entry level retrospective, particularly for new teams who are beginning to discover their ability to inspect and adapt.


What didn’t go so well?

As a Scrum Master you always want to improve. This can often lead to focusing on the elements that they were sad about. In this session we spent some considerable time focusing in this quadrant only to find out that although the team were unhappy about these items their degree of unhappiness was on a scale. Had we evaluated this scale of unhappiness immediately we could have focused on other items for improvement.

The retrospective format itself didn’t bring about any devices that helped the Scrum Master get beneath the surface which meant that this was largely down to their experience. This will naturally depend on the teams (Agile) maturity so some guidance may be needed to focus the team on improving process rather than items such as “We made good progress on X”.


What would you improve?

As mentioned previously their are scales of emotions and I think its useful to gauge this in some way. This could be by asking the team to rate their scale of emotion between 1 and 10 on the stickies for happy and sad allowing you to discuss your discussions on the right areas.

If you find that the team are feeling particularly pessimistic or downtrodden and all the stickies are placed in the sad quadrant you or the team are struggling to generate ideas for improvement you may want to limit the number of stickies per quadrant forcing the team to think about each quadrant.

2014-03-28 12.10.36

Visual Kata – Deliberate Practice

Over the past year I have seen a number of people on Twitter sharing these great pictures and visual sketches of talks they had been too, or processes that had been described to them and I always thought to myself, I wish I could do that. The visual nature really appealed to me even though I have never considered myself an artist.

It’s only been the last couple of months or so where I have learned that these pictures are referred to as sketch notes or graphic recordings and what caught my attention was Lynne Cazaly notes at Agile India 2014 and Nhan Ngos sketch on Continuous Delivery shared by Jez Humble


But I Can’t Draw?

No, neither can I, but following up on my interest I purchased several books on “sketch notes” to find out more and they all started with the same premise.

“You don’t have to know how to draw”

Great! that’s me then. I have never considered myself being able to draw and if anyone would ever put me on the spot and ask me to draw something I would have frozen pen in hand. In private and within the confines of my notebooks all I ever was was a doodler and that’s still not changed. I just have a different reason to doodle now and that’s to communicate my thoughts to others.


Your Visual Library

Mike Rohde author of The Sketchnote Handbook: The Illustrated Guide to Visual Notetaking and Dave Gray refer to a visual library. In the same way we have a series of primitive symbols that make up our alphabet, which we can use to assemble a whole language of words to describe almost anything,  the visual library consists of a series of known icons or glyphs that can be used in the same way to describe ideas and concepts. This isn’t the same as drawing. The skills in being able to draw allow you to apply your art to any object or scene and draw whatever you see in front of you or in your imagination. The visual library is a finite set of things that can be used on their own or in conjunction with each other to emphasize a concept or illustrate part of a story.



Building up this library requires practice, repetition and imitation. By deliberately practicing these icons you can develop your own style, developing how you draw them based on their basic form of primitive shapes. While you complete this practice,  you remove the thought process when you come to do it live, sat watching a speaker or in a meeting. Drawing these symbols becomes a muscle memory and your focus moves to listening, tuning into the structure, flow and key points from the orator.


Coding Kata’s

In software development this process is often known as a Kata. Taken from martial arts the Kata is a choreographed set of movements practiced solo or in pairs. In software development this process is used to rehearse all the other skills you need outside of solving the algorithmic or domain problem. This can be practices such as TDD, BDD or the use of particular design patterns. By making these practices a natural reflex, when you come to real life situations you can focus all your energy on the unique problem at hand and let the surrounding practices come naturally without thinking.

I’ll be continuing with this deliberate practice over the next few weeks. Its proven popular enough for me to share this with my peers where I’ll be talking to them about the Visual Kata and how they can expand their visual library.

Below is one of my first attempts from a presentation course I attended by Andrew Ivey at TimeToMarket.



Breaking the Kata cycle with Curiosity

Recently I came across Hakan Forss’s blog post on What is a Kata?

The following is an exert from this post:

“You learn and evolve a Kata through the three stages of the learning cycle Shu (learn), Ha (break) and Ri (create). In the first stage Shu, you learn by following the teacher. You imitate the teacher’s practices, values and thinking. You will only move on to the next stage when you have made the teacher’s Kata your own. In the Ha stage, you break from the teacher’s practices and make modifications based on your own creativity. In the Ri stage, you leave the teacher and you start creating your own unique Kata. As you expand your knowledge into new areas, you will loop back to the Shu stage for those areas in an ever-growing spiral of knowledge.”

The interesting part for me is “You will only move on to the next stage when you have made the teacher’s Kata your own”.
I recently came across a situation where eager engineers followed the frameworks set out by Scrum by the letter, sometimes using these guidelines as a stick to beat others over the head with when they were not followed. But like all frameworks and rules, there are always exceptions and they should never be blindly followed.

Although this shows great learning and knowledge of the process and makes you appear to serve the greater good of the customer, it does comes with pitfalls if you don’t have the curiosity. You may come across conflicts between those that want to follow the process because they are told it has value but don’t understand why and those who don’t follow the process because they don’t understand why they should.

It is often the latter that comes out as the agitator or the bad guy but this is not always the case. This behavior maybe demonstrating something you do want in your staff and illustrates an ability to progress through the 3 stages of learning.

Whenever you follow any process the curiosity inside you should always be asking “Why?”, leading to a true understanding. It is this step that should lead you to “break from the teacher’s practices and make modifications based on your own creativity”.

“Know the rules well, so you can break them effectively.” – Dalai Lama XIV

If you observe your team exhibiting this behavior, don’t always assume they are out to be obstructive. Ensure all your team understand why we perform the practices that we hold important.

One to Ones – Another Feedback Loop

Over the last couple of weeks I have been committing one of the worst sins as a manager. Not keeping up with my one to ones. This makes me feel really bad. Although I offer an “open door” policy, or in my specific case a no door policy (I don’t have an office) and I always try to encourage my directs to approach me whenever they have a problem or need advice, I still feel I have let them down by not having the metronomic opportunity to have my undivided attention and talk.

It still surprises me how few people have experiences of regular 1-1′s so I thought I would share my thoughts on my experiences.

What are One to Ones?

One to ones (1-1) are a regular and frequent meeting to give and receive feedback to your direct reports; those people that you manage. In the same way that we approach releases we approach one to ones, early and often, tightening one of the many feedback loops in Agile teams. It’s a time to allow direct feedback and build relationships with your staff. Giving feedback isn’t just about negative feedback nor telling someone how badly they are doing, it’s a time to offer encouragement and coaching. There any many techniques on providing feedback such as reflective questions or non threatening language but I wont go into that here.

The Anti-pattern

Annual reviews are a common practice in the business environment but the frequency extends the feedback loop between yourself and your directs to months. This allows little time for course correction until its too late and the behaviors that either you, your directs, or worse both, reach a point of no return and its time for personal improvement programs or other last resort corrective techniques that too often come as a surprise. How many times have you sat down with your directs to provide feedback at an annual review and you receive a look of shock and horror, as they were unaware of the impacts of their behavior or the fact that they were even doing it?

The cost of not doing them?

  • Your directs don’t know where they’re going wrong or what they’re doing well.
  • Morale depletes due to lack of encouragement or effecting other teams members with the unchanged bad behaviors.
  • As a manager you don’t get to find out what’s really happening on the ground and how people feel about it.
  • You don’t build up solid relationships with your directs.
  • You don’t allow yourself the opportunity to discover those gems of information about your directs that can help you understand where they are coming from and empathize.
  • You don’t allow a constant and open channel for communication.

What do they look like?

I generally make the 1-1 sessions 30 mins long, but this will depend on your availability and how many directs you have reporting to you. The session is split into 3; 19 mins for their feedback, 10 mins for my feedback and then 10 mins for any other business. My 1-1′s very rarely stick to this schedule but that’s OK. The important part is that the first part of the meeting is focused on what they want to say, reinforcing the fact that this meeting is for them and not a status update and that all parties have an allotted time to provide feedback.

Schedules can be tricky and the frequency is a balance. Too often and they can be time consuming for your direct with little to discuss at each. Too infrequent and you loose the opportunity for course correction and you slip too close to the anti-pattern.

I hope to share more of the specific challenges that I have faced in 1-1′s in the future, but hopefully, if your not doing them yet, this is enough to get you started.

There’s some useful pod-casts on 1-1′s and feedback in general from the people at Manager Tools. If you can get past the jovial conversational format there’s some good content.


Recently I tweeted about my team.




One of the common problems I see when writing user stories is the lack of definition. This definition needs to be at the right time, and there’s no hard and fast rule, and in the scenario below, this was at the story kick off, the last group chat before the coding starts on the story.

Previously the team when discussing our stories often felt that they got bogged down in the details. This is natural as the pressure to get stuff done and our sense of productivity means that we want to just get on with the task in hand. “If I’m not writing code, then I’m not being productive”.

After asking the team to try and be more thorough with the user stories as an experiment and reviewing the results in our retrospectives we realized the benefits that it had on the ability to deliver the feature quickly. With the first challenge completed we then faced out next challenge.


“I’m happy to write down in our acceptance criteria exactly what should happen when the user presses button X, but there are several options, which one is right?”


There are times when you might find your teams discussing at length which is the correct behavior. If this discussion starts to dominate a story planning or kick off meeting then its time to stop.


You Must Decide?

There’s no phone a friend on this one. The closet you may have is to ask the Product Owner, and that might be possible if they are in the planning with you, but does the Product Owner really know exactly what the customer wants from such a specific behavior? With any luck, they will be there to just make a decision, an often based on flipping a coin.


“Deferring a decision is deciding its not important.”


If your team relents on making these detailed decisions then gaps may appear in your product. If you don’t decide on the behavior of a feature, how do you know which is correct and which is not. This will ultimately result in a misunderstanding further down the line and cause re-work. If your lucky, this lack of definition will be caught by the testers in your team as they believed the feature should behave in a slightly different way, but still, this will be wasted time either discussing it after its been coded or re-work if you change your decision.


But What To Decide?

The stark reality is that you do not know what the right decision for this behavior is. The Product Owner does not know what the right decision for this behavior is. Some might even argue the customer does not know what the right decision for this behavior is (if asked).

The good news is, is that it doesn’t matter.

The paralysis and time spent discussing what is or what is not the right behavior and whether either decision has value to the customer is just waste. The best thing you can do is make a decision regardless of what that decision is. As long as everyone is agreed that a decision has been made. The time spent deciding on the decision is value wasted while your feature is not in production. The quickest way to validate whether the decision was right or wrong is by putting the behavior in a production or a per-production environment where real users can use it under real conditions.

The ability to do this quickly and shorten the feedback loop or PDCA cycle comes with techniques such as Continuous Delivery. The journey to Continually Delivering can be a long one with many challenges of its own, but even if your are only halfway there eliminating the waste of deliberating over small behaviors will be beneficial to both you and your users.