Agile thinking in ancient Rome

I found a number of quotes from a popular writer and favourite of Julius Caesar :- Publilius Syrus that I thought were so appropriate to Agile thinking today, it is fascinating how these lessons have existed for millennia and yet we still frequently fail to follow what would seem to be common sense.

RomanSoldier

Here are some of his maxims:

On agility in planning:

“It is a bad plan that cannot be altered.”

 

On commitments:

“Never promise more than you can perform. “

 

On quality:

“Nothing can be done at once hastily and prudently“

 

On multi-tasking:

“To do two things at once is to do neither “

 

2000 years later and the old Maxims are still relevant.

Understanding the 5 focusing steps

The Theory of Constraints (TOC)

The Theory of Constraints complements Agile software development extremely well, it is about applying a mindset of ongoing improvement to your organization. It contains the notion of applying efforts to improve to the areas that will have the most impact and offers some practical techniques for achieving this.

When we talk about the Theory of Constraints what is often thought about are the 5 focussing steps. The steps are not always easy to understand and the wording can be confusing. I’ll attempt to explain the steps with a few examples, where possible I’ll use examples more common to software delivery organizations.

broken-link-lean-theory-of-constraints

What is a constraint?

Firstly a constraint is neither good nor bad, it just is. Your system has a constraint and no matter what you do, it will always have a constraint. You may say that in a perfect system the constraint is the external demand for your product or services, but even then there are ways to increase demand or open new markets, and markets have a tendency to change over time.

Do not treat a constraint as a bad thing to be eradicated, awareness and understanding of the constraint is the goal, what to do with that knowledge is a secondary consideration.

Constraints:

A constraint limits the useful output of your system, so any improvements to the constraint will directly impact on the total output of your system.

Conversely improvements to an area that is not a constraint will have no impact on the output of your system.

example:

toc

Let us consider a simple system.  I can build 3 units a day and I can ship 1 unit a day.   

Shipping is my constraint, Building is NOT my constraint.  If I make improvements to shipping and can now ship 2 units a day I have doubled the output of my entire system.

If however I improve the building aspect of my system and can now build 4 units a day, it is wasted effort as I can still only ship 1 unit.  The over production is stuck there.

Any effort to improve any part of the system that is not your constraint is wasted effort. You should instead focus on improving your constraint.

This sounds obvious, but when your organization breaks areas into silos and measures managers on the performance of their area alone you tend to see this a lot. Teams striving for improvement and additional output when they are not the constraint.  The result is make-work. Things that “you know will be needed later” building inventory and so on.  Sadly cost-accounting supports this dysfunction by rewarding the behavior by classifying work in progress and finished goods inventory as an asset when in most cases it is a liability.

I say an hour lost at a bottleneck is an hour out of the entire system. I say an hour saved at a non-bottleneck is worthless. Bottlenecks govern both throughput and inventory.

Eli Goldratt

What is the system?

Our goal when applying the TOC is to identify constraints or rather the constraint in your system.  But that begs the question what is the system?

As a very broad rule of thumb, the system is all that is within your (organization’s) sphere of influence. It is not limited to just one area of the business.

Note: Your sphere of influence should include your market and potential market, and your supply chain, which includes potential recruitment candidates. Anything within which you have authority to influence.  

5-focusing-steps-113297

The 5 focussing steps

  1. Identify the system constraint
  2. Exploit the constraint
    (Make the best use of what you currently have)
  3. Subordinate everything to the constraint
    (Make decisions based on the constraint, the system should run at the pace of the constraint)
  4. Elevate the constraint
    (Make improvements to the constraint)
  5. Repeat the steps

Step 1 Identify the System Constraint

The three most obvious signs of a constraint are:

  • They are always busy
  • Work is piling up in front of them (in the case of people this may be requests for help)
  • Work downstream is starved, people that are dependent on them are regularly waiting

Note: busy work or excessive Work in Progress can mask these signs, so the first step is to stop any non-essential work, anything that is not needed immediately or cannot be traced to the top priority.  By reducing work in progress it will help reveal where your constraint is.  All too often your constraint is busy doing something not needed.

Once you have identified where you believe your constraint is, we move on to the next step.

Step 2: Exploit the constraint

There is nothing so useless as doing efficiently that which should not be done at all.

Peter Drucker

As we identified earlier any improvement to the constraint improves the output of your entire system. but the converse is also true. Any time your constraint is not working then your entire system is not working, any effort your constraint spends on something that is not immediately needed to deliver value to your customers is output lost to your entire system.  It may not be obvious but this is a key aspect to understand.

Your constraint should be considered in that manner, we say exploit the constraint in the sense that it should be used in the most effective way possible. This means doing the very best you can achieve with what you currently have.

  • Exploit your employees that are constraints to get the maximum value (NOT EFFORT) exploiting a constraint isn’t about a death march, it is about getting the most value from them in the long-term.  A happy employee working a sensible number of hours will deliver far more value than an overworked employee.
  • Work to keep your employees engaged, engaged employees deliver more value.
  • Pay well, your constraint(s) are your company’s most valuable asset, pay them well, they are worth far more to your company than their salary.  replacement, training and adjustment of new employees to replace a constraint directly impact the output of your entire system, learn that cost and value are not the same thing.
  • Only work on the highest priority items, make sure you understand the concepts of cost of delay and opportunity cost. Maximize Value !
  • Ensure there is a buffer of work before the constraint so that there is no idle time, idle time is time lost to your entire system.
  • Avoid multi-tasking, context switching is waste, better to complete one thing at a time, so ensure tasks for the constraint are prioritized properly.
  • Ensure your constraint is not working on anything that could be done (even less efficiently) elsewhere.
  • Ensure your constraint is not working on anything that is not directly leading to immediate value. Is your constraint booking their own travel, or filling in time sheets, or even making coffee? Or are they busy on a feature that you think will be valuable later?  All of those tasks are directly impacting on the throughput of your entire system, could they be done by someone else (or not at all).
  • Does your constraint have all the materials they need, do they have access to the information they need, the right tools and the right support, the right training.  Your constraint should have the right tools, the best tools available.  Your development team should have the fastest computers and the best software for the job, skimping here is one of the most costly errors a company can make.

This leads to a mini-debate on the use of admin assistants and Scrum Masters.  There is a trade-off between the ability for people to solve their own problems, and do their own admin and generally have a broader skill set.  Having an admin to do certain jobs can be a form of exploiting your constraint, but can also create a new constraint if you become dependent on them. Same goes for a Scrum Master, they are a great example of exploiting the constraint that may be your development team: Someone to handle blockers; chase things down; and generally ensure the team is enabled to be most effective all of the time by taking non essential work off them and keeping them focused on delivering value.  But again the risk is that they become the constraint.  Everything is a trade-off.

phoenixproject-680x400

Step 3: Subordinate everything to the constraint

This is generally the step that is the most confusing. What we are saying here is that all decisions you make in your system and for your system should be made based on understanding where your constraint is.

  • Quality, your constraint should not be working on things that are poor quality and may need to be reworked.  Ensure work handed to the Constraint is of the best quality it can be.
  • Identify and anticipate problems, if there are dependencies or potential blockers or risks ensure that they are mitigate BEFORE the work gets to the constraint, blocks at the constraint are blocks to your entire system. Have questions answered in advance where possible.
  • In the case of story writing, it may be that getting the input from the development team upfront at story writing time leads to fewer problems later, focus on flow and using valuable time effectively.  This is not an excuse to silo the constraint, this is about thinking of ways to use the time in the most effective way possible.
  • The rest of the system should work at the pace of the constraint, work should flow, sensible buffers of work should be maintained but no overproduction. Identify a cadence and have the whole system work to that rhythm.
  • Have non-constraints use the inevitable slack time to work on tasks at the constraint.  Developers should be testing, testers coding, anyone and everyone should use their slack to alleviate the work at the constraint, regardless of how inefficient they may be – so long as they are not introducing errors or knowledge gaps that may cause further demands on the constraint later.  This is where encouraging T-shaped people can enable us to maximize flow through our system.

As you can see the importance of understanding your constraint and making decisions based on that

Make the bottlenecks work only on what will contribute to throughput today … not nine months from now. That’s one way to increase capacity at the bottlenecks. The other way you increase bottleneck capacity is to take some of the load off the bottlenecks and give it to non-bottlenecks.

Eli Goldratt

Step 4:  Elevate the Constraint

Once we believe we have done all we can to Exploit the constraint and to subordinate everything to the constraint and we still want to improve further then the next step it to elevate the constraint.

Up until now the efforts have been without investment, it has been to utilize what you have in the best way possible, elevating the constraint will generally require an investment of some kind.

  • Hiring more or better people to support the constraint (only hire for the constraint)
  • Purchase more machines to support the constraint
  • Training or coaching the constraint(s) to improve their skills and effectiveness
  • Purchase better software, faster machines, better tools, conferencing equipment, more meeting rooms.
  • Team building activities, or other ways to improve effectiveness of teams that are part of the constraint.
  • You can consider more drastic options such as switching to a different tech stack, if that enables solutions to be solved quicker or may make hiring easier.
  • Moving to a new location.
  • Entering a new Market or creating more (diverse) products.

Remember all of these options should be undertaken with the specific constraint in mind.

Step 5:  Repeat

Once you have worked through these steps it is expected that you will have been a catalyst for change, it would be good to have a measure of the impact if you can.  But the end result is that your constraint is less of a constraint, allow time to see the impact of the changes and re-assess where your constraint is now. It may be in the same place or a new constraint may have been identified. But in either case repeat the steps and see if further improvements can be made.

5-focusing-steps-113297

Repeat again

The Theory of Constraints is a process of ongoing improvement, if you stop improving entropy sets in and things will get worse, these steps should be repeated and repeated indefinitely and frequently

Metrics – a snake in the grass?

One of the things I have noticed over the last few years is a drastic increase in the use of metrics. Particularly with the surge in the use of electronic boards for teams data is much more readily available and so is much more frequently used.

If you can’t measure it, you can’t improve it.

Peter Drucker

Previously there was an effort required to collect and process data to be meaningful, but now much more is easy to do, often it is done for you. But is this a good thing?

Problem 1: Lack of understanding the data or the tool

There are two problems I frequently see, the first is that we have access to data and tools but that doesn’t mean we know how to read the data or understand what it is telling us. Monte Carlo simulations are a great example here, I regularly see them being used without understanding what the data is telling you or understanding the limitations of the information. Instead the results are copied into forecasts and endorsed like they are gospel. The information is too easy to get that there is no longer a need to have an understanding to use the data.

Problem 2: Lack of understanding the consequences

The second problem is that our behavior changes as soon as we are measured, sometimes consciously sometimes not. Generally speaking this is the purpose of measuring, we measure what we want to improve, be it our weight or lap time or velocity.
However, there are nearly always unintended consequences, and they can be unexpected and unpredictable.

maxresdefault

The Cobra Effect

The Cobra effect is term that originated in a story from British colonial rule in India.  The British rulers were worried about the number of venomous cobras.

So they created a policy of putting a bounty on dead cobras.  People were paid handsomely to deliver dead snakes for a payment. What could go wrong?

Well at first the reward system worked well, the number of snakes seemed to decline, but the bounties paid continued to rise. The British became suspicious and investigated, they discovered that the reward was encouraging enterprising locals to start to breed snakes for the reward, it was easier and safer to breed snakes than catch wild ones, and they were breeding them in large numbers.

The British rulers were shocked at the dishonesty (It is simply not Cricket, old boy) and were so outraged they cancelled the program and  cracked down on the breeders, who released the captive snakes in to the wild. The result was a massive increase in snakes rather than a decline.

Republic of Congo

There is a much more horrific version of this situation from Leopold II (of Belgium) rule in the Congo.  If your quota from your rubber plantation was not met the overseers were expected to execute the wives and children of poor performing farmers and send their hands (as proof of death) in lieu of the rubber quota. – a hand equated to a quantity of rubber.

The problem was, some of the villages found it easier to supply hands than to supply the rubber, so were meeting their quota with a mixture of hands and rubber, there were some reports of entire quotas being met just with hands.

Bad as this policy was, it then got worse. The hands were not necessarily of poor performing farmers or their families. Some villages and soldiers that would collect quotas were attacking other villages, and killing each other just to chop off hands and then using the hands instead of rubber as payment.

Such was the extent of this practice some reports suggest that the population of the region reduced by as much as half as a result of this practice. Estimates suggest that 10million people were killed for their hands.

Parallels

Now those were extreme cases and it seems unfair to draw parallels given the seriousness but nevertheless it is human nature to respond to how we are measured, and by implication rewarded.

I hear tales of management that expects velocity to rise every sprint, and guess what it does.  But does actual value delivered go up – I very much doubt it.

I see teams wanting to mark a card as done and open a new identical one, because the cycle times are looking bad.

But the worse is the measure of being busy, far too many organizations have a fixation with everyone being busy 100% of the time, regardless of whether what they are doing is contributing to delivering value to the customer or if having a little slack would allow the team to deliver far more.

Suggestion

This sounds like a message that metrics are all bad, it is not at all. Metrics can be very useful and as many say you cannot improve what you don’t measure.  The key though is to have those being measured understand the desired outcome and share or support it.

Back to weighing yourself for a diet, your goal is to be healthier, your weight is a measurement. tampering with the scale may impact the measurement but will not help you to your goal. You may fool yourself for a while but it is only yourself you are fooling.

A clear goal, and a variety of metrics that support that goal is often more valuable than a single goal, especially if you are supportive of the desired outcome.

“Tell me how you measure me, and I will tell you how I will behave”

Eli Goldratt

Beware of the measurements you use, you may very well be defining the behavior you get, even if it is not your intent.

 

Is culture observation or aspiration?

There has been a lot of talk recently about culture and it’s importance when creating organisational identity,  but there are two ways I see for an organisation to create a culture.

A short story…

I was once told a story of how the British and US army engineers take two different approaches to footpath planning when creating their bases.

Flag_-_Union_Flag

The British planned in advance and they laid the footpaths to a defined route and the soldiers were required to follow the specified paths, and were corrected if they didn’t.

71X+wfQBpKL._UX385_

The US engineers on the otherhand would delay laying the footpaths until the base was in use, they would observe the routes taken and where the soldiers walked and would lay the paths when the preferred routes were clear.

The belief (or so I was told) was that people will find the most efficient route on their own.

Each has it’s own merits, and is itself likely a reflection of the culture of those two organisations.

A deliberate culture or a reflective culture

I see this as being very similar to a company’s culture. You have two main choices: either you decide the culture you want, you lay it out and then make decisions that reinforce the path you set. This means hiring practices, rewards, punishments, recognition, and everything in between, you continue to do this until the normal behaviour is to follow the path set.  Your culture is by your design. But to get the culture you want requires a lot of correcting of behaviour until it happens.

Or the alternative is to wait and see, behave the way you behave naturally and the same for the others around you, soon enough a culture will form and it will be a culture that reflects the way you behave. The good news is this is your real culture, the bad news is – this is your real culture.

There are problems with both of these, choosing a deliberate culture that goes against some of your natural tendencies or is unrealistic can lead to it not being followed and the result is that you claim one culture but actually have another, this can be very damaging especially to those that believe in the defined culture.  If you follow the rules but others get ahead by other means it can be corrosive.  A lack of defined culture can also bad as there is no safety check on poor behaviour, left unchecked it quickly becomes the norm and then it becomes your culture, which is the case for women in IT.

Women in Tech

One great example could be seen with Women in Tech, where most companies would say their culture does not set out to exclude or marginalise women, but without a deliberate culture to seek out diversity we have allowed the lack of diversity to become the normal state and for the culture to be one that unintentionally discouraged or excluded women. Often evolving from small companies that have grown by surounding themselves with like minded individuals. Unconsciously biased towards those similar to them.  It will take time and effort and a deliberate culture to break through some of those barriers we have created over the years.

But this is seen in all aspects of an organisation, if your culture tolerates something for long enough, maybe because it is easy to ignore when small, it can become a much larger issue when you grow.  If you are not explicit about the culture you want then you may not be able to shape the culture you have. In larger organisations sub-cultures can form in different areas and this can be even more damaging, without a clear global culture factions develop and the inconsistencies undermine the larger whole.

Agile Transformation

One of the reasons that Agile Transformation is so hard is because it is a culture change rather than a process change, you are defining a new culture and that will not happen overnight. All the previous actions that were normal, the rewards, the metrics the measurements are very hard to undo.  Empowering people to be self-organising when they have only known command and control will take a while to adjust.  I believe this is why so many agile transformations are unsuccessful, some processes are changed but there is no desire or will to change the culture, there is a general wish to change to Agile without actually changing.

The solution

The solution in my opinion is to do a little of both.  Be aware of the culture you want and be explicit about it, shout it from the rooftops, and repeat it and repeat it and repeat it, until everyone in your organisation knows you mean it and you believe in it, be clear where you aspire to be. This will still take a very long time to have impact.

But also be aware of where you are now, the unwritten culture you have now is just as strong and just as real. Be especially aware of the behaviours that your culture currently has that you are not happy about.  If you are honest about your weaknesses and failings you have a far better chance of changing. Seek out and coach those that are not behaving the way you aspire to be, remember they behave that way because it is your culture.

Culture change wont happen overnight but that doesn’t mean you shouldn’t be intollerent of any behaviours that don’t reflect the culture you want.

Do you know ‘what’ your problem is?

The title is a little tongue in cheek, because in my experience it is the ‘what‘ that is likely your problem. We focus far to much on what we are doing both in our work and in our product, and far too little on why we are doing it.

Failing to understand the why

The obsession with local efficiency and and maximizing utilization of people is crippling customer focus and value.

There is nothing so useless as doing efficiently that which should not be done at all.

Dr Peter F. Drucker

Peter Drucker has some very inspiring quotes but that one is by far my favorite and one that I wish was better understood and adopted in practice

shakespeare-quotes-9-1024x540

We look for work to stay busy, whether it be setting up grand databases or magnificent CI solutions. I am not saying either is unnecessary, but does the solution fit the need? Were they built when needed or in anticipation of a possible future need?

The focus on lead/cycle times can result in stories becoming rushed, the focus becomes on getting work ‘done’ as quickly as possible, rather than a focus on getting the work ‘done right’. We are completing work quickly at the expense of adding value.  It also leads to ‘creative accounting’ where the desire to reduce cycle times results in the definition of done getting corrupted.

Refactoring gets sacrificed when throughput is the priority.

Stories focus on the what not the why.

We are often in such a rush to complete we either skip the why entirely or we take the easy route and look for a ‘why’ that satisfies our ‘what’  rather than actually asking why or giving it proper thought and effort into understanding the real why.

Of course the “Why conversation” can be hard, or time consuming and sometimes it seems obvious but can be hard to articulate. Story writing is a time consuming process but when the process becomes rushed there can be a tendency to prioritize stories according to what is written or what is easy to write rather than what is the next priority based on value or other prioritization methods.  We tend towards keeping people busy and the process flowing rather than ensuring we are delivering value and working on the right thing.

It is far too easy to get into a cycle of business as usual, all the time running to catch up but not really knowing if you are working on the right thing. But because everyone is busy and something is getting done “Asking why?” drops below the radar and the hard question of value does not get asked.

stoneage

Step back and evaluate if you are working on the right thing. Sometimes going slower is actually going faster.

Taking a little while to do it right could well pay dividends.  Our goal should be to give our customer the most value, not maximize how busy we are. And whilst logically these two should be related, in reality the opposite can be true.

Learning to write good stories with an emphasis on understanding the why this story adds value, learning to prioritize with the emphasis on why this story is the one we work on next can make a huge difference to a project delivery.   Incorporating story maps; road maps, story boards and utilizing other prioritization techniques can help your product deliver the right thing.

The customer should be your focus

Your product owner should be able to articulate clearly and confidently why the next story is next and that justification should be customer centric. Your goal is to make the customer happy NOT to keep your team busy.

When lead/cycle times start to become more important than refactoring it leads to a degradation of the system, either in terms of a reduction in the quality of the code, or an increase in technical debt, but more often a reduction in quality of the user experience.

UX is an afterthought

When we teach story writing we teach the INVEST method, the I is independent, and V is valuable, but I wonder if the independent is misunderstood, especially when it comes to UX.  The goal of a story is NOT to minimize Effort, it is to maximize Value. Sometimes we can maximize value by minimizing effort (ROI: Return on investment) but our goal is still the value and NOT the reduction in effort.

The goal of a story is NOT to minimize development Effort, it is to maximize customer Value

A story that adds new functionality could easily be tagged on to the existing system with little redesign of what already exists, e.g. We add a new tab or a new page or a new button, just append it to what is there. In some circumstances this may be the right outcome, but it should be a conscious decision not a default lazy way out.

A new story that is adding functionality should be assumed to be incorporating that extra functionality into the system where it fits best for the user and maintains the user experience and flow NOT where it is the easiest to integrate by the developer.  If we just tag on new functionality without consideration for the user or the existing system it can quickly become ugly and cumbersome.  Sadly the prospect of changing completed work – especially visible work can be daunting and many teams are resistant to make changes to the UI, instead preferring to add new functionality where it is least disruptive.

Each new story especially UI stories should require some reflection and a conscious decision to maintain flow and look and feel and maintaining the user experience, maintaining the user experience may very well be more valuable than the new functionality adds.

Acceptance Criteria is a substitute for thinking and conversation

We can get so focused on delivering quickly and meeting AC for a specific story that we become blinkered, we know we need to maintain quality in the sense of stability, reliability and security, but we can easily forget about the less quantifiable quality of the user experience of the system as a whole. We can seek to address the acceptance criteria without thinking whether what you are doing truly adds to the value of the product (not story) and when A/C is specific we don’t question whether it is right, we skip the conversations.

images

Being busy is not your goal

It can be a very hard adjustment especially when you are paid by the hour, or even bill by the hour, for us to accept and understand that sometimes the most effective use of our time is not keeping busy. It may be to do something inefficiently or to not do anything at all.  Keeping you busy is not the goal, delivering the best product to the customer is.

If I were a painter, I…

Recently I have spent a lot of time talking about story writing, but this week the focus has been on Acceptance Criteria and there have been a variety of comments that have caused me to reflect and have caused me some concern.
Some examples:

  • Unless stated otherwise a story is assumed to be happy path only. If it isn’t in the Acceptance Criteria we don’t have to do it.
    • Acceptance Criteria must contain all details including all edge cases that must be tested, anything not stated doesn’t have to be implemented.
  • If all acceptance criteria are met the PO/Customer MUST accept the story even if they are not satisfied.
  • If acceptance criteria change before the story is done, it should be completed as specified and a new story should be created for the changes. after all, late changes to Acceptance Criteria demoralize Developers.
  • If Acceptance Criteria are unclear we can choose what to do.
  • The Acceptance Criteria should never tell us how to do the job.

A metaphor

To respond to these questions I thought I would use a metaphor – A homeowner wanting to redecorate her house.

img_0374

The home owner hires a firm of decorators because they have a reputation for quality.

Her first request is that the painter decorate the sitting room,  She would like the walls painted blue, the ceiling an off-white, the windows also off-white but the paint needs to be wipe-able to avoid finger prints, and the doors and trim should match the window color.

A story is an expression of a need

Acceptance Criteria are the notes from the discussion to help clarify the need

In this case the homeowner has specified a number of acceptance criteria:

  • Walls – blue
  • Ceiling off-white
  • Windows off-white but wipe-able paint
  • Trim same as windows

The acceptance criteria are details provided by the Product owner that would help the workman understand how to complete the job to the satisfaction of the Product Owner – in this case the home owner.

The acceptance criteria are details provided by the Product owner that would help the workman understand how to complete the job to the satisfaction of the Product Owner

The job can and probably should be broken down into smaller tasks (stories). Having just the windows painted has value, just the ceiling does too, just the trim and potentially each wall independently may have value although that may be harder to qualify with the Product Owner, depending on their needs.

Detail in Acceptance Criteria

What you will note though is that the acceptance criteria did not state that the areas to be painted must be professionally prepared and sanded, that a primer coat be applied and two top coats are applied.  They do not state that the carpets should be protected and that spills should be cleaned up and that there should be no paint on the glass and no wall paint on the ceiling, no ceiling paint on the walls or that the paint should fully cover the walls and be an even drip free finish.  In fact the Acceptance criteria make no mention of how the work should be completed at all.

Who is the audience of your Acceptance Criteria?

The Acceptance Criteria come from a conversation with the Product Owner, but you may also want to take technical notes from conversations with those that will do the work. E.g. if the contractor has an apprentice, it may be necessary to spell out to him/her the technical details mentioned above, what seems common sense to you and the Product Owner may not be as obvious to someone less experienced. But notes on implementation are not acceptance criteria in the same sense. The product Owner should not be expected to understand all the technical details, what is acceptable is always determined by the Product Owner.

If quality is not specified in the acceptance criteria

But that means I only need to worry about the happy path right? So I need to do a good job with the specified work but I don’t need to care about drips or mess or if I am painting the walls I don’t need to care about the ceiling after all I am only doing the happy path. I can ignore walls that are hidden behind furniture, I can do the job quicker if I don’t put down dust sheets and we can worry about cleaning up the mess later right?

Put like that it sounds silly doesn’t it, but that  is what you are suggesting if you don’t consider anything other than the happy path, the minimal amount is done but you are leaving a mess to clean up later.  If this is clearly understood and acceptable to the customer or that you have split a story like this to get feedback sooner there may be an exception but if you think that you can declare a story ‘done’ with a mess left to clear up later it is a recipe for a disappointed customer or a misleading impression that you have achieved more than you really have. Giving a sense of artificial progress may lead to disappointment later.

img_0376

Acceptance Criteria are comprehensive and exhaustive

If all acceptance criteria are met the PO/homeowner MUST accept the story even if the homeowner is not satisfied.   There is some crown moulding between the walls and the ceiling, it was not mentioned in the Acceptance Criteria and the decorator has painted it the wall colour, but the Home owner wanted it the same as the ceiling and thought it was obvious so had not mentioned it.  The decorator insists the job is done because the Acceptance Criteria are met.

This is actually a very common issue, Acceptance Criteria are often not comprehensive and there are ambiguities and omissions, so how do you handle them?  Assuming you are paying for the work on a time an materials basis the customer is the one that suffers, they will have to pay for the rework(or extra work), but it is generally the workman that gets frustrated, they believed they did a good job and so it is frustrating to have to repeat good work.   But the customer is not satisfied, and that should be the only thing that matters. Your goal as a quality workman is to satisfy your customer.  The job is not done until they are satisfied (assuming the request is reasonable)

It might be that the customer is willing to accept the work as it stands and agree to the repainting later. But more likely they will want it fixed before you move on to the next piece of work.

What is not acceptable is to refuse to make the changes because they were not explicit in the Acceptance Criteria.  The story card is an invitation to a conversation, the Acceptance Criteria are reminders of what has been discussed. At no point do Acceptance Criteria or the card become a sealed contract.

img_0373

Changes during a story

The painter is half way through painting the window and the Customer comes to check on progress. She sees the paint colour of the windows and decides it is too white, too stark and clinical and would like the colour changed to an off-white.  She understands that the rework will cost and the new materials will cost and she accepts this, but she is unhappy with the colour.

The painter responds: “But the thing is the A/C were clear about the colour, the shade was specified, I have spent a long time getting through the first half of this job and it is only fair that I finish it according to the A/C”  Then we can have a separate job to repaint it a different colour.  Frankly my metrics will look bad if this job takes 50% longer, it will look like I am slow. Do you know how frustrating it is to do a job and have it rejected..”

I have heard frequently how when a PO changes A/C the story should be completed as it is and a new story created for the revisions.  But any continuation on work that is not wanted is waste. The notion of continuing to work on something that is unwanted, and even worse billing the customer for that time, is just wrong.  If metrics are driving bad behaviour then the metrics are failing. If someone is demoralized because a PO has clarified their needs then they need to evaluate their understanding of Agile.   A full half of the Manifesto is:

Customer collaboration over contract negotiation
Responding to change over following a plan

If you are unwilling to accept and adapt to changes in A/C even late into development, then you really need to go back to basics and ask if you genuinely support Agile software development.  I am sorry if that sounds harsh but the notion that keeping devs happy and metrics pretty is more important than delivering the right thing for your customer is very frustrating for me to hear.

 If Acceptance Criteria are unclear we can choose what to do.

The homeowner has been pretty vague in her choice of colours, blue and off-white. So presumably we can choose whatever we want?

Clearly that is unrealistic.  What might be more reasonable would be to talk to the homeowner and say “We prefer this brand and type of paint and these are the available colours within that range can you pick one”   The homeowner may say, No I want a very specific Blue only available in this brand that needs to be imported from New Zealand.  In which case you should explain that such a choice will increase the cost and duration of the job and adds to the risk – being an unfamiliar material, it may need more coats etc.  If the homeowner understands and accepts those risks then it should be done, but if the homeowner can be presented with a less costly and less risky alternative then they may be willing to modify their request.

Ambiguity should trigger conversation it should not be an excuse for making assumptions.

Ambiguity should trigger conversation it should not be an excuse for making assumptions. The goal is a finish that the homeowner is happy with, the specifics are likely open to negotiation. But whilst you may present alternatives it is for the homeowner to make the decision.

Anything not stated doesn’t have to be done

There are two types of things not stated in the Acceptance Criteria that apply here, how we do the job and some of the specifics.

How: The Acceptance Criteria doesn’t explicitly say that we need a primer coat, but we know that for a quality job it needs to be done. The Acceptance Criteria doesn’t tell us which brushes to use, or how to paint to get a good neat coverage. The contractor may need to specify those to an apprentice, but the homeowner should not need to specify the tools to be used or how to do the job (unless that forms a particular part of the need)  You as the contractor may need to spell out those details to your apprentice, consider those sub-tasks of the story.  Prepare and protect work area; Sand surface, apply primer, apply first coat,  apply 2nd coat, clean up area, clean brushes etc.  But these are NOT Acceptance Criteria to be supplied by the home owner. They are about how to do the job not about the job that needs to be done. Sometimes these do overlap but generally we try to keep the how out of the request.

There are also some specifics that may not be mentioned, for example there is a recess around the fireplace but only 4 walls were mentioned.  Can I ignore the other surfaces?  Likely not, details may have been assumed, if there is doubt clarify with the homeowner. There is something fixed to the wall which is too close to be painted behind, but if not painted it would look odd. The Acceptance Criteria shouldn’t need to specify that you need to remove it and paint behind to do a good job. But again if there is any doubt clarify it with the homeowner.  The Acceptance Criteria will rarely be comprehensive and conversation will be necessary.

Specifics: The Acceptance Criteria should not specify how the job must be done

Normally we try not to specify how the job must be done, but there will be exceptions to this. The homeowner may have a need to decorate using traditional materials, and so may specify that particular tools are used – e.g. No power tools, no lead based paint. No synthetic materials in paint or tools.  Sometimes those requirements are not necessarily clear to you. The Customer may insist on 2 primer coats and 3 top coats.  Two more coats than you feel is necessary for a quality finish, but they insist are how the job should be done.  In those instances you may make recommendations or suggestions, and try to understand why they feel this is a requirement. But ultimately it is for them to decide – so long as they understand the additional cost and risk.

But again there are exceptions to this, for example the customer my request that you skip a primer coat and only apply a single top coat, or insists that you use low quality materials to save on cost. If you believe that this will result in a substandard job, then again you should explain your reasons and try to find an alternative and if necessary refuse to accept the job if you feel that the result would reflect badly on you.  Ideally it should be clear from the start what the expectations around quality of service are, but it may be necessary to re-clarify periodically if there is doubt.

Summary

  • In story terms, the story should express the need, what your goal is. It is the start of the conversation(not the end) for assessing how to satisfy that need.
  • The Acceptance criteria are simply notes to help remember that conversation, they do not form a contract.
  • Acceptance Criteria should never be considered absolute, immutable or comprehensive.  Uncertainty should be clarified with the Product Owner early and often.
  • You should respond to changes in Acceptance Criteria quickly, the quicker you respond the less waste there will be.
  • Acceptance Criteria do not normally express how to do the job, although you may note how you intend to do the job to illustrate to the PO to help clarify any ambiguities.

What about Gherkin?

You can’t have a discussion on Acceptance Criteria without mentioning Gherkin, Gherkin is simply a tool for expressing Acceptance Criteria in a standardised and hopefully clearer format. However, Acceptance Criteria Gherkin and Test scenario Gherkin are very often confused, and the Gherkin constraint may result in the focus shifting from the conversation about the user’s need, to how to use Gherkin and the user’s need may get lost.

Story Acceptance Criteria is also not the place for identifying all of the test scenarios and edge cases, it is about understanding the need of the customer.

Another common issue with Gherkin is that the precise nature of the format and terms implies that the Acceptance Criteria are absolute and non-negotiable which is the exact opposite of how they should be considered.  If you start to fall in to the trap of seeing the Gherkin as a contract (rather than notes on a conversation) then stop using it until you get in the habit of regular conversation with the Product Owner.

By all means practice with Gherkin until you get better, but if you remember that it is about capturing notes from a conversation with the PO and most certainly NOT negotiating the terms of a contract then it is a useful tool.  But personally I prefer not to use Gherkin in the initial conversations about Acceptance Criteria simply because it is not a natural way of thinking for many POs so the format constrains thinking and conversation and the frequency in which it is treated as an explicit contract undermines it’s value.   Once you have discussed the Acceptance Criteria converting them to Gherkin may be beneficial.

However, I prefer to see Gherkin used for Acceptance Testing where those writing the tests are familiar with the syntax and where precision is more important.
If you take nothing else from this, please remember that Accceptance Criteria are notes on a conversation, they are not clauses in a contract.

Accceptance Criteria are notes on a conversation, they are not clauses in a contract.

It is all in the follow through…


Accountability of others

Holding another person accountable can be a scary thing, even just saying that sounds a big deal.  And whilst it is a big deal, it doesn’t need to be scary.  Feedback is a skill, and it one that you get much better at the more you practice.

In theory feedback in the context of accountability should be the easiest kind.  Your work colleague or partner has made a commitment to you or to the team and in doing so they are implicitly inviting you to give them feedback if they stray from this commitment. Learning to give that feedback constructively and supportively comes with practice, and frequency. If you are giving feedback regularly it is easier to give and easier to receive, eventually it will become a normal and natural interaction on a team.

If they took an action item to do something by the end of the week a polite enquiry on their progress, may serve as a reminder that the task is important and that they have committed to it. There is no need for judgement or pressure and certainly no need to micro-manage. An offer to help or an enquiry if there are any impediments you should be aware of, or can assist with, should be sufficient to reassert the importance of the task and a reminder of the commitment made.

In most cases if someone has taken responsibility and committed to something, they will be happy to be held accountable, especially if you have established trust on the team and have decided as a group this is something important, a good team player understands that group decisions impact all of us and are in all our interests to get it done, so understand and expect you to have an interest in getting it done.

Holding yourself accountable

Holding yourself accountable is much harder, after all if we could see we were slipping we’d do something about it. Which is why it is so important to explicitly ask others to help you with this or to find techniques to help you stay focused on what is important.

accountability-breeds-responsibility1

Accountability techniques

There are a couple of very easy techniques for creating opportunities for holding each other accountable. If done right these should lead to more frequent feedback, if they become a constraint and feedback becomes limited to these opportunities then try something new.

A regular stand-up meeting

Get together with your team on a regular basis, a lot of teams find once a day is a good cadence, review priorities, objectives and actions, by sharing what you are working on and where you need help you are inviting input from others, if an action item is being neglected this is an opportunity to ask why or to remind others of the importance of it. Be careful this does not become reporting to someone, this is about sharing information and looking for opportunities to assist each other.

Make your work visible

Something like a Kanban board or a todo list is fantastic for sharing with your team mates what you are working on, you and they can immediately see if an action is not being given priority and can see why or what is.  If Kanban is used then priorities of work are clear and your policies are explicit, everyone is clear just by looking, what is going on.  The key to maximising the value of this is by ensuring it is used correctly, all tasks are on the board and you follow the rules, ambiguity can ruin this technique.

If combined with a stand-up it can enhance the effectiveness of both techniques.  Also whilst Kanban boards are great for team working, they also work well for an individual, many people find a personal Kanban board is a great way of keeping focused on what is important and avoids getting distracted by less important interruptions. and having it visible in a public space too will aid you holding yourself accountable to it.

Always review previous actions

At the start of a team meeting it is important to review the previous action items, and to not lose sight of any that remain outstanding. First the team should be focused on the most important issues, and actions should be the team’s collective view on how best to proceed. If as a team you don’t care enough to want to know how those actions turned out, you have to question your buy-in to those desicions or if your team is actually focused on the right priorities.

Was the purpose achieved?

Remember the reason for the Action item. I would also suggest that an action is the result of a discussion about resolving a problem, satisfying a need, or is progress towards a goal.
Taking some time not only to review whether the action was taken, but also to review whether it achieved it’s purpose would be valuable. It is quite common for an action to not have the expected results, and in that case the underlying issue still needs addressing.

Summary

Accountability should become routine, and we can all benefit from being held accountable. If it doesn’t become easier or routine then perhaps there are other underlying problems either with trust on the team or a lack of genuine commitment to decisions.

 

 

Related reading

This is the fourth post on the theme, the five dysfunctions of a team.

The others are available here:

Are you ready for the fallout?

There is an old saying – An Agile Transformation is easy, you only have to change two things: Everything you say, and everything you do.

But actually, as obvious as that joke was, it is also wrong. You only need to change one thing, you need to change the way you think.

Project or Product

It is my premise that when we talk about Agile Transformation what we mean is transforming our thinking from considering our deliveries in terms of ‘Projects‘ to thinking in terms of ‘Products‘. And transforming from measuring people in terms of their effort, to measuring them in terms of their collective contribution to a shared goal (the value they add).

Projectan individual or collaborative enterprise that is carefully planned and designed to achieve a particular aim.

Productan article that is created or refined to satisfy a need.

As we have all discovered, software product development is complex, both in the development itself where we face a host of unpredictable variables, complications and unknowns. But, more significantly, it is very difficult to know what you want until you see it and consequently there are an abundance of quality software products that do not effectively fulfil the need that triggered their commission.

We have learned that reviewing progress regularly with stakeholders and modifying based on that feedback is far more likely to result in a successful product.

In most cases is is a fallacy to believe that for a complex and bespoke software solution you can know your end state before you begin, regardless of how well you analyse. And no matter how good at planning you are if you don’t know the end state your plan is flawed, and as you cannot predict the unknown even the best plans are unreliable.

We have come to realise that bespoke software delivery is far more akin to product design and development than it is to project delivery.

Management is doing things right; leadership is doing the right things.

Peter Drucker.

Agile Transformation is about moving from Management to Leadership

Peter Drucker is an inspiration here, traditionally we put so much effort into getting things right, to be more efficient, or to do this, by that deadline. That we forgot to ask if what we were doing was bringing value. We put all our emphasis on measuring and monitoring effort, or efficiency, rather than assessing if we are achieving our goal.

If you are considering an Agile Transformation it is likely that you have discovered that efforts to ‘manage‘ projects is leading to the wrong results and the focus needs to move from a focus on effort to a focus on value. To set a direction and ‘lead‘ the way in product development.  Try to stop measuring output and to start measuring outcomes.

Impact on Project Managers and Business Analysts

But this is a major cultural change for many companies and not an easy one. It is a complete shift in perspective, moving from planning the delivery of a project to collaborating on the creation of a product.

It is particularly difficult for Project Managers.

For project management to be effective the end state needs to be [largely] known, and for the steps to get there to be familiar and [largely] predictable. With a known end state and predictable building steps, a Project Manager can effectively work towards that aim.

But bespoke software is far more complex and is generally dealing with many unpredictable variables, the biggest variable being the end state. In the majority of cases the end state is not known at the outset and emerges in the course of the product being developed. The true end state needed to fulfil a need or want can very often be significantly larger or smaller than initially anticipated.  The ability and flexibility to pivot based on emerging information is crucial for delivering value and the product being a success.

Business Analysts similarly must adapt, project planning generally relies on a knowing as much as possible at the time of planning, and so there is heavy reliance on the Business Analyst. Product Development is again a mindshift for a Business Analyst, there is no longer a need for detail up front, in fact in most cases it is a waste due to the likely and frequent change of direction and priority as we learn so much as the product emerges.

Business analysis in an agile software product development means an early assessment generally at a high level is all that is needed, with detailed analysis happening much closer to when the work is done,  at this point much more is know about what is actually needed and so we are not wasting time analysing something that will not be done.

An Agile Mindset

Agile is a mindset far more than anything else, and when you start to look into it, there is nothing new, nothing original, and you will be surprised to find that whilst the word Agile has been used a lot by the software industry in the last 20 years or so, the practices and behaviours are just the good practices and behaviours of general management going back a century and possibly even a millennium or two.

‘Agile’ as we have come to know it whether we mean Scrum, Kanban, Lean, Lean Start-up, or any of the many other Agile frameworks is, in most cases a collection of historic good practices and guidelines identified by successful leaders and businesses in the past, they have been collected under one umbrella polished up a bit and marketed – very successfully – which is likely why you are reading this.  I say this to discourage the notion that ‘Agile’ is new and untested, there are certainly some misinterpretations and misapplications but the underlying principles are sound and based on a lot of experience.

Just as an observation, if you looked back at the early days of the Ford motor company as an example from over 100 years ago, and you assessed them against modern standards of agile my guess is that they would hold up very well.

Agile Transformation should not be your objective

Agile Transformation is often presented as the objective, when in reality it should be a strategy to reach a goal. Taking some time understanding what your goal really is, will make any transformation far more likely to succeed.

  • Are your customers dissatisfied?
  • Are your products missing the mark?
  • Do you(or your clients) feel you are not getting value for money?
  • Are you slow to market?
  • If you are creating software products for internal teams are they not having the impact you expected?
  • Are people circumventing your tools?
  • Is your ROI on software development too low?
  • Are you losing key development staff?
  • Is there a lack of transparency in the software development process.

These are just a few of the many reasons a company may want to undergo an Agile Transformation, they are all global business issues, and that is a key point: Agile Transformation is not an initiative just of the software department, it is a change for the entire business. It is a major cultural change that will impact your business from top to bottom. From the way you sell your products, to the way you hire staff, and particularly to the way you measure success.

 

 

Unless commitment is made, there are only promises and hopes

This is the third post on the theme, the five dysfunctions of a team.

The first two are available here:

With a natural or assigned Maverick on our team and a level of vulnerability and trust we reach the point where actual decisions can be made. Up until now we could consider the efforts to build the team to be the foundation, but now we have to put it in to practice.

This is also the point when it starts to hurt, this is where it really tests whether you truly have trust and are truly open to input and discussion and healthy conflict.  Many teams say they have built trust,  and many teams seem to have open discussion and healthy conflict, but this is where you test that.

Can you make a decision and follow through on it?

five-dysfunctions-pyramid

Consensus

Please do not confuse decision making with getting consensus. The goal of a team is not to please everyone on the team, it is to get things done, to make decisions that help us – for the team reach our team goals.  If we waste time trying to please everyone we end up either paralyzed, or with a watered down decision that accommodates everyone but satisfies no one.

“Consensus is horrible. I mean, if everyone really agrees on something and consensus comes about quickly and naturally, well that’s terrific. But that isn’t how it usually works, and so consensus becomes an attempt to please everyone.”

Patrick Lencioni

The funny thing is that most of us do not want consensus, nor do we always want to be agreed with.  Most of us are not unhappy when a decision is made just because we disagree with it, but we are very unhappy when our opinions and concerns are avoided; ignored; overlooked; or given only lip-service.

I want to feel valued

If I feel that my input is valued; listened to; if my concerns are discussed fairly and sensibly but the decision is made to proceed despite my concerns, then I can still buy in to that decision and crucially I can support it.

But if the decision gets made without me, or my input is so obviously not going to be given a fair hearing, then two things happen, first it won’t get my support, or my support will be shallow and half-hearted. Second, why would I speak up next time? We will just regress to a lack of healthy conflict.

It should be simple, if someone is on the team then their opinion counts, otherwise they should not be on the team.   If you cannot accept that, then perhaps you should not be on the team.  Being a part of a team has an implicit commitment to value each other.

Childrens-4

Unless commitment is made, there are only promises and hopes… but no plans.

Turn decisions in to plans

Getting to a decision is not enough, you need to turn those decisions in to plans and you need to turn those plans in to actions.

Plans are only good intentions unless they immediately degenerate into hard work.

Failing to commit to a decision is as bad as not making a decision – possibly worse. We should be clear what the decision is, and who and how it will be implemented.

Failing to follow through on a decision renders all the time and effort spent discussing and debating the right choice, null and void, it becomes waste. A waste of time and energy and will undermine a team as surely as the inability to have the conversation.

Be decisive and be clear

Whenever possible any decisions should be associated with a specific action, a date for it to be completed and a clear understanding of who will do it.

If we make the extra effort to identify who will perform the action and when it creates a foundation for the best chance of success, there is a clear and measurable outcome. Everyone knows what to expect and when. This is crucial for being able to hold each other accountable.

Wishy washy action items, that are for everyone with no expected date will generally get ignored, but something specific combined with the certainty that you will be held accountable and it will be followed up will likely mean it gets done.

Pointless conversations

If you find you get to the end of a discussion with sufficient healthy debate and the result is to take no action on a frequent basis, then this is cause for pause.  Could you avoid wasted conversations by injecting a Go/No go break a few minutes in to a discussion and ask the team: “If we reach a decision are we empowered to act?” or “If we reach a decsion would we be willing to act?”  if your answer is No to either of these, then save yourself some time and heart-ache, if there can be no action then the conversation is moot.

That is not to say all conversations must result in action, but all conversations should have that potential or they are waste.

 

 

 

dysfunctions

If I had to recommend one book that would help your team become the best Agile Software Development team, it would be The Five Dysfunctions of a Team by Patrick Lencioni, the book does not even mention agility.  But in my opinion the vast majority of questions I’m asked or problems I see can be traced back to something covered in this book.

 

 

 

 

 

 

 

 

 

 

Every team needs a maverick

Have you ever been on a team where the boss presents a new idea and looks around the team for a response and there is this one guy that breaks the silence by saying “What are you drinking boss? That idea is a bunch of crap” well maybe he was a little more polite but still the message was clear. Everyone else holds their breath waiting to see what happens.

Desire for harmony

For most people the desire to be liked and accepted leads us to have an overwhelming urge to conform with a leader (or the group majority) to maintain harmony, regardless of what we might think.  Sadly most people also have a very strong subconscious desire to be agreed with, especially leaders. When people agree it affirms their leadership and those that challenge are perceived as challenging them personally – rather than the idea itself.

perception

This all combines to create another horrible dysfunctional team, one where there is an absence of conflict. Well, apart from that one person stupid enough to speak their mind, and they’ll likely be fired soon, then we can all get back to agreeing with each other.
Now I am making light of it, but a leader that is able to understand conflict as healthy is rare, and one that can, in practice swallow pride and engage in healthy debate is rarer still.

The invisible threat

The problem though is that even with that rarest of leaders there is an invisible threat, the leader himself knows that he values conflict, that to be truly successful ideas need to be freely expressed and freely challenged, but everyone else can see the threat that is invisible to the leader, they know he still holds the power even if it is not overt, that invisible threat still causes teams to hold back and to create a false sense of harmony.

You may think that I am overstating the point but just think back over your career and how often does the yes-man or yes-woman get promoted over the more capable but outspoken. How many leaders surround themselves with people that will affirm their decisions rather than pushing for more. It is natural and normal to like those that agree with us far more than those that push us. But get over it! That behavior is limiting your team.

Solution

My solution to this problem is for every team to have an maverick, someone that is Not afraid, someone who will break the harmony spell and get the conversation started,  push ideas to be better, force plans to stand up to scrutiny, to trigger others into sharing their opinions. If you are lucky you have one already.  Turns out every team I’m on has one 🙂 but if your team doesn’t already have one (or more than one) then take turns, at the start of a meeting roll a dice, select one person to be devil’s advocate and it is their role to challenge ideas look for flaws or weaknesses, this will push the team to be better and can do so from the safety of an assigned role.

Devil’s Advocate:

The term a devil’s advocate describes someone who, takes a position he or she does not necessarily agree with (or simply an alternative position), for the sake of debate or to explore the thought further through discussion.

Try playing Devil’s advocate:

  • If you sense that some of the team are not buying in to a proposal but are not speaking up, make a challenging statement
  • If it is your proposal, invite disagreement by questioning your own proposal, by saying maybe I am wrong, or I think I missed something
  • Be clear on your motives, you must genuinely want healthy debate. If you invite disagreement but brush it off then it can further encourage artificial harmony

There is a difference between healthy debate and someone that is just obtuse, and conflict alone will not get you to results. But an maverick that is also a genuine team player is invaluable on a team. I’m not talking about jackasses here, but people who are not afraid to speak their mind, for whom honesty is more important than acceptance.

 

dysfunctions

If I had to recommend one book that would help your team become the best Agile Software Development team, it would be The Five Dysfunctions of a Team by Patrick Lencioni, the book does not even mention agility.  But in my opinion the vast majority of questions I’m asked or problems I see can be traced back to something covered in this book.

 

Once trust has been established the next step is to build on that trust with healthy conflict where ideas can be shared without fear, where opinions are heard and considered.