Striving To Be Happy

Have you ever sat in one of those emotional retrospectives where everyone draws a happy or sad face depending on how they felt the sprint went, or a little graph to show how you felt during the sprint?

They can and do feel like BS, especially to programmers like myself who are introverted, would prefer to sit in a dark room all day coding rather than share their feelings, but there is some merit to measuring happiness during a sprint.

Now we have to do some clarification about what happiness is work wise. Its not playing around all day, browsing facebook or shooting each other with Nerf guns, its more when are you happy being productive. You know the feeling, when you are in the zone. Time seems to pass by without you noticing and at the end of the day, when its home time (you have to be reminded its home time as you are so focused) that you have a feeling that you have accomplished something. These days are as rare as hens teeth, but damn they feel good.

So what is the magical formula that brings us those days. According to Lean Thinking, it is when the following criteria are met.

  • A clear objective – In other words, you know exactly what you need to accomplish.
  • A need for concentration so intense, that no attention is left over to think about other things.
  • A lack of interruptions and distractions (This rules out the modern workplace 🙂
  • Clear and immediate feedback on the progress towards the objective. In other words, you have the feeling you are getting somewhere.
  • A sense of challenge. Not too much of a challenge. Your skills need to be just adequate enough to complete the task. Too hard and you get frustrated. Too easy and you get bored.

Jeff Sutherland, one of the co-creators of Scrum. In his book Scrum, The Art Of Doing Twice The Work In Half The Time summarizes it to 3 points.

  • Autonomy
  • Mastery and
  • Purpose

This definition I like more. Short and Direct. So what are these?

Autonomy comes from having a certain level of control over how you do a task or more likely how you accomplish a goal. The more vague the goal, the more the person has control on how you accomplish the end result. The more detailed the task, the less choices the person has on how to accomplish. The more they feel a cog rather than a thinking person.

There was recently a scientific study that discussed the mortality rate of a person based on the level of control they had over their job.  The findings were that if you have low control, in a high demand job, you have a 15.4% increase in the chance of death compared to a low control, low demand job.

For a high control, high demand type job, there was a 34% decrease in the odds of death compared to high control, low demand job. So having more control and a little bit of stress is actually good for you.

Mastery is where we want to learn more. Get better. The struggle for perfection. It is what gives us the sense of challenge.
When we are in the zone, we are learning. We are trying to figure out that little puzzle, put all the pieces together. Once they are all together, we go ‘ahh’. We have mastered that problem, we have accomplished  something and that little snippet of knowledge is tucked away for next time. Not to mention the dopamine shot we get to activate the pleasure centers.

Finally there is purpose. This is what drives us to keep going. Without a purpose all our work feels like it is being done for nothing. That purpose needs to be perceived, for without the perception of purpose, it doesn’t matter how important the job is, it will have no meaning to the person carrying out the task.

So why is happiness important? Quite simply, a happy worker is a productive worker. A Happy worker is a more accomplished worker and a happy worker is a more healthy worker.

I’d like to say, for your next retrospective that you go through and do an emotional check. Rather than draw happy faces, discuss the above points and see what can be done to increase the likely hood of reaching them, or even if they are relevant.

Please let me know how you go in the comments.

Technology Can Bring Benefits…

I have started listening to Beyond The Goal: Theory Of Constraints by Eliyahu Goldratt.

In the first chapter, Goldratt has come up with an explanation as to why, if tried, his Theory of Constraints has failed. He doesn’t mention this, he keeps saying that everyone who has tried TOC has succeeded, but I think his argument can be applied to Agile/DevOps or any other radical system/process/framework in any industry that fails to succeed. This is my interpretation of what he says.

The first thing he asks is the following….

Technology can bring benefits, if and only if it diminishes a limitation.

Note, The statement does not say that Technology that does diminish a limitation will bring benefit. This is why I have underlined the can. Its is not a will.

Now before you agree or disagree with the statement, Eliyahu does not say what the limitation is. It could be known or unknown.  If it is not known, is the statement still true?

So what is a limitation – well, its something that prevents us or limits us from doing something. When we as humans hit a limitation, what do we do? Give up and do nothing? Not likely, we work around it. We develop policies, rules, measurements, processes etc to accommodate the limitation.

Now, lets say we introduce a technology that eliminates this limitation. Yay, its gone.  Now, what happens if we do not change the policies, rules, measurements, processes etc that were developed to accommodate the limitation? Well, not a hell of a lot. Despite the fact that the limitation has been removed, we act as if it is still there. The limitation is virtually still there.

As an example, Eliyahu brings up the MRP (Material Resource Planning) software industry.  Before MRP software was developed, it was typical for a factory of 300 workers to have about 20 staff work on their material requirements planning. Calculations were tedious and error prone, they were done manually. It would take about a month to work out the requirements. So orders for materials were done monthly. Lets say you are a customer and make an order for 100 widgets. The factory will receive your order, it would then go into the system. The calculations would be made and if you were lucky, the materials for your order would reach the factory in a month. Then you had to wait for the factory to make your widgets and then finally you would receive them. If you missed the montly cut-off, you might get the orders fullfilled in 2 months.

Then the first MRP software was developed. One of the first companies to use MRP software was Black and Decker in 1964. At the time, MRP was in response to the Toyota Production System which was barely known in the west at the time. Black and Decker did so well with MRP, they became one of the most profitable companies in the world. You have to remember too that at the time, software was done by punch cards, not terminal screens like it is today. We’re talking a very basic system compared to what is available today.

It took time, but by 1975, about 700 companies world wide were using MRP software. These companies were getting the same results as Black and Decker. Reduced inventory, more profitable results etc. At this point, the rest of the world started to notice. More and more companies wanted MRP software. So, by 1981, about 8000 companies were using MRP software. Then the murmurs of not getting the same results started to happen. Most of these companies didn’t get the magical results. By 1984, this turned into a scream. 90% of companies that used MRP software were not getting the benefits. In some cases, companies were worst off.

No one at the time knew why. The going theory at the time was that in order to get the benefits, your inventory needed to be 97% or higher in accuracy. No ones inventory is that accurate. Then you were not trained correctly on how to use the software. So, vendors started selling training. An industry of certified implementers was developed. Still, many businesses were not seeing the benefits. It became so bad, that the cost of the implementation wiped out any savings. If there were any.

Since then, we have moved on to MRP2 (Which is where I started my career in the mid to late 90’s) and now ERP systems.

So, why did the early pioneers succeed where the later adopters didn’t.

Eliyahu has a theory, which he admits, he didn’t think of at the time all this was happening.

What is the most important part of the data? Its the orders. The new recipients of MRP software forgot about this. What they did was run their MRP system overnight – once a month. So the customer orders were still fulfilled a month or 2 later.  It was if the limitation of the calculation time was still there. The procedures and processes were not changed. So no net benefit. That is not to say that there wasn’t benefit, they no longer had 20 people taking a month to do the calculations, it could now be done overnight. But this benefit does not lead to the magical profits the early adopters were getting. So why did the early adopters get the benefits? These were the more forward thinking companies. They ran their systems more frequently. Fortnightly, weekly or every few days. They were able to get their orders in sooner. Get their products made sooner and get the end result into the customers hands sooner.

Eliyahu has come up with 4 questions to ask when looking into new technology.

  • What is the power of the technology?
    This is an easy question to answer. Just speak to the Vendors. They will talk all day about the power.
  • What technology does this technology diminish for us?
    This gets harder. Trying to identify what limitation is diminished. Remember that some are seen and obvious, some, not so obvious. You need to identify precisely what is affected.
  • What rules, policies, procedures, measurements etc helped us accommodate the limitation?
    It gets harder and harder. Here you have to identify what you do to accommodate the limitation.If you do not identify the rules, procedures, processes etc you run the risk of leaving them in place. Then you will find yourself still in the same position.
    In MRP’s case above, it was processing orders monthly.
  • Finally, What rules, policies, procedures measurements etc should we be doing now?
    Now that the limitation has been removed, how far can we go before we hit the next limitation?

So, how does this affect Agile. Well, I see Agile as another technology. It may not be a new piece of software, but it is a new way of doing things. If you are not careful and identify what needs to be changed from a traditional Waterfall implementation. If you just focus on the superficial such as stand-ups and Kanban boards, and not focus on the planning, or retrospectives (At least in Scrum’s case) where you try to continuously improve, then you are still working under the limitation or Waterfall. Yes, there are some benefits. Just like the late adopters of MRP software saved some money by not having 20 people doing the calculations (It really sucked for those 20 people being laid off) but the massive benefits were not realized.


Lunchtime Meetup Tomorrow

I almost forgot, Elabor8 have another lunch time meetup tomorrow at 12.

I like these meetups because they are at a great time of day. Lunchtime. Other meetups at 6PM or later are a little hard to get to when your wife works at nights and you have a 4yo to take care of while she is working.

One Piece Flow – Part 2

I’m a little late this week, due to the Melbourne Cup holiday.

The following video I found on youtube is what inspired me for the card game from the previous post.

This video clearly shows that the smaller the batch, the quicker you process the work.

So, how does this relate to Agile, well, the sooner you can complete work – get it into production, or ready for production, the quicker you should finish your project. Think of each process as dev/test/preprod etc with the end goal ready for prod.

Don’t get fooled though, completing tasks themselves does not mean you are doing the above. For example, completing the development of a feature, completing another feature, completing another feature, then migrating to test. Testing feature 1, testing feature 2 etc. Where you have one card per task. ie, one card for developing feature one, then moving it to done once developed. In this case, you are still doing batches.

The above is for the life cycle of the feature. Not the task. If a feature is not being actively worked on, it should either be in the backlog, blocked or ready for migration to production or in production. Anything less and you are not doing agile.

For more information, look up continuous flow with regards to manufacturing, the Toyota Production System or Lean.

Another good book that explains this is “The Phoenix Project” which I’m currently re-reading (This time as an audio book).