Scope, Schedule, Budget/Resources and Quality

 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. 

Conformist vs Creative

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.

Bear Scouts

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.

Burnt Toast

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.