Feedback is not a passive activity

In Lean manufacturing setting up feedback loops is considered a critical part of the operation, so much so there is a term for this – Andon – a system to notify management, maintenance, and other workers of a quality or process problem.

download (1)

The principle is that it gives the worker the ability, and moreover the empowerment, to stop production when a defect is found, and immediately call for assistance.  Workers are encouraged to use this feedback mechanism freely. Common reasons for manual activation of the Andon are part shortage (dependency), defect created or found, stoppage, or the existence of a safety problem. Work is generally stopped until a solution has been found.

Loosely translated an Andon is a Paper Lantern – To shine a light on a problem.

andon

Sounds great in principle, any worker is empowered to give feedback to management if they have concerns over safety quality or even a weakness in a process, but for it to become culture it needs to be adopted in a no-blame manner and used frequently, lack of utilization of an Andon is a serious problem and is addressed in Lean.

If a feedback mechanism is not triggered regularly then the settings are considered too loose.  The threshold for triggering an Andon would continually be made tighter and tighter, quality is expected to be higher, time for a task is squeezed and so on until there is an increase in frequency of Andon being used.

The aim is to get a regular feedback of actionable information, too little and the feedback loop has failed, too much and you cannot see the problem so it needs tuning and adjusting slowly.

What does that mean to us in a non-manufacturing environment?

We have got pretty good at retrospectives and giving feedback locally, but feedback to management is largely absent.

devops

The difficulty in many organizations is that senior management hide behind an open door policy.  “Employees can talk to me any time, my door is always open”. It is very easy to pretend you are open to feedback but much harder to actually be open.

“Employees can talk to me at any time, my door is always open”

– the unapproachable manager

In many cases the open door is actually an invisible barricade: fear of retribution, fear of not being supported, fear of being ignored, fear of the messenger being shot.  In many cases the fear is justified,  but even when it isn’t, it doesn’t make the fear any less real to those with genuine feedback to share.

Creating Feedback Loops

Just like with Andon, this is feedback that should be sought and encouraged and your measure should be how frequently you are given constructive feedback from your employees, if you are challenged regularly and respond to it regularly then it is working, but if you are not getting regular feedback (from those outside your inner circle) then it is likely your “open door”  is not that open.

opendoor

Has someone in the last week given you critical feedback without being asked?

If on the occasions you do explicitly ask for feedback are you bombarded with hostile questions? Do the questions catch you by surprise? Do people seem dis-satisfied with your responses? Do you only ask for feedback when people quit? If yes then perhaps you are not asking for feedback often enough, or are not responding to the feedback you are getting.

Feedback is not passive

Feedback is generally not passive, you need to invite it, create forums where feedback is invited and expected, be open to the feedback and when you are not willing to change be prepared to explain yourself, and be prepared to repeat yourself.

It really comes down to whether you truly are a feedback culture, if you are you have to work for it.

 

 

 

 

 

 

 

 

Are you working too much?

Would it surprise you to learn that the person in your team or company that regularly works 60 hours a week (and makes sure everyone knows it) is very likely the least productive person on the team?

The person working 60 hours is likely the least productive person on the team.

And I don’t simply mean that productivity diminishes after 40 hours, I mean absolute total productive output is less from someone working 60 hours compared to someone working less than 40.  The reality is that you would actually get more done by NOT working that time than you will working those extra hours.

This is a hard pill to swallow in a culture where ‘working hard’ is seen as a virtue, and the more hours I work the more virtuous I am. Long hours are often assumed to show commitment, dedication, loyalty. Maybe they do, but they don’t show productivity. If your company values those things above actual productivity then so be it, but understanding that it is about those attributes rather than productivity is a rather brutal fact to face. However, if you want to produce more and maintain high quality then you need to work less hours.

Parkinson’s Law

I am likely to offend a few hardworking people with this but my assessment of the findings of these studies is that is is a subconscious manifestation of Parkinson’s law. “Work expands so as to fill the time available for its completion” If I expect to work 60 hours then I’ll make my work last 60 hours.

parkinson 2

Not just a European thing.

Europeans have a reputation for favoring reduced working hours and I’m sure it is an ongoing frustration to those in America that despite typically working more hours, American companies are consistently similarly or less productive than their European or Japanese counterparts despite the longer working hours and less vacation.
Interestingly, the study I’m quoting was actually a 12 year study by the Ford Motor Company of production in the USA.

Henry Ford… again.

Before I go into the study in more detail I’d like to go back in time and talk about the history of working hours and in particular Henry Ford.

If we go back 150 years there were campaigns all over the world to reduce the working week from 16 hour days, 6 days a week – 96 hours was considered a normal working week for many. Forward thinkers pushed for limiting the working day to 10 hours with breaks for food – a radical concept at the time.

MayDay

Over time much of this became law despite fierce objection from industry, and by 1914 a normal working week was 9 hour days, 6 days a week.  The pressure until then mostly came from humanitarian motives and agendas, and perhaps because of that, businesses took steps to prevent it taking hold, reducing pay in line with reduced hours so a reduction of 20% of hours came with a reduction of 20% in wages, this undermined the whole movement.

But then came Henry Ford. Ford created the 5 day working week, and a limit of 40 hours, but best of all he did it for profit and not for social good.  At the time his factories worked 6 days and 9 hours a day (54 hours per week) just like everyone else, but he reduced working hours by 25% and instead of cutting wages he doubled them.

The productivity increases resulting from reducing hours were so significant that Henry Ford was attacked by the Wall Street Journal “To double the minimum wage, without regard to length of service, is to apply Biblical or spiritual principles where they do not belong.” going on to say “in his social endeavor he has committed blunders, if not crimes. They may return to plague him and the industry he represents, as well as organized society.”

51098603-f186b080bc53f64bbbd46208f7dec61a538631e4-s1200
Henry Ford may have paid his workers a good wage, but it wasn’t out of charity — it was a good business decision that some say helped the middle class take off.

As you can imagine his competition was not happy either, paying more for “less hours” was maddening, but what really made them mad was that productivity jumped up massively. People simply couldn’t get their heads around the idea that less hours  increased overall productivity.  Slowly the competition copied Ford and got the same results, productivity went up for less hours, and eventually this carried across to office workers too. But even with those startling results and seemingly unquestionable evidence we stubbornly cling to the notion that more work is more productive.

I have written more about Henry Ford here.

Back to the present.

Last time the proposed reduction in hours was met with hostility but eventually it was seen as beneficial to everyone, especially the business owners that fought so hard against it.  Once again studies show that reducing hours will increase overall productivity, and once again industry is pushing back on it in the face of the evidence. Challenging established culture with only facts is apparently not an easy battle.

Studies repeatedly show that long hours (40+ hour) results in reduced productivity, reduced quality and a less healthy lifestyle, and yet society still perceives the number of hours worked as a measure of hard work.
It is as if we see more value in the hours worked than the output of their labour.  Someone that works 30 hours and produces 30 widgets  is seen as less valuable than someone that works 60 hours and produces 25 widgets, because he works so much harder.

In our culture we see more value in the hours worked than we do in the output of our labour.

In our culture we see more value in the hours worked than we do in the output of our labour.

How did we get into such a mindset and how do we challenge that way of thinking.  Surely we should reward the more productive and effective person? But we don’t, we reward the inefficient, we lift up Jane for being here at 7:30  PM finishing up her work and we criticize Anne who got all her work done and left at 4.

Part of the problem, especially in knowledge work, is that productivity is not easy to measure, just like quality and mistakes are hard to quantify.  So rather than focusing on what is important we focus on what is easiest to measure – number of hours in the office, it is ironic that in our laziness in finding effective measures we end up working longer hours.

So what about overtime?

There is more bad news in the 12 year study by Ford they found that overtime (over 40 hours) results in reduced productivity in the long term.  40 hours is the very limit of maximum total productivity for a manual worker, this applies in both the short and long term.

Short term (less than 3 weeks) there are productivity gains for working beyond 40 hours, but after 3 weeks those gains disappear and actually reduce productivity afterwards. Even just 2 weeks of overtime and then stopping results in more loss in recovery than the gain made in the short term boost.

In other words, yes you can make a short-term gain using overtime to meet a deadline, but it will cost you more than you gain over the following weeks. So use it wisely and expect a recovery period.

Bad news for knowledge workers

For knowledge workers the news is worse still, the point of peak productivity is under 35 hours, and any hours above that are actually damaging, quality is markedly worse, mistakes and resulting corrections mean that productivity reduces dramatically when knowledge workers work beyond 35 hours, primarily because fatigue, stress and concentration have a profound impact on the quality rather than the quantity of work. We simply cannot be creative when tired, we struggle to solve problems come up with ideas or compose constructive discourse and debate, we are actually very likely making things worse not better and the clean up cost for knowledge work – bad decisions, introduced bugs, stifled creativity is far more damaging than not being there.

Worse news for Lawyers

Lawyers are typically in an unfortunately situation where they bill by the hour rather than by quality or even quantity of work. They are essentially encouraged by their business model to be unproductive (not consciously, it is just a product of the business model). Essentially a 60 hours week for them is the result of rewarding bad behavior, if you pay for time then they will take more time, pay for productivity and we become more productive. We also reward with status the hard working person that is willing to sacrifice his weekend for the appearance of working harder. More encouragement of bad behavior.

In ‘bill by the hour‘ work environments it is a challenge to change the model, productivity is very hard to measure – even if we see stress, mistakes and problems taking longer to solve. So it is hard to convince clients that working less is more productive, especially when it means charging more, and it becomes even harder when we can’t even convince ourselves because this notion is so culturally ingrained in us.

What now?

It is pretty simple really if you want to maximize the productivity of your teams, then reduce their maximum working hours to less than 32 hours (without reducing pay).  They will work harder and more effectively for five 6-hours days than they will for 8 or 10-hour days. Your overall productivity will be higher.

Or work 8-hours, 4-days a week and you will find your teams will be more focused, more energized and and noticeably more creative.  They will be happier, harder working and make less mistakes.  They WILL get more done and it will be higher quality and more creative. They will also be refreshed have a happier home life.

Or we can ignore the brutal facts and continue to pretend that working long hours is a good thing, and praising the guy that works 60 hours a week and yet produces less than a part-time worker.

Note: my wife finds this particularly amusing as I work long hours and when I’m not working I’m blogging and when I’m not blogging I’m working on my game or running meet ups – there is a significant degree of hypocrisy and self-denial at play here.

Summary

Let’s not underestimate the difficulty here, this is a complex topic, and it is unlikely to be accepted any time soon, there is a lot of resistance – and that resistance is not based on facts or data.  There are numerous studies on this topic, all with the same findings.  Oddly enough despite the strong resistance to this idea, I couldn’t find a single study that didn’t find that overall productivity went down when hours went above 35-40 hours.  There were even some studies that showed that regularly working 60 hours resulted in the same number of mistakes and level of performance as being drunk.

(If you see a study that contradicts this please share it, I spent quite a few hours on this but couldn’t fine one – and no, the contradiction has not escaped me.)

Decision Makers

Decision makers typically work longer hours and it is effectively their money, asking them to pay more for the perception of ‘less‘ work is never going to be an easy decision.  We come from a puritan culture where we make a cultural assessment of someone based on effort not outcome. Deep-down we know this is not objective, I think we know this is wrong, but culture is not based in logic and changing culture will take more than facts and figures. It needs someone like Henry Ford to lead the way again.

References:

https://cs.stanford.edu/people/eroberts/cs201/projects/crunchmode/econ-crunch-mode.html

https://www.igda.org/page/crunchsixlessons

For the public good…

I am continually fascinated by the notion of self-organising teams, how they motivate themselves and how you can create an environment that is conducive to self-motivation.

Unfortunately my experience is that self-management works for the minority and is highly rewarding and highly effective, but it does not work for all. Bystander Syndrome is prevalent and too often the plants do not get watered. Why don’t developers water the plants?

So, recently I ran an experiment and discussion on the general low involvement and engagement of extra-curricular activities. In particular events that are considered to be core to the effective working of the company but are not explicitly part of your core objectives.

The premise of the experiment is that we have become more focused on benefit to ourselves or benefit to our local teams, rather than the benefit to the wider organisation.

img_0447

For those out there ready to point out that an experiment requiring voluntary attendance already excludes those that are more focused on themselves – you got me!
I stacked the deck in favour of the more social minded of the organisation.

Some examples:

Our organisation is very much built around self-organisation and we are expected to manage our own time and priorities.  However, we have a number of activities that are ‘global’ in scope: some where the time spent is voluntary and expected to be worked above and around billable time.  Or facilitating other team’s retrospectives which is billable time but can conflict with your primary team priorities. Even our Guilds, which are groups of people based around a single focus or competency have an implied ongoing commitment to attend regularly.  Finally, “Lunch and Learns” or bookclubs where there is opportunity to share ideas and learn from colleagues, which is a core cultural goal of the organisation but is done as part of your personal development and on your own time.

All of these activities could be considered to be valuable to the organisation and in most cases to you personally (directly or indirectly), but all require an investment of time and effort. My observation is that in many cases the involvement is diminishing either proportionally or absolutely as we grow. Attendance at lunchtime events seems to be diminishing, involvement in volunteer groups like guilds is a challenge to the organisers and maintaining membership is probably the number one challenge.

The goal of the discussion was to identify ideas for how we maintain or stimulate these activities and how to involve a wider audience, preferably without putting a greater burden on a few (and often the same few people), and without directing people to attend, which is counter to our culture.

The Game….

We played a game loosely based on the ‘Public Good Game’ We set up two relatively large groups. All participants were given $10 each and the game is played in rounds.
Each round players can contribute as much or as little as they like to ‘a pot’ but the total contributions will be combined and then a pre-determined bonus would be added to it. One team got a 30% bonus the other team a 40% bonus.

Round 1

All players were asked to choose how much to contribute, in the 30% team the contributions were visible, in the 40% team the contributions were secret.

If you apply pure logic, the maximum gain is obtained by everyone contributing fully, that way everyone gains a lot.  But an individual can work out that by opting out and reducing their individual contribution they can benefit at the expense of others.

Subsequent rounds…

Over the course of a number of rounds as more and more people realise that others are not contributing fully, they will either call the others out for not contributing, OR they too opt out and eventually those that are still contributing receive back less than they contribute and at that point system fails as everyone eventually opts out.

End Game

What we found was that the transparent team reminded each other and kept the focus on the public benefit and maintained a better contribution level, the secret contributions team had two or three participants who were able to benefit considerably at the expense of others  by not contributing (leeching from the pot). There was sufficient reward to keep the others motivated although that was diminishing each round.  Overall it was the transparent team that benefitted more, but both teams missed out on a huge amount of potential benefit by a focus on personal gain.

Conclusion

In the recap there was a suggestion that it was unclear whether the goal of the game was for collective gain or individual gain – e.g. How did we measure the winner?

But the reality is that this is the same quandary that we face in our day to day life,  are we working for the benefit of ourselves or our team or our company?  All our choices for extra-curricular activities are an investment of our own time and effort and we are motivated either for personal gain (what is in it for me?) or collective gain (How would me attending benefit my team/company?)

Discussion

Many of the arguments we heard were around billing, and utilisation. There seems to be a reluctance to use personal time for ‘extra-curricular’ learning, which implies that there is a perceived lack of sufficient personal benefit from involvement in these activities.

In other cases such as facilitation and helping other teams people are balancing time spent with their local team against involvement in activities that benefit a wider group.  The question is… Which is more important?

The challenge for us then is how to change priorities such that activities that benefit the company as a whole are perceived as valuable (not necessarily more valuable but valuable enough to make that effort), or to highlight the benefits to us as individuals resulting from a greater involvement in company wide activities.

The conversation that followed created some great ideas, as well as highlighting some of the concerns.


The Dunbar number

Dunbar’s number is a suggested cognitive limit to the number of people with whom one can maintain stable social relationships.

Dunbar’s number on Wikipedia

Dunbar has a theory that as groups exceed a certain number approximately 150 people their sense of community diminishes and the group becomes less effective, less cohesive and it is more difficult to self-organise.

Many of the issues raised could be interpreted to have their root in the Dunbar number.  As we grow we don’t personally know the other people that are presenting at LnLs or the others that are attending the guild meetings. This lack of personal attachment results in a diminished sense of interest, ownership and responsibility, skipping is downplayed as it is only letting down people you don’t know, or an assumption that others will attend.

Ideas for increased engagement

  • Offer food
  • Educate people on calendar etiquette, e.g. show up if you accept
  • Increase advertising/promotion of events and activities
  • Write up a “What you missed” summary for those that didn’t attend
  • Leaders show support by attending,
  • Reward directly or indirectly those that present and/or attend
  • Make clear the purpose or learning goals of events
  • Introduce compulsory lunch breaks, or compulsory attendance
  • Highlight the understanding/visibility of what happens when you don’t step up
  • Identify Champions to help organise and promote these activities
  • Have fixed times/days for lunchtime activities to regulate number and ensure quality.
  • Invite only those from a sub-group (accept Dunbar’s Number and work with it).

Our goal with this experiment was to gain ideas and gain a better understanding of the problem and to share these concerns with a wider audience, we were not aiming for a solution to the problem just a start to the conversation.

Feedback?

Any more thoughts or ideas on this would be greatly appreciated

 

 

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.

 

 

 

WiP Limits and Velocity

I recently presented at a conference on the topic of Work in Progress (WiP) limits, and in particular Little’s law.  As part of I gave a demonstration and from it drew the conclusion that WiP limits have no direct bearing on velocity.

This caused some controversy so I’ll try to explain again here.

little

Applying Little’s Law

Mathematically speaking we can increase the speed with which we get served in two ways:

  1. We reduce the number of people in the queue (We limit WiP)  or
  2. We increase the speed each person is served (We increase Throughput – in this case by adding more people, or installing faster equipment)

Note:  When mathematically applying Little’s law the pre-condition is that the variables are independent, the assumption is that number of people in the queue does not impact on how quickly the server works.  This works in mathematics, but maybe not so much with people in reality.

The principle is that WiP and Throughput are two independent variables and changing one does not change the other, only cycle time is impacted.

The wider impact of WiP limits

Of course the goal of my talk was to illustrate that whilst you may feel you are getting more done by not limiting your WiP, and having a whole bunch of work in progress this has no bearing on your actual throughput which is governed by your bottle neck.

When using Little’s Law in a controlled environment we can show that limiting WiP doesn’t impact throughput (unless we limit it to less then our bottleneck and starve it – say two servers and limiting the queue to 1 person). What limiting WiP does do is reduce cycle-time enabling you to be more flexible and more responsive and to have more reliable forecasts.

Work in Progress Limits will directly impact Cycle-time

Contradictory Claims

Unfortunately this contradicted one of my other claims in the presentation where I said that Limiting WiP helps increase throughput of the team.

The confusion of course is understandable, when using a mathematical example there is no cost for context switching and the example was to show the impact of WiP on a stable system isolating variables to demonstrate what happens.  The real world is far more complex and there are many more variables.

In the real world

Generally speaking the ability to focus on less things means less multi-tasking, reduced cycle time means you have less things on the go at once, and for less time. These help you be more productive and thus indirectly the throughput will go up, but this is a result of you being able to focus not as a direct impact of the WiP limits.

There are many indirect benefits of using WiP limits,  but Cycle-time is the prime beneficiary, the rest is a bonus or an indirect consequence.

 

 

 

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

 

New Kanban Game Available

Around two years ago I was introduced to a Kanban board game which we used as part of a training program and I really enjoyed it, it was a great learning tool but it had three major drawbacks.

  1. First it was heavily scripted and so it was only suitable for a single play through, you couldn’t replay it and get more out of it.  It was not a game in that sense, it was much more of a training tool/prop.
  2. The second issue was that the exercise was taking 3 or more hours to run and whilst Kanban is a critical aspect of the training the return on investment was not sufficient.
  3. Finally it didn’t effectively address Little’s Law or the Theory of Constraints, there were aspects of that in the game but the heavy scripting meant that the learning was masked or even lost.

motorcity_Board-1

A New Kanban Game

It got me thinking and so I created a couple of workshop games that addressed this in more detail.   One of those workshop games was such good fun that I expanded it and combined it with training. For the last year or so I have been running workshops using it and continually looking to find improvements and modifications to make it more fun or to emphasize the learning aspects.

I have now presented this at a number of Lean/Agile conferences and have had a lot of great feedback, including a lot of encouragement to publish it as a board game.

Rulebook_cover

And so Herbie* – the affectionate name for the workshop game, became Motor City a Kanban based board game.  That is first and foremost fun to play and re-play, but the game is under-pinned with an understanding of Kanban, Little’s Law and the Theory of Constraints.  You can play the game without any knowledge of those and it will still be fun, but people that instinctively apply those practices or use them as a result of understanding will fare better playing the game.

*Herbie was named after the character from the book The Goal, by Eli Goldratt.

box_bottom

Game Prototype (Early Access)

The game is now in prototype, with a small number published for evaluation and for use in training and conferences, with the intent to publish the game more widely after getting feedback from the prototype.

motorcity_logo

To purchase the game…

The game is provisionally priced at $150 but for early access to the prototype it will be charged at $120
I’d love to hear of anyone that uses this as part of a training program or just as a fun game for your team to play.

If you would like a copy of the prototype board game for evaluation and feedback, please contact me.

Similarly if you are interested in training on the Theory of Constraints or Kanban and would like to use this game as part of that training, I would be happy to offer guidance on how to incorporate the training into a workshop.

Thank you

Thank you to those that have supported and encouraged me, I can assure you that board game design is far more complicated, costly and time-consuming than I ever imagined. In particular thank you to Toby Gerber who has helped with the graphic design and turning my ideas into reality, I could not have done it without him.

boxbase sm

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.