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.

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.

If you make the tools easy to use, the process easy to follow and it helps get things done, then people will follow the process, they will use the tools and so you have a defacto standard. You have a standard that actually helps promote work and productivity.

Even if the tool is slow and unresponsive, provided it helps get things done, people will accept it. I have had this happen first hand with my WebMethods tools that I developed for the company I work for. The tool takes a few minutes to do anything (yes I know I need to optimize, but I don’t have the time – and I was taken off the product so that other team members can can know e source code), but it is hailed by my team for the simple reason that it can save hours of work even in its crippled state.

On the other hand, if you have a process designed to slow things down. Has long lead times. Tools that are difficult to use and basically hinders productivity and feedback, then you will find people complaining about the tool or the process. People start to get disgruntled. You have to force the standard and overall you will end up with a compliant workforce rather than a productive workforce.

In our news, I went and took a certified scrum master course and I am now certified. With my interest in DevOps, Lean etc, and given my experience in my first Agile project recently, it seemed like someone to do. I just hope that I can use my new found knowledge sooner rather than much later.

It’s been a couple of weeks since my last post. I’ve been finishing up a project which has m ant a few days of long hours and I have also gotten myself quite sick during the process which leads to this post. 
In this project, I was the only resource for the particular technology stack used for the integration layer. This meant,by hat despite being quite sick, I still had to work. This resulted in me getting much worse. 
So, my advice is always have someone with you, even part time so that they are across the project, but also too so they can take over from you when you need time off. I.e. When you are extremely ill. 

 I’m currently at the tail end of my first agile project (specifically scrum) and it has been an interesting experience. It’s had its problems, one being that it has been incredibly fast.  A total of 4 x 2 week sprints. The scope has done nothing but grow and we have been committed to complete the whole scope. My company is generally a waterfall company, so when something like agile comes along, any problems with the project are pointed to the agile process. I think that this isn’t the case, I have seen similar situations in my career under waterfall.

I’m reminded of a video I watched of Uncle Bob (Robert C. Martin) give.

Basically you have 4 dials on any project you can play with. If any one or more of them are out of whack, they start to affect the other dials.

For example, increase the scope. Keep the budget fixed or keep the same number of resources and keep the same schedule, the quality of work is going to be compromised. If you want to keep the quality, then something else has got to give. You may need to increase the schedule. Alternatively, decrease the scope, or get more resources to do the implementation or a combination. 

I don’t thing that there is any way around this. Compromises will always need to be made. Just don’t blame the process or methodology because it’s new. 

As for those who think that it is Agiles fault, agile has been around officially for around 15+ years. Since at least the manifesto was first written in 2001. If it didn’t have some traction, it would not have survived this long. If your agile project fails, try to understand why.  You may just find that you are implementing it wrong. Similarly with Waterfall. My guess is, if a project fails, two or more of the dials have been cranked up too high causing a blow out of the other dials. 

A few years ago, my team started doing Knowledge sharing sessions. We would get together for an hour and a member of the team would share something. It didn’t have to be related to work. It could be anything. Anyway, one team member did one on psychology testing. I can’t remember he details of what the test was, but I remember a few things about the results of the team. The first was that the individual that brought up the test was leaning towards the practical side. I remember him saying that for him to consider something new, you had to show him proof that it was a benefit. The second was that most all of my team scored similarly, except for one person. Me. I scored more on the creative side. I’m more willing to try new ideas, and find creative ways to do things.

I feel that this might explain why I’m more inclined to accept and try different ways of doing things an my colleagues at the time. It may also explain why it’s hard for some people to change their ways and accept lean principles even if it stares them in the face.

I also think, that with Taylorist type management where conformance reigns, that this mindset tends to be rewarded and those that do not conform, are either told to conform, or are controlled to the point that they conform anyway or worse of all, considered trouble makers and punished.

Although I have never worked for a Lean style organization, I would like to think that the more creative types are given a chance to shine and those that are more prone to be cautious are given a chance to let out their creative side.

If anyone out there reading this works for a lean organization, are you able to confirm my thoughts? If so, please let me know in the comments below.

I was reading my son the Berenstain Bears, The Bear Scouts the other night and at one point in the book, the father bear decides to take the short way to the scout camp, where as the bear scouts decide to follow their scout guide and take the long way. The father bear very quickly runs into alligators and almost gets bitten. It got me thinking that with Agile, DevOps, basically every modern methodology that I have come across, we always try to do it the short way. We try to find the shortcut. We try to do things without fully understanding, just enough to get us into trouble. Sometimes we get somewhere, but usually in the long run taking the short way comes and bites us.

I feel that if it matters, that only by doing the hard work, can you get the full benefit. Shortcuts get you incremental benefits at best, but without understanding.

William Edwards Deming, the father of quality had a theory about the handling of defects. He wasn’t the originator of the theory, but he did put it in a fun way.

He defined the terms Common Cause and Special Cause.

Common Cause, also known as Natural Patterns, are historical, quantifiable variations to a system.

Special Cause or UnNatural Patterns are unpredictable occurrences in both frequency and severity.

So what does this mean? Common Cause, at least in Operations terms are those issues that occur regularly. For example, that error that comes up in the log all the time. The system that goes down every week. 

Special Cause on the other hand could be that power spike that caused the systems to go haywire. The computer that crashed due to hard drive failure etc.

So, how should you identify them? Is is where the Burnt Toast analogy comes in.

Say you have a job of making toast. The toast gets burnt and you scrape the burnt bits off with a knife. This keeps occurring, every slice of toast comes out burnt. So you scrape more and more.

You may decide to use a fork, at least that way you may not break the toast. Or, decide to cover up the burnt bits by slathering on butter. This is how Deming saw western manufacturing and how I see IT systems managed.

So, as a sane person, who had this job of producing toast, what would you do? Keep scraping? Build an auto scraper? I don’t know about you, but I would try to fix the toaster. This could be as simple as turning the heat setting down for a common cause. If your toast was working fine initially, and all of a sudden it started producing burnt toast, then it could be that your toaster is broken and you need a new toaster. This is a special cause. A variation that was unpredictable (e toaster breaking).

The system is consistently producing issues. Instead on focusing on fixing the end product, we should be focusing on the cause of the problem.  The toaster, yet in many it systems, we tend to focus on fixing issues in the aftermath, rather than in the root of the problem.

So how do we fix software issues are the root of the problem? This is where techniques such as Test Driven Development, Behaviour Driven Development etc come in. You fix defects before they become problems and start burning your toast.

If you decide to incorporate techniques such as Continuous Integration or Continuous Deployment before addressing the quality of the development before hand, what you are effectively doing is automatically burning your toast.

Today I’m going to quickly go through the 7 wastes of IT and my take on them,

At some point in the future, I may go through them in more detail.

• Partially done work
  Have you ever been on a project or been doing a task and then asked to drop it?
  That wasted effort for developing that piece of work is one interpretation. 
• Extra features
  Writing something that isn’t what the customer wants – or worse yet something the customer will not use.
• Re-learning
  Have you ever learned something, never documented it and then had to come back some time later and had to re-learn that thing again?
• Hand offs
  Anything that involves passing how the system works from one person to another. Not everything is given over, and usually the handoff is too short to be of any use, or months before the recipient needs the information. Where we go back to re-learning and they have to go through it all over again.
• Delays
  Delays can cause a loss of knowledge of the system. Ever completed a piece of work, had to wait days or weeks before you can migrate into production? by then you have moved onto something else?
  How difficult has it been to fix any issues that occur? Would it have been quicker if you deployed sooner?
• Task Switching
  This I have recently been through. 3 projects. All done simultaneously, all requiring 100% of my time. I spend so much time changing context from one task to the next that I don’t focus on anything and it ends up being a mess.
  Also, every time you change context, you have a ramp up time to focus. Change too often and that ramp up time eats into the productive time.
• Defects
  Anything that takes you away from planned work is bad. Defects tend to do that. They cause unplanned work in the issues they cause and also in having to fix them and the aftermath.
• Bonus Round
  • Unused Creativity
    Your people may have ways of doing things, but giving them a chance to try new things and new ways to do something may gain efficiencies and new perspectives. Giving your people a creative out, also gives them more job satisfaction.
    Not using creativity, you are prone to repeat the same mistakes and have morale problems. Also, creativity is where your innovations occur.
  • Technical Debt
    These are effectively defects, quick fixes etc that will bite you at some point in the near or distant future. It could be messy code that when you need to do a change will take weeks or months instead of hours or days if done properly in the first place.
    It can also be lack of documentation, or poor documentation etc.
  • Heroics
    This is working long hours or extra hours. Any time that is taken away from rest time causes productivity to suffer, either short term or long term. People get tired.
    I have a colleague that will work in his own time on a project for work to try to get ahead. He is not paid for this time, and most of the time he accomplishes little. He would be better off learning in that time if he needs to rather than slog it out. He actually reminds me of this Dilbert cartoon.

Sometimes waste is unavoidable, but every effort should be made to reduce it. This in essence is one of the foundations of Lean and DevOps in my opinion.

I work for an electricity utility and one of the things that the company is passionate about is safety. Its dangerous work out in the field. Dealing with electricity, there is always the chance of electrocution. So everyone, even though who work in an office learn about safety.

Once of the concepts we were introduced to was the safety pyramid. We found out that if you focus on reducing unsafe acts, you actually make a difference and reduce fatal injuries. Its a trickle up effect. Being aware of the situation from a safety perspective, you make the workplace safer overall. That’s not to say that you eliminate fatal injuries, you just reduce the chance of them happening.

This got me thinking, what if the same process was applied to software development. Would being aware and trying to fix minor bugs, those both during the development process but more importantly those already in production. Would you be making your system more stable overall, thus reducing the chance of a severe outage? If so, how would the pyramid look. So I put the following together.

I know the concepts of Test Driven Development, Acceptance Test Driven Development and the whole, shift left theory deals with this, but does putting it in this perspective help?

I’m interested in your opinion, please let me know in the comments below.