Scrum is like the foundation to a house. Remove some of the components and the house is compromised.

In Australia, we tend to build houses on a concrete slab. So, for example, if you don’t do something outlined in scrum, such as stopping g the daily standups, reviews, retrospectives, product owner dictates work to be done, quality is compromised etc, then it is not unlike leaving,out the rebar in the concrete slab.

You can still build the house on top of the slab. The house may even hold, but the chances of the house toppling over are increased significantly.

The same with scrum. You take away one of the few components, without knowing full well what you are doing and the consequences, you run the risk of your scrum implementation failing. You may be lucky in that it will not fail, but why lay on luck.

As a side note, it could be considered that other types of housing foundations, such as pillars that keep the house off e ground, are analogous to other agile methodologies such as Kanban.

Ignorant Thoughts

As I mentioned in a previous blog post, I have next to no experience with Agile, but I have gone through the Certified Scrum Master course (at my own expense) and I have read quite a number of books, not specifically on Agile, but on lean in manufacturing and the Toyota Production System.

Since I have next to no experience, but a willingness to learn on my own, I have an idolized view of how Agile should work. This may be a good thing as my view isn’t disillusioned from a failed Agile implementation, nor have have I had Agile forced on me so I’m not trying to fight it.

I’m currently reading “Lean Thinking” by Womack and Jones and one of the common themes in implementing Lean is that it is hard. Very hard. Everything is against the implementation. Processes are challenged and broken, ways of doing things a completely changed. Problems within the manufacturing process are brought to light. It is the same thing with Agile and I think that is what is missed when companies decide to “go agile”. There is a period of time where productivity goes down, things slow down. Especially if you do not have a guide to get you through the process. This I am guessing is because people hold on to the old ways of doing things. Habits are hard to break. Problems are uncovered that were previously hidden and management doesn’t like it.  Basically, lean and agile are easy to fail at. 

At this point, it looks like Agile is a failure. My thoughts are, that if you do not fight through this period by addressing the problems that caused the failures and just give up or change the process to make it “easier”, then in the long run,you don’t get the full benefits. 

In other words, you need to get through Hell before you can get to heaven.

Also, if you think, being experienced programmers, you should be able to do better…

As I’m writing this, I’m watching Hell’s Kitchen. Here, you have a effectively a game show where chefs compete for a job with Gordon Ramsey and lead one of his restaurants.

These are experienced chefs (mostly) who are put through a high intense period over regular intervals. Not unlike a sprint in scrum. These are experienced chefs put under a situation they are not use to, and they initially fail. And they fail regularly. Quality is not there..they make a mess of themselves. Not unlike a first few agile implementations. Those that survive the process, get better. They learn. Those that don’t learn, don’t get better and are given their marching orders. 

At the end of the process, the chefs are much better, both skills wise and personally. 

This, I think is not unlike going agile. 

Scope, Schedule, Budget/Resources and Quality Revisited

IT was only a few posts ago that I was saying that if you increase the scope, decrease the schedule or keep it fixed and then keep the resources and budget the same, quality suffers. Well, after taking my CSM course and learning a bit more, I don’t think that this can be always the case. It may be at first, but if you regularly learn from the experience, as you should be doing during retrospectives (that’s if you do retrospectives which I think are a great idea) then you should be getting better every iteration. You should be trying to improve every time, doing something different. Try to automate, try to determine what is important, improve the value stream and I think speed doesn’t become a problem.

I have the following analogy. Say you have a craftsman working on a sculpture. It can take months to finish. If you get them to hurry, say, do the sculpture in 3 days, the sculpture would get a lot more messy. But if you take the same sculpture, 3D render it, then put it through a 3D printer, then potentially you could make the same sculpture in a day. With the same or even better quality than a craftsman with months of work. Another analogy is a racing car driver. They may start with bad times around the track, but with every race, they learn more. How to handle the car better. Get a better car. Get more experience, get more practice and eventually with any luck start wining races.

In my ignorant opinion, the same can be said with Agile projects. The more practice you get, the better tools you get such as automated testing, automated deployment. Start cutting down your documentation to the bare essentials, or even change the way you do your documentation. The faster you can get. The only problem is the lead time and the willingness to keep trying to improve. Saying that, in the short term though, I still stand by my previous post.

Magic School Bus

My 4yo son loves the Magic Scool Bus tv show and books. There is once character, the teacher Miss Frizzle who has a great saying.

Take chances, get messy, make mistakes.

To me, that sums up the whole learning process.  I think corporate culture needs to learn a thing or two from Miss Frizzle and get away from the whole “mistakes are bad” mentality.  You never learn anything if you don’t try.