Water Levels

One of the things that I think is missing in Agile training is that agile highlights problems and that through learning and solving those problems, you get faster and better.

The flow of work is a river. If the river flows slowly, the deeper it is. 

Traditional methodologies such as Waterfall slow things down. This hides problems. They remain hidden under the surface and are never addressed.

The same thing can be said with Agile, if you do not work towards lowering that water level. For example, focusing only on getting the work done instead of focusing on improvement and learning as well. 

So, how do you lower the water level? Well, you push the limits. You try to go faster. Try something different. Experiment.

For example, If you go a little faster, what happens? If you continue to do things the same way, only faster, you start running into problems. You make compromises, either in quality or scope. For example, code gets messy. You leave out documentation or testing. In these cases, you are not getting better. In fact you are getting worse.

So what do you have to do to keep the quality up? Well, remove waste, get better at getting better, find different ways of doing things. Find out what is valuable and work towards that. 

This of course is easier said than done, but that is why Agile is considered hard and not easy.

As you lower the water level, you start to see problems. This is a crucial time. Most companies balk at this stage and say that Agile doesn’t work. Those that are truly successful in agile fix these problems and move on.

As you get faster, better, you start to see more problems. Solve these problems and continue to get faster and better.

Keep going.

There will always be problems. Those that continue to solve the problems and get better, become highly successful. Those that don’t remain mediocre. They may be successful to a certain extent, but not as successful as those that embrace continuous learning and improvement.

Apologies for the crude diagrams. My artistic ability isn’t that great. I recently got the Apple Pencil for my iPad Pro that I’m using to write this post. 

Hot Potato

There is a Childs game called “Hot Potato” where a small object such as a bean bag is tossed around (as if it was a Hot Potato) while music plays. When the music stops, the person with the Hot Potato is out.

There is a communications method I would like to call the Hot Potato method where when you try to disseminate communication, you do a blast. Such as an email to your group, a poster on the notice board or some other passive means. Why would I like it to be called the Hot Potato method, its simply because it seems that the goal is to get rid of the communication as easily and quickly as possible.

My thoughts are that this method of communication is fine, if the information is inconsequential.

If the information is important, then I suggest other means be employed.

Why? well, if you disseminate information that is not currently relevant to all individuals at the time, then you run the possibility that it will be ignored or forgotten when the time is crucial.

For example, you have a procedure for a particular circumstance that comes around once a month. You send an email out to your team a month beforehand. If they are inundated with a number of emails per day. They are going to read it and mentally ignore it, or ignore it in the first place. Its 30 days away. They are busy, its not going to be at the top of their thoughts. Then a month later, the procedure needs to be implemented. You are going to have people who have no idea what you are talking about. You can complain, and say that you sent an email, but it was sent at a time that it was irrelevant for those people.

A quote by George Bernard Shaw comes to mind in this circumstance. “The single biggest problem in communication is the illusion that it has taken place”.

So what can you do? Well, my thinking is that its not going to be easy and there may be different methods to try.

For example, timing might be everything. A day before the procedure needs to be performed, notify then. Not a month before hand. Physically go to the people affected and let them know about the procedure. A conversation may stick more in their mind than an email. Teach those affected. Write a tutorial, doing sticks more in the mind than telling.

The whole point is that if you really, really want to communicate something to someone, you have to be pro-active, you cannot be passive. You have to get their attention. Tell them and/or teach them. Get confirmation that they have received the information. Reinforce the information.  If after all that, you still fail to get the message across to all relevant people, re-evaluate and try something different.

People retain information through different means. Some through written word, others audibly, others through pictures and diagrams. Some, by doing and some a combination of all the above. It becomes your job as the person who needs to communicate the information to make sure it is properly communicated as only you know if its importance.


The 7 Principles of Bloat Software Development

No doubt you have heard of Lean Software Development Agile and this DevOps stuff, well, it doesn’t work. Bloat Software Development is the way of the future.

In this post, I will go through the 7 key principles of Bloat Software Development and you can happily delay your projects indefinitely.

1. Incorporate Waste – This isn’t as bad as it sounds. You are not systematically trying to delay by slacking off. No, you delay by adding manual processes (If you haven’t got a process for adding a process, you need one), increase lead times, do incorrect work or add unrequired features. Also, don’t forget to document everything up front. The more pages the better. There is nothing like a 700 page requirements document that says nothing about the end product. Automation is good too. Have a task that will save you a small amount of time, automate it, but spend 18 months for its automation. 6 months sitting on it(we should automate that), 6 months development, then trying to perfect it for another 6 months before releasing it to your development team (if ever).

2. Check Quality at the End – You have to make sure that everything works right. The best time to check quality is after development. Hand off the finished product to the testers. Make sure that the testers have no idea what they are testing. (See principle 3, obscure knowledge) and hand back a bunch of defects back to the Developers. After a few rounds of this cycle, you will eventually go to User Acceptance Testing, only to find out you have built something completely different to the customers requirements. You will then either go back to the drawing board, or the customer would have spent so much money that they will need to accept the final product, with a few major changes.

3. Obscure Knowledge – The whole idea here is not to lie or mislead, the whole idea is to describe the requirements as vague as possible.

One of the keys to obscuring knowledge is cyclic logic.

For example:

The purpose of this requirements document is to fulfill the requirements of the feature. The feature will fulfill the requirements as specified in this requirements document.

A true master of knowledge obsuration can make a document flow, without actually saying anything.

4. Get Commitment Early – Oh yes, we have have that for you in 12 months. When the 11th month comes along, then you let the customer know about the delays. Sorry, we have only just finished writing the requirements, it will take another 6 months. 5 months later. Sorry, development has been delayed, you have changed the requirements based on the original requirements document, it will take another 6 months…… You get the drift.

5. Deliver Eventually – That is unless the project is canned before it is completed.

6. People are Resources – You can chop and change people at any time. They are mere cogs in the machine. Add more people when deadlines are looming. Work your people 24 hours a day. So what if they are exhausted, sick, tired. They bounce back. If they don’t – replace them.

7. Optimise the areas of least return- If you have a task that takes 10 days out of a 12 month project, and you automate it (while having a single resource for 6 months working on the automation) so the time is halved to only 7 days, it is well worth it.


As much of a joke that this post is, sometimes some of this can be seen as the norm.

What Makes People Happy

There is a great talk by Dan Ariely on TED where he talks about what motivates people to work.

The simplistic view is that motivation = money. This isn’t always the case, but it seems to be what a lot of people think. The term “You’re getting paid good money to…”

This isn’t always the case, Dan goes through several experiments with psychology students to check out the findings.

What he found is that the more meaning you have for your work, the more you will love it, and be more productive.

He also looked into other methods of motivation. How we feel if our work is not acknowledged or ignored completely. He found that ignoring work gave the worker the same amount of de-motivation as if you destroyed the work in front of them. Simply acknowledging the work, i.e. Saying “Good Job” can significantly increase a persons motivation.

At the end of the talk, Dan goes through that motivation is money, meaning, creation, challenge, ownership, identity, pride etc.

This ties in with the book “Lean Thinking, bu Womack and Jones”  Pg 65 of the first edition talks about what makes a person happy.

  • A Clear objective.
  • A need for concentration so intense that no attention is left over.
  • A lack of interruption and distractions
  • Clear and immediate feedback on progress towards an objective
  • A sense of challenge.
  • The perception that ones skills is adequate, but just adequate to cope with the task at hand.

This makes sense. Have you ever been in the “zone” while developing. Time seems to fly by, you get a lot done, but don’t know where the time went.

This is what I like about Agile. You have a plan, clear objectives that you have worked out with the product owner. Using Specifications by Example/BDD techniques, you understand what you need to accomplish. You work in a small dedicated team of professionals, any interruption is on task. you also get feedback quickly. With the short iterations of scrum, you get feedback fairly regularly and you can implement that feedback. 

Then you have the opposite, which despite best intentions, I see in traditional Command and Control organizations.

The following has been taken from a talk by John Willis and Damon Edwards from the DOES 2016 conference with my own explanations.

The recipe for burnout

  • Work Overload – Have you ever been on a death march project. Too many tasks on your plate you feel overwhemed or even just ridiculous deadlines. 
  • Lack Of Control – Having multiple bosses telling you to what to do, therefore context switching all the time. Inability to do tasks the way you want to. For example, not allowed to improve but must follow a process.
  • Insufficient Rewards – As we mentioned above from Dan’s talks, even just a simple acknowledgement can go far. But having them too few and far between can do wonders to demotivate.
  • Breakdown of Community – Basically having a non supporting work environment. You would like to try different things (but still get you work done) but no, you can’t because your boss doesn’t like it. You want to try TDD, but told “No” it doesn’t work. Sigh.
  • A sense of Fairness – Your view is consistently not taken on board, or worse still dismissed. Someone else comes up with the same thing, and then it’s implemented.
  • Value Conflcts – A mismatch between the organizations values and individuals. For example, the organization is Waterfall, but you want to try Agile.

 To put it simply, you don’t need significantly high renumeration to keep your people happy. Just give them enough challenging work and get them involved. Acknowledge what work they do do, whether used or not, so long as it’s generally relevant or with good intentions. Help them guide their own destiny. Give them the ability to explore, with full backing, but keep them on point. Give them a goal to strive towards whatever way they wish to try. There will be constraints, but removing as many constraints as possible and giving them some freedom. I like the concept from “The Toyota Way” where Toyota builds everyone up to be a leader. Not just the chosen few. 
Finally, inspire your people. Inspire your colleagues and avoid situations of burnout. It is not a badge of honor.  

Scrum for Cars!

I have just watched an interesting TEDx talk. Joe Rainier talks about wikispeed. An organisation he started where the goal was to build a car that can go 100 mpg. Be road worthy and safe.

They did it!

They used scrum and software development techniques to iterate over a 7 day period. They had their first fully working prototype done in 3 months, and an auto show version done in 6 months.

The video is only 10 minutes long and I think its well worth a watch.