The Zone of Acceptance

One of the challenges of an Agile Coach, or anyone in a management or leadership role is establishing what I have seen referred to as the “zone of acceptance” for individual team members.

The Zone of Acceptance is a term for the tasks an individual sees as something they are prepared to do as part of their job.  This can relate to tasks, overtime, meeting attendance and more.

In a traditional model where work is explicitly assigned, this took the form of a team member saying “that’s not my job” when asked to do something on the periphery of their role. E.g. being asked to write documentation or attend a meeting outside core hours.  This is a direct confrontation that can be handled directly, the team member can be coached to broaden the scope of their ‘zone of acceptance’ and have it explained that sometimes responsibilities extend beyond core hours and core responsibilities.

However, when you move to agile it becomes much harder to deal with. We introduce the concept of self-management and self-organization, there is no longer an external person pushing you to extend your boundaries.

change

What is my Zone of Acceptance?

In my house I will sometimes come home to find the kitchen bin full or overflowing, if I ask why it has been left like that my wife will in a ‘matter of fact’ tone reply – “That’s your job!”  I don’t doubt that it is, at some point we agreed a division of responsibilities – , the responsibility is clear.

But conversely my behavior in a different situation is far harder to manage. My wife may ask me to change our child’s nappy (or diaper as my wife calls it), I will generally willingly comply, but I rarely volunteer.  I would never say it is not my job, but by subtly avoiding doing it I am implicitly saying that.  She can ask on a regular basis but that in itself undermines the equality and self-organizing nature of marriage, she shouldn’t need to ask. We have an understanding that generally works and in this case the reality is that she is not asking me to take the responsibility, nor is she demanding assistance, but my help is certainly appreciated.  What I need is to broaden my ‘zone of acceptance’ and to be more proactive in my support. We are a team.

That is not my job

The same becomes true in an Agile team, if I were to hear someone say ‘that’s not my job’ or “I’ll hand that over the wall to a tester” or similar comments, they can be directly challenged, and the coach or the other team members can act accordingly. But far more common is seeing the team members forming natural silos for work, an often agreed line in the sand where work is divided and not challenged.  They will avoid tasks they are not interested in or don’t see as their role, find excuses for working on tasks they see as theirs and in some extreme cases work on something outside the board to avoid picking up a card that doesn’t fall into their zone of acceptance.  This behavior may not even be visible, a team can actually become very productive in the short-term by forming mini-silos, but that doesn’t make it right or healthy in the long run.

I see the role of a Coach (or any Agile minded team member) to challenge these silos, to encourage team members to broaden their zone of acceptance, and to get the team to inwardly think that it is their responsibility to get involved in Story writing, and coding and testing and to be active in all meetings, to volunteer to write documentation and present the Demo, and to challenge those that don’t become active members of the team.

“But I’m a tester I don’t know how to code” – is a common argument. My response – “So what!” a lot of coders I know would benefit very much from having a tester on their shoulder asking if they had considered this case or that case, challenging the use of TDD and actively engaging in what and why things are being coded even if they don’t understand the code syntax itself.  And perhaps more controversially the opposite is true, having a developer sit on the shoulder of a tester and see what and how and why certain tests are performed can help improve the way a developer writes code. I think we can make passable testers of most developers and vice versa, teams should want to challenge boundaries. In the long term I’d suggest those roles should become indistinguishable from each other and in an ideal world they would be one and the same – a team member who would do what they could and what was needed.

Jack of all trades

By this I am by no means suggesting that we create a team of jack of all trades – I am actually very much against that, expertise should be encouraged and my view is that testing; coding and design etc. are very different skills and expertise in each should be valued. But my view is that the comparison of skills needed to get a user story to ‘done’ will often form a huge amount of overlap and likely a combined involvement.

purple jigsaw

If each user story represents a piece in a puzzle, chances are that there are a few parts that will require a specialist in ‘Blue’ or expertise in ‘Red’ skills, but the majority of the work is shades of ‘purple’ something that does not require particular expertise  and could be achieved by anyone on the team or through a mix of people. We often use edge cases as examples so we can dodge the normal cases, when we see that we should call it out.

How do we expand the Zone of Acceptance?

But now what? We understand the problem, we know it is hard to spot and hard to challenge, so how on earth do we expand the zone of acceptance?

The first step is nearly always acknowledging there is a problem. Discuss it with the team – maybe as part of a retrospective and see if they recognize it as a problem too.
Let the team find ways to solve the problem. Once they see themselves as a team it becomes easier as they will be seeking ways to help each other rather than looking for the easy way out for themselves.

One team I work with identified this problem for themselves and their solution was to put a sign on their task board that said: “Have I done this before?” And another sign that said “Is this on the critical path?”

have I done this before

The idea was that when selecting a story the team member would stop and think:

  • First whether they were taking a task that someone else could take and learn – or maybe they could pair and teach someone else to share their knowledge;
  • Secondly “Is this the next highest priority or am I taking an easy option?  Some team members will cherry pick from the backlog rather than taking the highest priority item.

By having a written reminder it can become a challenge at stand up. The team members can call out each other if they see either of these behaviors.

Great Team Players

This barely touches the surface of this particular problem, but there should be a desire by the individuals on a team to (sensibly) broaden their zone of acceptance, for the focus to shift from what is the next best(or easiest) task for me to what is the next best task for the team – and even better what is most valuable for the customer.  And more significantly for this to be supported and encouraged by the team and the organization as a whole. Too often the organization rewards ‘star developers‘ rather than great team players, that message reinforces bad behavior and can be extremely corrosive to the organization over time.

Mindset or method?

Straw poll:

Should we teach practices and methods in the belief that an Agile mindset will evolve from the good practices?

or

Should we teach an Agile Mindset in the hope that with an Agile Mindset good practices will emerge?

Related image

I know of a few Scrum Masters and a few Agile Coaches in each camp, and some that feel very strongly on this topic. And of course the choice lies at the heart of most Agile Transformations and the outcome will therefore be far reaching.

Method over Mindset

Around 10 or 11 years ago I was introduced to a new way of managing projects and a new software tool for doing it. I was trained in how to use the software, but not in the theory behind the tool.

We are what we repeatedly do. Excellence, then is not an act but a habit.

– Aristotle

The tool was amazing, it really blew my mind. As a Project Management tool/method it made more sense than anything I had used previously and I loved it, I happily used the tool and got good results. But despite having the tool I never learned the theory and didn’t even know where to look to find out more.  No lack of interest or enthusiasm but I was content to use the methods and it helped in my current situation but I was never able to make the leap to more than a method despite my enthusiasm.

It is a little beside the point but the tool was Critical Chain for Project Management and before I was introduced to Agile I thought this was the best option out there for Waterfall projects (probably still is). Sadly despite it being so great, it was still based on the assumption that the end state was known at the start of the project, which for me is the ultimate failure of Waterfall thinking, and my primary reason for moving to Agile.

Only much later did I discover the theory behind the tool was The Theory of Constraints and the 5 focusing steps, IF only I had been shown that and I feel my enlightenment would have come much sooner.  But a method without understanding the theory leaves you unable to adapt and improve, I was limited to the context in which I was shown.

What is more I had a co-worker that struggled with the concept of slack and wanted to follow the method apart from that one aspect – the lack of understanding left him unable to differentiate between a necessary aspect of the method and an arbitrary one, and ultimately for him the tool didn’t work because he rejected the necessity for slack.

A lack of understanding of the theory leaves you unable to differentiate between a necessary aspect of a method and an arbitrary one.

– John Yorke

1cf58fa9895dafded2997558ab348190

Method over Mindset, the Return on Investment

Another consideration is that teaching theory takes considerably longer and has a much lower conversion rate. That is to say that I could teach the Scrum framework fairly quickly – a matter of days, and be pretty confident that the instructions are clear and ‘could’ be followed effectively. To take that same group and to teach them the theory to the point of understanding the why behind each of the practices could take weeks or months, and likely longer before they are fully understood. It is also possible that some will never grasp the theory but are still perfectly capable of being good team players.

Continuous improvement is better than delayed perfection

– Mark Twain

Many organizations are interested in the short-term results rather than long-term understanding and so there is a desire to do the least for the most impact. So we see the evolution of phrases like ‘Scrum-but’ as a means to discourage deviation from the defined framework. Our goal becomes to repeat, rather than understand.

Mindset over Method

cropped-serres-view-4.jpg

If you want to build a ship, don’t drum up the men to gather wood, divide the work and give orders. Instead, teach them to yearn for the vast and endless sea!

– Antoine de Saint-Exupéry

The flip side of this is the desire to teach/show the impact of having an Agile Mindset and then having the individuals identify a solution using that knowledge.

Clearly this is a much greater challenge, even those with an Agile Mindset will initially lack any practical applications to draw upon, even the most Agile of mindsets is limited to what they have experienced or read about, and contriving a new bespoke process to your environment may ultimately be the most desirable solution. However, it is impeded by the ability to share that vision and understanding with others, and limited by your understanding, ability and creativity.   And frankly do we really think that we are able to come up with a better framework than Kanban or Scrum on our first pass at an Agile Transformation?

A middle ground?

As you have probably guessed I am not a fan of either approach. I believe that most people will not become Agile overnight and even the most eager of minds will take time to absorb and understand the implications and possibilities of Agile.

I further believe that teaching Scrum as a closed framework that must not ever be deviated from is not the solution. Instead I would compare it to learning any new skill, we teach good practices and when you have mastered them you are ready to move on, we may teach a variety of good practices so you have some comprehension of the possibilities available, that way you do not limit your thinking so just one solution.

But we learn to master the basics, and we learn to question ‘why?’ when we feel we have mastered the basics and we understand why, only then we are in a position to start to evolve.

Applying Lean and XP and Kanban to the Scrum framework can let you grow in understanding within a safe set of guidelines. And when you understand the mindset enough to comprehend the limitations then maybe you are ready to craft your own solution.

If you can’t explain it to a six year old, you don’t understand it yourself.

― Albert Einstein

 

Why I recommend Scrum

Personally I love Scrum as a foundation for a transformation to Agile for those undertaking software development projects, not because I believe it is better than Kanban or other tools, but because to succeed with Kanban you need a level of self-discipline and understanding that is often absent for those new to Agile, and it becomes far to easy to gold plate or run long.

Scrum adds some safety nets and feedback loops that counter many of the usual “human nature” problems that arise from teams new to self-organization. Self-organization is a skill we need to learn and develop like any other. Scrum is so simple to learn, and easy to follow (if you are willing) and once you understand the Agile mindset it is a great framework for evolving into a great Agile team. But like any tool if used inappropriately you can make a mess. But any change requires a good guide.

That being said for support or reactive work Kanban is ideal as the discipline generally comes from outside. It is never a one size fits all.

Leadership

Method without mindset can only take you so far

Teaching the mechanics without teaching the theory is only half the task and whilst it is sufficient for many consultants to get paid, what they leave behind is a culture unable to improve, and without improvement entropy will set in.  I believe both some guidance on the mindset and instruction in some methods are both necessary for a successful Agile Transformation, along with a healthy amount of enthusiasm and patience from those leading the transformation.

 

 

 

Motor City – A Kanban Game : Overview

JSY_1323

Game Overview

The game is designed to reflect a simplified operating of a delivery pipeline for a car manufacturing plant.

The player accepts orders from customers, chooses which products to make and allocates resources and manages the plant to deliver cars to customers in the most effective way possible.

JSY_1267

Kanban

Each player manages a separate board representing a factory, the board is laid out as a Kanban board and the production is tracked as it moves across the board.

JSY_1279

Wip Limits

In the core game WiP limits are optional. Players may choose to apply WiP limits to manage flow, or just use their instincts.

If played for fun the WiP limits are not explicit, but if using this in a training environment I’d encourage explicit limits and for them to be strictly enforced to enable the class to evaluate the impact of WiP limits on the game.
I’d also suggest that each player experiment with different WiP limits to compare the impact with each other and discuss the results.

JSY_1276

Accepting Orders

At the start of a shift a player may choose to review and accept an order, once accepted an order must be delivered and if the player fails to complete an order they will be penalized.

Sourcing Materials

Each shift all players may choose to source materials for their production, this is done by selecting vehicle cards from the available selection, only 4 cards are visible and players may only choose from those available – this adds some competitiveness over resources, and an element of understanding your constraints and dependencies.

JSY_1264

Production

At the start of each hour within a shift one player rolls dice to determine the available production points for all players (all players get the same to make this game about the allocation of resources rather than the luck of the dice.

Each player is allocated a quantity of Manufacturing, Assembly and Quality production points which they can allocate over the course of the hour. Unused production points are discarded. The player also has the option to trade production points of one type for another but at a 4:1 ratio to indicate the impact of repurposing machines.

The vehicle cards are pulled through the system and production points are allocated as they progress through the system.

JSY_1305

Bottlenecks

There are a number of potential bottlenecks in the system and how you manage these will heavily impact the result of the game.

Game Success

Ultimately the winner will be the one that manages the production most effectively to meet their customers’ needs. It is hoped that applying Kanban and Theory of Constraints Practices will be rewarded, although there is an element of game mechanics and chance.


Purchasing the Game

The game is for sale at $120 + postage and is available now.  Game contains 4 game boards so is suitable for 4 players (or 4 pairs).

Please email me at john.yorke@yorkesoftware.com to arrange to buy the game.

Thank you for your support and encouragement.

JSY_1308

 

The 4 steps to successful software delivery

After [reading / posting] a recent article on waste, (read it here), someone asked me why we shouldn’t do work that we will need later if it is more efficient to do it now?  You have already dug the hole—doesn’t it make sense to do all the work in that area together?

This is very similar to the argument for splitting stories horizontally along business layers: “We can be more efficient if we optimize and specialize.”

Yes, you might achieve local efficiencies by taking these steps. But local efficiency is not the most important factor in your decisions. Efficiencies and optimizations need to be considered in the context of the whole system.

The primary goal is to Maximize Value Early

For both project and support work, our goal is to maximize value for our organization, and to realize this value as early as possible.  In a consultancy firm, there is a slight abstraction, as work is paid based on time and materials, and these steps are distributed between client and team. Regardless of who owns the following steps, success depends on shared awareness of these priorities.

The 4 Steps

The four steps are designed to focus our energy where it will have the most impact first, and then building upon the previous step by shrinking the focus area through each subsequent step. Hence they are in descending order of impact.

1 – Prioritization
(Selecting Which Project/Product to Build Next?)

The most important decision your organization needs to make is which work will bring the most value NEXT. This has the most impact on your company’s bottom line, so should get the lion’s share of effort and focus.

Program Management

 

Describing the value a project will bring is far and away the most important aspect of software delivery. If possible, create a formula for calculating business value to help with these decisions. If you are unable to quantify or qualify the value to the organization of the work being undertaken (at a high level), then you are likely working on the wrong thing and all other actions you take could be waste.

Some projects/products will obviously bring in huge amounts of revenue. Others may save huge costs in manual entry and work-hours. Some may support business-critical systems that, if not supported, create extensive risk and potential cost. A project might also fulfill a safety or regulatory concern, or business objective.

Naturally this is complicated and can be difficult. Priorities change. Time factors and organizational politics come into play. A lot of the time you will be making informed guesses about value and costs. But this decision dwarfs all of the others in the impact to the bottom line, so is critical to put the right amount of effort here.

I would consider this to be the responsibility of the Program Manager or Project Management Office, but I see the responsibility to be to identify the projects that will bring most value to the organization as the end of their role. “Day-to-day Project Management” responsibility lies elsewhere.

I would however strongly encourage this decision-making process to be transparent and inclusive.  Hold a regular Project review board and invite the stakeholders. Make the process clear and help everyone understand how the decisions are made. I would also suggest a visible roadmap of work planned.

Finally, I would encourage you to not plan beyond your company’s horizon. If new work is likely to emerge in the next 3 months that may significantly change priorities, then only plan for 3 months.  Only start a product or project at a point you feel committed and certain it will be completed. Starting something with the expectation of pausing or pivoting suggests it wasn’t the most important thing to work on next.

2 – Direction
(Product Ownership – Building the right Product)

Whether this a new product or supporting an existing product, it is important to ensure that you build the right product,  Product Ownership is covered in lots of detail in other places so I won’t go in to details but I suggest watching this video:

po nutshell

Like prioritization in Step 1, the most important responsibility in Product Ownership is Maximizing value–Are you working on the most valuable thing next?  You do this through experience and through feedback from users and stakeholders.

Feedback is crucial. To get frequent user feedback, you should be thinking about how you intend to deploy your software and then update it regularly. You should be thinking of this before or with your first story.

Deployment and ongoing updates should not be an after-thought.

Product Ownership is also about maximizing the work not done. The product should meet the needs and goals but only do what is necessary. There will be a point when the returns diminish. All work carries an opportunity cost, and at some point your time is more valuably spent elsewhere. Understanding this is vital.

Finally, I want to stress the importance of getting value to the customer quickly. Value is only realized when the software is used. We should be striving to getting the software in use as soon as possible. This may be in an unfinished state. It may be only a partial solution, but it should be adding value. e.g. it can be used alongside an existing product, or it could be used for this workflow but for another you use another tool etc.

Feedback from people actually using your software is the most valuable feedback you can get.

Just like prioritizing projects, prioritizing stories has far more impact on the success of the project than the following steps.

3 – Quality
(Build the Product Right)

Building the right product is more important than building it right. Building the wrong product is just a waste. But that doesn’t mean that quality is not important.

Quality means doing it right when no one is looking.

Henry Ford

When assessing cost of software, it is easy to focus on the initial development cost alone. But support maintenance and future enhancements all fall into the total lifetime cost of a product. The cost of defects magnifies over time, and the cost of supporting poor quality code is significantly higher and more risky. Re-learning and knowledge transfer are painful and costly to an organization and I can think of numerous examples where companies have been forced to abandon projects or replace software because they lost a key employee who had the knowledge locked in his head–or software so fragile no one dares touch it.

Good practices such as Test Driven Development, Pair Programming, Behaviour Driven Development and Automated Regression Testing may seem costly at first. But when considered in the context of lifetime cost, they are a sound investment. More importantly, they enable the right business decisions to be made because there is a confidence in the software.

Quality code with a solid set of tests enables refactoring and new features to be added with the knowledge you are not causing unintended consequences elsewhere by breaking older functionality. This reduction in risk is a considerable advantage, especially when supporting older applications.

This is not a carte blanche to gold plate or over-engineer. Quality Code is the right code for the story and No More. We write just enough to satisfy the story and we write it well. Over-engineering applies to the GUI too–we don’t add features or over-engineer.

4 – Efficiency and Improvement
(Building it Better and Faster)

By this point we should be working on the most valuable product to our company. With that taken care of, our next focus is to work on the most valuable feature or story for our users/customers. We should be doing it in a manner that enables us to be confident in the work and able to expand it later.

But guess what? You can do it better.  We should reflect on the decisions we made and how we make them. Are we making the right decisions?  What helped us make those decisions?  Are we making the wrong decisions? If so what could we change to avoid repeating those mistakes.

The reflection and improvement should be done at all steps and should incorporate the learning from all stages.  If we continually look for ways to improve we will get better and better.

If you always do what you always did, you’ll always get what you always got

Henry Ford

 

What about efficiency of developer effort?

So what of the original question about being more efficient with horizontal splitting of stories, or the perceived inefficiency of re-working the same area of code later?

It is a question of impact and perspective. In both cases the question is founded on ‘efficiency’ being a measure of the developer’s efforts.  What I would like you to consider is that in terms of delivering value to your users and ultimately your company efficiency should not be measured in terms of developer effort, but should be measured in terms of delivered value.

Efficiency should not be measured in terms of expended effort, but should be measured in terms of delivered value.

The most valuable decision is to work on the right project – this dwarfs all other decisions by an order of magnitude. But it is at a different level of scope than this question.

The next most valuable decision is what to work on. This generally best considered from the perspective of delivering value to the customer quickly and of being able to respond to their changing and emerging needs.

When we split horizontally or when we do extra work, we know we will need later we may give the appearance of making more efficient use of developer effort, but in doing so we reduce our ability to adapt to changing needs and more significantly we delay the time to deliver the next most valuable feature.

This is an example of working with a waterfall mindset. The measure is that while it delays us this week, we will make back the time next month or next year. So if we are not planning to deliver this to our customer until next month or next year, it might appear to make sense. But you may not have considered two factors.

If we are deploying frequently, we are realizing value with every release and in the value of our software isn’t massively more than the cost of developer time to create it, then it is likely we shouldn’t be working this project at all. So ultimately the cost of developer effort for having to rework the same code later for a new feature is insignificant to the value gained by delivering sooner. We should measure ourselves based on value delivered not the effort to deliver it.

The second consideration is that the work you are doing on the assumption of needing it for a future feature may not actually be needed. That feature is by definition lower value and less important as it has been prioritized lower.  There is a pretty reasonable chance that the customer may change their needs or there is the possibility of the project being cancelled or considered good enough as it is.  That work may never actually be needed and you would have delayed the project for work that had no value. The efficiency you are trying to achieve may just be an illusion.

This is the business equivalent of spending $10 today to save $1 next year.

When considering efficiency and improvement, remember your goal is to maximize value to your customer and to realize that value as quickly as possible.  Ask yourself if the efficiency improvement you are proposing fulfills those goals? If not it may be just be an illusion.

 

 

 

 

 

 

Identifying Waste in Your Processes

I think as agile practitioners we can learn a lot from Lean thinking and there are a number of concepts of Lean that I think apply very well to Agile Software Development.

This is the second part of a blog attempting to convey the Lean concept of waste and I have introduced some ideas for how we can help mitigate waste in an Agile environment.

The 7 deadly sins

Lean identifies 7 wastes  (recently adding an 8th Waste)*

  1. Over-Production
  2. Inventory
  3. Transportation
  4. Over-Processing
  5. Waiting
  6. Motion
  7. Defects
  8. Wasted Potential of People*

 

Over-Production

explored in more detail here.

 

Inventory / Work In Progress

In manufacturing the physical properties of inventory are obvious, piles of raw materials, stacks of part built products, warehouses of finished goods are all big and obvious, but in software, inventory is harder to see, it is intangible to the casual observer.

In software, Work in Progress takes many forms, most obviously this is in the form of code, any code not deployed to a customer is Work In Progress, that code cost time and money to create, the raw materials are developer thought and effort.

But Inventory is not just code, it is also knowledge, it is thought and problem solving, unrealized ideas and even experience and learning.  Code is the manifestation of thinking, problem solving and planning. WiP/inventory is also the consequence and ideas resulting of conversations with users, usability testing, marketing. All of these are the efforts needed to create a product. But until those efforts are turned into a product it is all potential waste: time and money that are spent but until released to a customer are not providing value.

If we can learn to manage our Inventory/Work In Progress to limit it to only what we need and only what we can benefit from in a reasonable timeframe we can cut back on excess Inventory which in business terms this can have a major beneficial impact on our cashflow. Reducing Work In Progress also has the added benefit of making it easier to see  other waste.

Effectively managing your WiP is probably the second biggest opportunity for waste reduction and the act of limiting WiP will help identify other wastes in your system.

Transportation

In manufacturing, there is deemed no value in transportation. Moving a product does not add to it’s value and may even damage it with wear or breakage. reducing the distance between workstations or distance from your raw materials or the distance to customers can reduce the cost of time or effort and reduce the risk of wear or damage.

In software transportation could be best viewed as hand-offs, handing off work to another person or team requires effort, bringing them up to speed, co-ordinating, sharing the work. All this time and effort does not add any value to the software. But worse there is consequential loss of knowledge when there is a hand-off, and each hand-off results in a greater loss as the knowledge becomes fragmented and dispersed. Vital information may not be passed on leading to poor decisions, this is equatable to a breakage during transit.

Limiting hand-offs can reduce waste, having a team that contains all the knowledge and skills necessary to complete the work can help.  Steps to improve and enhance communication so that less knowledge is held by a small number of people can mitigate the loss of knowledge during a hand-off.  E.g. have all members of the team involved in story refining meetings so everyone is apprised of the intent of a story and can ask questions.

Over-Processing

In manufacturing this is making a product to a higher standard than is required or spending longer on something than is necessary, or in using a tool that is over powered for the job at hand.

This is similar to Over Production in many respects as is it unnecessary work, but in software it is obfuscated.  A feature may be needed, but we have over engineered it, spent more time and effort on it than is necessary.  This is not an excuse to cut corners, but development and test effort should be reflective of the customer need.

TDD – Test Driven Development can help here, by writing the test first and limiting coding to passing the test can help reduce over-processing.

However, many developers engage in EDD – Ego Driven Development where they write unnecessarily complex code to solve a problem so they appear clever to their peers.  Or RDD – Resume Driven Development where they introduce a shiny new: tool, technique or gadget, because… ” it is shiny and I wanted to try it out” or “It will look good on my resume” rather than because the product needs it.

EDD – Ego Driven Development where developers write unnecessarily complex code to solve a problem so they appear clever to their peers.

There is another form of Over-Processing and that is writing software to solve a problem that could be done more easily another way.  We have a great desire to automate everything but sometimes the solution costs far more than the problem we are solving.

The waste of this seems obvious when described here but can be difficult to spot in the wild, pairing and TDD can help keep the focus on the goal and limit the opportunities for over processing.

Over-Processing – Re-Learning

Another aspect of over-processing is the act of re-learning, if you have solved a problem once you should not need to solve it a second time, or if someone else has solved a problem can you benefit from their learning.

We can reduce this waste with knowledge sharing within the team or having the whole team in discussions about design or story refining so that opportunities to avoid re-learning are increased.

Avoid long delays between first looking at a product and then coming back to it later where you need to remind yourself of context better to only start work on something when you are ready to see it through.

Waiting

Waiting is any time that the product is not being actively worked on, this could be a story that is blocked waiting on someone or some event.  I think most people see that as waiting time, but any card that is not being actively worked at any time is ‘waiting‘.

Any state such as ‘dev done’, or ‘QA done’, or ‘ready for test’ or ‘ready to deploy’ or even stories written but waiting in the backlog are ‘waiting‘. Most stories will spend far more time waiting than they will being worked.

This is often a symptom of having too much work in progress, but items waiting may be a sign of a bottleneck or potential areas for improvement in your workflow. Kanban focuses on flow – minimizing the waiting time, so identifying any area where there is excessive time waiting is a candidate for improvement in the workflow.

Keeping track of repeat blockers, or being aware of areas of your system where stories regularly spend time waiting can help reduce this waste. Challenge any story that is not actively being worked and ask why.

One technique for this is for team members to each have only one avatar and have them place it on the card/story they are currently working on.  Any card without an avatar is waiting.  Only allow one avatar per person.

Motion

Similar to transport in many ways but refers to the operator or the operation rather than the transport of the product, could the workstation be operated more effectively.

In software this is sometimes interpreted as Context Switching which unnecessarily slows down the team, this is certainly a major part of it, but I prefer a broader interpretation, anything that hinders the team from getting the job done effectively, this could be having the right tools, the right environment, the team working effectively together, communication barriers.  But I can understand the desire to focus on context switching such as: support calls, emails, even distractions in the office space are forms of task switching that impair the effectiveness of the team to get the job done.

Identifying ways to improve the work environment and limit the interruptions could cut huge amounts of wasted time from your workflow.

Defects

Defects are another waste that gets compounded as a defect is exposed to all of the other wastes as it goes through the system which magnifies a problem that is already serious.

Defects are waste that grows the longer they go undetected, the problem itself is magnified by time and use, the more time the more frequently the defect occurs and the more users it impacts the more it costs you. That is until reported it is a hidden cost.

The waste is a hidden waste until much later so it can give us a false sense of security until the product reaches end of life and we have a full picture of the total lifetime cost we will not know the true extent of the cost of defects.

Another factor is that the cost goes beyond the impact of the defect itself the longer it goes undetected the less recent knowledge the development team has of the subject and so the learning time goes up.  How often have you been asked t fix code of someone that left the company years ago and have no clue what they were writing.  Once again one waste impacts another if that developer was using EDD you may have code that is so complex the effort to resolve is much higher.

We can try and combat defects with good development practices, such as pair programming, TDD, and comprehensive regression testing.  Any efforts we can find to identify defects sooner or prevent them occurring reduces the waste and the long term impact.

Wasted Potential of People

I have seen this added as an 8th waste of manufacturing, and it goes doubly so for software development.  In software development people are your greatest asset, it is a creative knowledge based activity and so providing the right work environment and opportunities is essential to getting the best from your people.

Demotivated people work slower and with less care, but enabling people to reach their full potential could reap rewards for you and your products.

Summary

Any system will have waste, some is necessary and some is not, but being able to identify what is necessary and what is unnecessary or what is waste and what is slack can greatly enhance your chances of making improvements that really help your software development process.

Often what you thought was waste is actually a valuable activity and what you thought was adding value was just adding waste. Understanding this helps you make the right decisions.

However, please remember – It is very important that waste reduction is NOT the Goal of your efforts,  Waste Identification is a supporting activity for the Theory of Constraints, any efforts to improve a part of your system that is not the bottleneck is a waste in itself.

Your goal is to improve the entire system and focusing on one area without consideration for the system as a whole leads to the wrong decisions being made. Waste is just one of many considerations.

 

 

 

 

 

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

Applying the Theory of Constraints to Agile Software Delivery

In ‘Agile’ circles there are certain topics that come up frequently, such as Kanban and Scrum, so much so that we often forget that Agile is a mindset rather than a small subset of methodologies.

As the saying goes there are a great many ways to skin a cat, but limiting ourselves to only a few may constrain us from opportunities to improve.  The Theory of Constraints is one of these overlooked options.

The Theory of Constraints (TOC) is often assumed to only apply to industry and manufacturing, which is very sad. TOC is in my opinion the very example of an Agile mindset applied to industry and the techniques can be applied very effectively to Agile Software Delivery.

TOC5

Some common applications of TOC

  • Ongoing Improvements
  • Improve flow
  • Incremental delivery
  • Smaller batches of work
  • Reduced Work in Progress
  • Focus on maximizing customer value
  • Reduce firefighting
  • Reduce inventory of undelivered ‘finished’ work
  • Reduce speculative work
  • Reduce reaction time – ability to pivot sooner
  • Identify potential productivity improvements
  • Expose underutilized capacity
  • Identify skills shortages
  • Identify blocker clusters
  • Identifying new markets or new ways to engage with your market
  • Using cost of delay principles to prioritize work

TOC1

System Thinking

TOC starts and ends with system level thinking, your organization as a whole, not just your team, the whole market, not just your current customers or your current market. TOC requires you to look up and around rather than just looking down.

The Theory of constraints uses the term ‘theory’ in the scientific sense, it is a well defined set of practices that have proven to be very successful when applied appropriately.

The guiding principle is that improvements to anywhere that isn’t your bottleneck is worthless. Think of adding a third row of seats to a car that only ever has one passenger. and that improvements to your bottleneck improve your entire system as a whole so should not be measured in isolation.

This can often feel confusing and counter intuitive, it can sometimes result in decisions that increase local costs and even reduce local efficiencies.  Say shipping by air may seem far more costly per item, but results in an increase in sales that far out strip the increase in costs.  Shipping got less efficient and costs went up, profit per unit went down. All seemingly unwise decisions when considered in isolation.  But the result was that sales went up and so profits increased faster than sales.

And that is the heart of the problem, most organizations create silos and fail to consider the impact of opportunity cost on the organization as a whole. This mindset leaves the shipping department seeking to reduce costs without considering the impact on sales.

In IT this may be seen as saving money by sharing an expert between two teams which means their utilization is high (they are perceived as efficient) but they are not fulfilling their purpose in a timely way to their teams which actually costs the company far more in opportunity cost.  Sadly opportunity cost does not show on a balance sheet and so cannot be seen unless you look for it, and understand the significance of it’s impact.

Having dedicated resources with built in slack often causes traditional managers and PMs to have kittens, they cannot bear the thought of costly resources being underutilised, they only focus on cost, not on the value that people bring and that thinking could be crippling your organisation.

TOC3

Contrary to popular belief your company’s goal is not to keep all workers busy all the time,  it is to be the most profitable it can be now and in the future.  That means effective use of people and not maximum use of people. The two are not the same and until that is understood your company’s profits will suffer.

In agile we suggest dedicated teams and to minimize multi-tasking, limit WiP and so on, this often leads to under utilized resources(people) but far more value to the customer and generally more profits.

Dependent Events

Another key principle is the impact of statistical variation on dependent events.  That is a bit of a mouthful but basically it means that in any given time period, output from a person or a machine varies, neither people nor machines are consistent, we have good days and bad days, some tasks take longer than others, we encounter problems and so on.

The results is that variation in output of one item in a chain impacts on the next and so on, and the longer the chain the more stages are impacted and the more variation disrupts the flow.

This is hard to explain without a demonstration and few people get it until they see it for themselves. Goldratt explained it really well with a game in the book The Goal, but sufficie to say balance is a fallacy.

Balancing the items in a chain (people, processes or machines) does not solve the problem, TOC explores techniques for managing flow to mitigate these problems.

Agile teams apply many of the flow management techniques TOC advocates – training T-shaped people, reducing hand-offs, buffering work, smaller stories, more paths through the system, continuous delivery. These are all techniques that come directly from the Theory of Constraints and have been adopted by Agile development teams.

littles-law-queue

Summary

You would be surprised at how many good ‘Agile’ ideas have come from the Theory of Constraints and yet we continue to consider it to be for industry rather than software. Think how much more we could be missing by not applying the thinking processes.

I’ll try to cover some of the aspects of the Theory of Constraints in future articles with some ideas of how they can be applied to software development.

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.