Act Now, Ask Later

We have another guest posing from Tenfold.

i was recently watching a talk I found on YouTube on “Douglas Hubbard” from “How to Measure Anything” and he was talking about having too many data points when making decisions.

He was talking about how bookies with two pieces of information would make a prediction. This would become a baseline. Given 4 or 5 data points their accuracy would go up slightly more.

But given 8 or more pieces of data, their prediction would actually get worse, but their confidence in their predictions gets better.

According to the Tenfold Article, with Agile, you “Need to be comfortable with vague or contradictory information”. In other words, incomplete information. You will actually make better decisions, faster decisions and thus lead your team to success.

I suggest reading the original article at Tenfold to see how Agile can help with sales.

https://www.tenfold.com/sales-leadership/agile-development-sales-strategy

Agile In Sales

I was recently contacted by a company that had read one of my posts and wanted me to share one of their posts. Usually I would think this is spam and move on, but I do check first.

The reason I’m telling you this, is that the post I think is interesting and I’m willing to share for that reason.

Here Patrick Hogan, one of the co-founders of Tenfold outlines how Agile can be used in sales. Sales in general, not only Software sales.
This fact alone I think deserves a mention. It shows that Scrum and Agile in general is not limited only to Software Development, but not only that. I think he is right.

Its been over 7 years since I worked for a vendor, but I worked for one for over 10 years (SeeBeyond then Sun Microsystems), and although I didn’t work directly in sales, I was on the implementation side – I did work with the sales reps. Especially when we implemented Proof Of Concepts and being a small office, we got to know one another quite well.

I remember the sales process was all about wooing the customer. Telling them and sometimes even showing them how well the software would fit in their organisation and solve their problem. Sales cycles would be in months if not years. Especially in Australia.

Now, things are different. At least I see it from a customer perspective now that I work on the other side of the fence. There is so much open source out there now, customers are more informed. The sales process is much harder.  It requires that sales people adapt and change as required and what better way to adapt than to use Agile methods and processes.

Patrick has given a high level overview on how this can be achieved for a sales team.

I suggest you read the article for yourself.

https://www.tenfold.com/sales-leadership/agile-sales-teams

 

 

Scrum vs. Kanban vs. Everything Else

This article was originally published on the DZone Agile Spotlight blog as part of the DZone Bounty competition.


Scrum and Kanban are but two out of many Agile methods currently in practice. They are both completely different in implementation but have fundamental similarities. Here we explore the differences, the similarities, and how they relate to other Agile Methods.

Scrum

Scrum, developed by both Ken Schwaber and Jeff Sutherland was introduced to the world in 1996. The inspiration of which was Jeff’s time as a fighter pilot in Vietnam, an article in the Harvard business review, and basic observations on how people actually work to get things done. Not the processes that are enforced that tend to both manage how the work is done and actually slow down progress.

Scrum got its name from a rugby scrum where teams huddle together to try to get the ball.

Given that Scrum was introduced in 1996, and in development much sooner than that, it predates the Agile Manifesto by at least 5 years. This means that Scrum helped influence the Agile Manifesto. Not the other way around. In fact, Jeff and Ken were one of the original founders.

Scrum is a cyclic framework that tries to solve problems and accomplish goals through experimentation. The Scrum “process” starts with a planning session, where the Scrum team plans the experiment. The Scrum team consists of the Scrum Master, who makes sure that the Scrum process is followed; he role is required to prevent reversion to old habits. There’s also a product owner, the person who holds the vision of what the team tries to accomplish. And, finally, the development team. Not developers in the software development sense, but developers in the product sense. In other words, the software developers, testers, architects, etc.

Then, during an iteration, i.e. a period of work, of between 1 week and 1 month – usually 2 weeks – known as a “Sprint,” the development progresses. Teams hold a daily, 15 minute meeting between to plan each day’s activities. The experiment is to try a better way of working, it is executed by, well, doing the work. At the end of the iteration, the stakeholders review the work done to make sure it meets what they require, and the team then reviews how the actual experiment did and then determine the next experiment. Whether it is a modification of the current experiment or a new experiment.

I’ve highly simplified and modified the description of Scrum here, but I wanted to show that there is a process to how Scrum works.

Kanban

Kanban was created by David Anderson and was released to the world through David’s book “Kanban: Successful Evolutionary Change for Your Technology Business” in 2010.

Kanban is a Japanese word that means signboard. The system has its roots in the Kanban cards used by Toyota to indicate when components on the assembly line of car manufacturing need to be replenished.

When an assembly line worker runs out of bolts on the line, for example, a Kanban card attached to the bin is taken and brought back to the factory store, where it triggers the replenishment to the assembly line worker. Another Kanban card which was attached to the replenishment triggers an order from the supplier, who then replenishes the factory store. The system is designed so that only when parts are used are they replenished. The system is a pull system where the use of a component triggers the pull of additional resources for replenishment.

The Kanban system works in a similar way. The Kanban cards here represent the work being done as opposed to components. The cards are then pulled from one process to another. The other component of Kanban is the visualization of the work being done. This usually takes the form of a board with the columns labeled: to-do, in process, done.

Kanban, unlike Scrum, is not process driven. Also, the starting point of Kanban is actually to start with the way you work at the moment, whereas Scrum completely changes the way you work.

So with Kanban, you visualize how you work and the different stages the work goes through, via the Kanban board. You have your Kanban cards that represent the work and then move the cards as the work progresses through each stage.

Very simple, but this is the easy bit. This is also the point where many implementations of Kanban stop.

The hard bit of Kanban is to track and monitor the progress of cards across the board. This includes the determination of bottlenecks – where cards bunch up – and determining the overall time a single card needs to progress across the board, recording both the time the card is actively worked on and the time it is idle.

Then, using various techniques and experimentation, you continuously try to improve the flow of cards.

As you can see, Scrum and Kanban, although completely different, do have some fundamental similarities. These being that, through experimentation, you continuously try to improve how you work.

The strange thing is that practices from one method start leaking into the other. You would be hard pressed to see a Scrum implementation that doesn’t have a Kanban board (either physical or virtual) to see how work flows through their team.

With Kanban implementations, you may see teams do regular reviews every couple of weeks. They may do daily stand up meetings to plan the day’s work. Some even have a single person who is in charge of the backlog of work. They may even be called the “Product Owner.”

These methods are different to Waterfall, which is very process driven. Follow the process ad infinitum to do the work. Everything is determined up front, there is no change during the process, and no review, at least not until the end of the project.

Everything Else

The similarities between agile methods are not just common to Scrum and Kanban but are actually fundamental to most Agile implementations (of which there are many). Craig Smith has a great presentation on 40 Agile Methods in 40 minutes – and this is still only a small portion of the number of Agile methods out there! Many of these methods vary on the degree of process, for example, XP has practices including Test Driven Development and Pair Programming, among others. While others such as DevOps and SAFe (Scaled Agile Framework) have a basis in other Agile methodologies, but expand on them.

Just like between Scrum and Kanban, practices in Agile methods bleed into one another. Test Driven Development, User Stories, Continuous Integration, and even pair programming from XP are pretty standard practices regardless of which Agile method has been adopted.

Lean software deals with the elimination of both wasted effort and time and is resource based. DevOps deals with automation. These are both ways of improvement adopted by agile development teams.

Those methods that do not have these fundamentals tend to have no benefits other than making the company “feel” like they are doing Agile.

Now, it doesn’t matter which methodology you choose, or if you make your own. What is important is that you have the fundamentals of Continuous Improvement through experimentation and actually reviewing the experiments. This is known as the Agile Mindset.

The Agile Mindset requires that you actively try to continuously improve and that you verify that improvement.

The various methods, be it Scrum, Kanban, or something else, are but methods to help implement the Agile Mindset. Without the Agile Mindset, no matter what method you choose, you are most likely to fail in the long term.

For more information on the Agile Mindset, I suggest searching for “Linda Rising Agile Mindset.” Linda has done a number of lectures on the Agile Mindset which is heavily based on Carol Dweck’s book “Mindset,” which looks at the difference between the “Growth” mindset and the “Fixed” mindset.

PSM 1 Study

I recently passed my PSM 1 certification and I thought I would go through my study techniques for anyone interested.

Now, these study techniques are how I learn, and not necessarily how you may learn, but my thinking is that it doesn’t hurt.

I should mention too that I completed my CSM certification a little over 18 months ago, so I’m not a complete newbie. I’ve also been reading quite a lot about Lean. TPS, Agile Methods and taken quite a number of courses online. I follow podcasts, recorded conferences and follow blogs such as DZone’s Agile Zone, The Scrum Alliance blog. I have even written several articles for both. I have had experience with Agile “Projects” both as a member of the Development Team and as Scrum Master.

I should also mention that getting your certification(s) does not make you an expert in Scrum or even Agile. It only confirms your knowledge of Scrum. But saying that, once you learn the techniques it should go a long way towards understanding. I think of the certifications as a step along my Agile journey. Not the destination.

I don’t want to debate the merits of certification here also, I will leave it as a personal choice, which I think it should be.

The Exam

The exam itself is an 80 question multiple choice exam with a time limit of 1 hour. In order to pass, you need to get 85%. The exam itself covers what is in the Scrum Guide, some scaling of scrum questions and some situational questions that are not covered in the guide, but require understanding of Scrum to answer.

The Scrum Guide

The first obvious thing I think someone should do is read the Scrum Guide. The exam itself is one the scrum guide. So read it.

Now, the next thing I decided to do was deconstruct the Scrum Guide. How did I do that, Well. I wrote out by hand (yes! By hand) each paragraph of the Scrum Guide and after the paragraph, I wrote down my understanding of what was being said. I even went another step further and started writing out from a skeptic’s point of view (as best I could) why certain practices would not work. I based these on what I have heard from other skeptics and I also tried to put my mindset in that mode. This I must admit was difficult at times as some of my skepticism didn’t really make sense.But the mere voicing it out I think was a benefit. I would then counteract if I found it was needed.

Now I only got half way through the Scrum Guide before I decided to take the test, but this did help with understanding. The “writing” actually allowed my reading to slow down rather than typing and my thoughts could gather around what is being said.

Books

Another thing I did was listen to Jeff Sutherlands book “Scrum, do twice the work in half the time”. The book goes through from Jeff’s perspective how he developed Scrum. More importantly, the reasons behind the practices. This I found important as it gives a basis as to why certain things in Scrum are done that way.

Another book I read was “Scrum And XP From The Trenches” written by Henrik Kniberg. This is a free book that goes through Henrik’s experiences in implementing Scrum and XP. this can give a practical perspective.

Practice Exams

The last thing I did was do a lot of practice exams.

I started with the Open Assessment provided by Scrum.org. This is about 30 questions to be done in 30 minutes.

The first time I did this practice test, I think I got 60 something percent. A failure, but as you lean, keep re-doing the test. Soon you get 100% each time.

The problem is that the questions get repetitive and you start knowing the answers without knowing the actual context. This should be avoided. When you get a question right or wrong, understand why.

The other practice exam I did was Mikhail Lapshin’s practice exam. This practice exam has 2 modes. The first is the Learning Mode where as you answer the questions, you get told if you were correct or not straight away. Then the reasons for the answer.

The second mode is the actual exam mode where you answer 80 questions in an hour.

A few days before I started doing the PSM exam, I would do this practice test on the train on the way to and from work.

Now, these 2 practice assessments, I would repeat to the point where I could do the Open Assessment in 5 minutes with a 100% pass mark, and Mikhail’s practice exam within 15 minutes with a pass mark of 100% also. Any question I would get wrong, I would try to understand why. Even if it was a silly mistake. Go back to the Scrum Guide and find the section where the topic is covered and re-read.

The final practice exam I did was the TestAhoy exam. This exam I left to the last week before taking the test. This I saved to check how I would go. That way the questions would be some way of a surprise. I actually did this exam the afternoon before I was going to take the test. I took the test that evening around 9PM when all was quiet.

Finally, a few days before you plan on taking the test, read and re-read the Scrum Guide.

Finally

Now, when I decided I was actually going to take the test, I had it in my mind that it would not matter if I failed. I would say to myself that it would not matter, it’s no big deal. Just try again. I was trying to calm my nerves. I think it helped a little, but I was still nervous, and then got a little careless. Once I completed the test (in a little over 30 minutes) I didn’t bother reviewing my answers. I just hit submit and let what will be will be. Thinking back, I’m not sure if this was a good or bad thing to do. If I start reviewing, would I change my answers? Would I second guess myself? Would I have got more correct answers? I will never know, but I did pass with low 90’s score. The frustrating thing is that you only get told the sections you did not do well in. You do not find out what questions you got wrong,  or their correct answers. Why would you, it is an exam. But it is still frustrating. At least for me.

So, if you decide to go and do your PSM 1 Certification, good luck and I hope this guide was helpful.

Agile Retrospectives: Lessons Learned

This post first appeared on DZone Agile Spotlight. Its original title was “What is an Agile Retrospective” and was entered as part of the DZone bounty competition.


The first time that a lot of teams do (and what my team did when they had their retrospectives after they tried to implement Scrum or any agile process) is try to answer the following questions:

  • What went well during the sprint?
  • What didn’t go well?
  • What can we do to improve?

We would go around the room. Each person answering the question if they wanted to. To mix it up, the manager would elicit responses, note the responses down, and then move on. The whole process took about 15-30 minutes at most and was completely USELESS!

What we did then was go by the letter of what a retrospective was, not by what its intent was.

So, What Really is an Agile Retrospective?

The retrospective is a time to reflect on the past work that has been done, and through self-assessment, determine how things went and how they can be improved. The above 3 questions may always be asked (not necessarily in the one sitting), but it is why they are asked that is as important as to how they are asked to get the most benefit from them. The goal of the retrospective is to have an action plan in place to try to improve productivity in the next iteration. I say “try” because the action plan is an experiment. Through the implementation of it in the next iteration do we determine whether or not the action plan is successful.

What Went Well?

Part of a retrospective is to look at what went well during a sprint. This serves 2 purposes:

  • The first is to celebrate your success. No matter how large or small, you did something good and it should be acknowledged.
  • The second is to see if this success can be replicated in other areas. Also, can it be sustained?

I recently completed a Scrum project. Now, we are a BAU (Business As Usual) team, where we mainly take care of systems rather than development, but during a recent project, it was decided to use Scrum. It was the first Scrum project for this team. For the final retrospective, one of the things I wanted the team to reflect on was, what practice could the team bring back from the Scrum project into their BAU work?

What Didn’t Go So Well?

This means “to acknowledge one’s own mistake and pledge improvement.”

One portion of the retrospective is a bit like this. When done properly, Agile uncovers problems. Problems may be small, problems may be large, but part of the retrospective is to acknowledge those problems and find ways to resolve them.

In western culture, even though it isn’t really said, mistakes are seen as a failure. They are seen as bad. So, they either get ignored, stigmatized (through blame and ridicule), or worked around. Very rarely are they directly addressed, and only then is it done so begrudgingly. Yes, all systems have problems, but it’s how you deal with those problems that is important.

One method I like to bring up to help answer the question of what didn’t go so well is to spend about 10 minutes letting the team throw out anything they didn’t like during the sprint. One example could be that planning didn’t go so well. Another could be that the sprint felt hectic. There were too many interruptions. The deployment failed. Tests failed. Anything and everything are fair game.

The next thing I like to do is have the team prioritize the top 3-5 problems and then explore what the root cause was. Based on that root cause, we brainstorm what can be done to try and determine a fix. And finally, one of the important results of the retrospective, we map out an action plan to alleviate the issue. I only focus on 3-5 problems and make sure that they are in distinctly separate segments of the development cycle simply because focusing on any more than that starts to become too much for the team to handle. You will also find that several problems have a common root cause.

For the action plan, there must be at least 1 action that needs to be done in the next sprint, but no more than 3. Any more than that, and again it is too much for the team to handle.

What Can be Improved?

The final question asked is to try to look at what you did during the sprint and see if there is a better way to do it. Improvements can be in the form of automation of tasks, or trying a different method or a different development language. It can also be as simple as explaining something a little better.

For improvements, I like to use the lean methods of eliminating waste where waste is:

  • Defect
  • Overproduction
  • Waiting
  • Non-utilized talent
  • Transportation
  • Inventory
  • Motion
  • Extra Processes

If a suggested improvement actually increases one of these wastes, it really needs to be justified.

Other Things to be Taken Into Account

An agile retrospective can take other considerations into account that help improve productivity. These can be the level of happiness of the team. A happy team is a productive team. The amount of learning the team has made during the last iteration is one example to look at the productivity level. There are many methods to do a retrospective. I’ll include some resources at the end of this article.

Rules

Within Scrum, a retrospective should take no more than 3 hours for a 1-month sprint. For shorter sprints, the time allocated should be less. For example, for 2-week sprints, I set the retrospectives to 1 hour 30 minutes maximum. Now, this is specifically for Scrum. For other agile methods, these rules may not apply.

Personally, I have two other mandatory rules:

  • No blaming people. This isn’t a witch hunt. We’re all trying to solve problems and not point fingers.
  • No excuses. I don’t care if you had to spend 2 days on a production problem and couldn’t do your work. What can we do to prevent the production problem from interfering again?

The final optional rule is:

  • No one gets a doughnut until they speak.

This brings me to the final thing that I think should be at a retrospective. Food. The simple act of having food around relaxes the team. It invites discussion. Some Scrum Masters prefer to play icebreaker games. Me, I find that just having the food around helps.

One last note: a retrospective is only useful if the actions brought up during the retrospective are actually acted upon. If they are not, and they just get noted down and filed away, then the meeting itself becomes useless. It is through the actions being implemented that the team improves, and if you do it continuously (Kaizen) your team only keeps getting better.

I’m Still Here…

Its been a while since I posted an article here, that is because I have been writing articles for other blogs.

As my previous post, you can see that “How Do You Measure Productivity?” was posted under the Scrum Alliance.

I also have a couple of posts under DZone’s Agile Zone which will be added to this site in the next few days.

In other news, I passed my PSM I exam. So now I hold both the CSM and PSM I Certifications.

How Do You Measure Productivity?

The following article first appeared on the Scrum Alliance Member Articles


How do you measure productivity? It’s a simple question, but does it have an easy answer?

If I increase my productivity by 20% or even 50%, how do I know for certain? How does your manager know? Is it a subjective, finger-in-the-air guess?

I thought I would explore the process of measuring how productive a person is. I presumed that a simple question would have a simple answer. To get at the answer, I realized that I needed to ask more questions.

What was the amount of work done?

The most obvious answer to how productive someone is, is to measure how much work that person has done. For example, John has done 50 things today (a rate of 50 items/day), whereas Jane has done only 5 (a rate of 5 items/day). Obviously, John is more productive, right?

Let’s consider another analogy: John delivered 50 parcels today. They were all on the same street, whereas Jane delivered only 5 parcels today — but they were delivered in towns 100 km apart. Now who do we think was more productive?

The amount of work done does not seem to be a good measure.

How many hours of work were spent?

The next obvious answer is the more hours you work, the more productive you are. So John works 12 hours per day, whereas Jane works 7 hours per day. John, again, is more productive, right?

Well, John spent those 12 hours writing Testing Procedure Specification reports that no one reads, browsed MySpace, and twiddled his thumbs. He also complained about losing his stapler. (Why, oh why, doesn’t Netflix carry Office Space!). By contrast, Jane worked on a method to save the company $5 million per year. Who was more productive?

The amount of time someone spends at work does not seem to be a good measure.

What was the value of work?

Perhaps we should try evaluating value. The higher the value of your work to the business, the more productive you are, right?

So John works on 5 high-value, 2 medium-value, and 1 low-value piece of work. Jane worked on 1 high-value piece of work. However, John’s 5 high-value and 2 medium-values pieces of work were not very difficult, as they took only a few hours to do. The low-value work took him weeks, whereas Jane’s one high-value piece of work was difficult and required days of effort. Who was more productive?

The amount of value of the work does not seem to be a good measure, but I think we are going in the right direction. Value does need to be taken into account.

What was the effort and difficulty?

Because the value of work must be taken into account, let’s work on the high-value items first. However, I think we need to take into account how much effort something takes.

Suppose we rate the work based on how much effort each item takes by using measures such as small, medium, and large. Assume that John worked on a large item for a week, while Jane worked on three medium items for a week. Are three mediums more work than one large? Are three mediums equal to one large? How can you tell easily? Who is more productive in this case, John or Jane?

Defining units of measure

I think we are getting close. We need a common unit of measure &mash; some simple way to convert from (S)mall/(M)edium/(L)arge to a number. Let’s say that S = 1, M = 2, and L = 3.

So, we have John who worked on 3 smalls, while Jane worked on 6 smalls. This also doesn’t sound right. Some small tasks take no time at all, whereas others can take significant effort. We need something more than just three categories. Maybe we can use extra small (XS) for those items that take little to no effort; small (S) for items that take a little bit of effort, but still not much; medium (M) for those that are a quite bit more effort; large (L) for something that takes a lot of effort, and finally extra large (XL) for something that will either pull a muscle or burst a blood vessel, based on the amount of effort.

The units of measure look something like this:
XS = 1
S = 2
M = 3
L = 4
XL = 5

Wait, something doesn’t seem right. Where is the cutoff point from “I’m exhausted from the effort” (Large) to “My head hurts” (Extra Large), or from tilts hand up/down, left/right in so-so motion (Medium) to “I’m exhausted” (Large)? The differences need to be much bigger than one unit greater.

How about this measure: The next level up is the sum of the two previous units? It looks something like this:
XS = 1
S = 2
M = 3 (same as before)
L = 5
XL = 8

Hmm, a 5 to 8 jump isn’t “Ow, my head hurts!” level of effort, but if we add an XXL, we get XXL = 13. That’s a big enough jump.

This sequence looks familiar. I remember my high school math teacher, Mr. Fibonacci, mentioning something like this. This looks very interesting. I’m going to call these work units. (Hey, who said story points? What’s that?) Now we can work out how much work has been done.

Assume that John with his Large unit of measure has completed 5 work units, whereas Jane has completed 6 work units. I think we are making progress.

Let’s standardize this to a time period. They both completed the tasks in one week. The productivity rate for John was 5 work units per week and Jane’s was 6 work units per week. (Hey, who mentioned velocity!)

Hang on, we’re not quite done yet. Individual productivity rates are all well and good, but John and Jane are a team. Measuring individual productivity rates does not promote a team mentality. If Jane is doing more than John, she should be helping John, or vice versa. I should combine these to one overall rate, so the team rate is 11 work units per week. I should only compare rates week to week, per team, and not across teams, because each team sizes work differently. I also need to make sure that the team agrees on the size of the work as a whole. There’s no point in having Jane say something is small when John thinks it’s large. They will both need to discuss and agree.

If, in a few weeks, Jane and John’s combined work increases to 17 work units per week, they have gained about a 50% increase in productivity. A measurable, comparable unit of measure for productivity. I think we’ve got it!

Conclusion

This experiment on trying to determine how a manager might work out how to measure productivity is a fun way, at least for me, of trying to understand why in Agile you would use something like story points and velocity.

Using velocity for measuring productivity is not perfect and is subjective, because it is based on an individual’s or the team’s idea of the size of work. It is also open to abuse. Jane and John could say all their work is Large and increase their productivity (throughput) significantly. Therefore, this rating should not be used for any incentives, simply because it can be abused and thus the rate becomes meaningless. However, it does indicate, for an experiment or trial, whether a productivity gain has made headway.

As you can see, this also ties into estimation, which is another reason to move away from doing estimates as time units.

One more thing: Although this story is complete fiction, I still think it deserves a happy ending.

Epilogue

With the help of their manager, John and Jane were able to visualize their productivity rates. Thus, they were able to put them into effect. They could make changes to the way they worked and get quick feedback on how those changes affected their throughput for work. Six months later, their productivity rose 1000%. They did this through experimentation, eliminating wasteful practices, and adopting a framework called Scrum.

And they lived happily ever after.

Little’s Law, Multitasking and Getting Things Done

This article first appeared on the Scrum Alliance Member Articles Section

This version is the original unedited version.

Little’s law is the theorem of queuing created by John Little, a retired professor from MIT

The theory is

l = tw

Where

l = the length of the queue

t = the rate at which items arrive or are removed from a steady state system (Throughput) and

w = the wait time in the queue

So, if you want to work out the wait time in the queue (ie, how long before your job is looked at) then we rearrange to

w=l/t

We see that the wait time is proportional to the length of the queue and inversely proportional to the processing rate.

So what does this mean. Simply put, if your processing rate is slow, then the larger the queue is, the longer waiting time before a new entry into the queue is processed. In other words your ability to change – be agile reduces.

Whereas, if your processing time is faster than your length in the queue, then you will be processing the queue quite quickly – but you run the risk of your system constantly being starved for work.

So how can I demonstrate this?

Let’s say you have a processing rate of one story every 2 days. This gives you a rate of 0.5 stories per day.

If we have a queue size of 1.

Then

w = 1/0.5

= 2 days your story will wait in the queue before it is even started on when added to the queue.

Now, lets say we push to the queue 2 stories.

w = 2/0.5

Now, for any additional stories entering the queue will take 4 days before they are looked at.

Our agility is really slowing down now.

Adding More Resources (Increasing Throughput)

Now, ok. Surely if I add more resources I can processing things quicker. My throughput has increased, so things should improve.

Ok, let’s say you now have 2 people, each with the capability of doing 0.5 stories per day. So you’re processing speed has doubled to 1 story per day.

So with a queue depth of 1.

w = 1/1

So the time waiting in the queue is now 1 day. We have increased our throughput.

Let’s try increasing our queue depth to 2.

w = 2/1

So the wait time is now 2 days again. Our agility is starting to go away again.

The more we assign to the queue, the longer it is going to take before the story is looked at.

The problem here is that you cannot always add more people. People and resources cost money. So what else can we do?

Reduce Queue Size

Let’s try something else. Let’s try reducing the queue size to zero. To keep things simple, we’ll go back to one person.

w = 0/0.5

Our wait time is now Zero????

We now have complete agility – the ability to change stories up until they are worked on.

So how do we achieve Zero queue size? Well, we’re cheating a little. There is still a queue – the backlog. What we are doing is no longer assigning stories to people. Their personal “queues” (The work in progress) has been reduced to “zero” – in other words they are working on one story/task/item at a time and “pulling” new items off the backlog when they finish. This allows the changing of the backlog without affecting the work.

Multitasking

Now, one of the problems with “assigning” tasks to people is that they have a tendency to multitask. Chop and change between what has been assigned to them and think they are making progress.

This is actually not the case. Let me explain.

Say you have 3 tasks. A, B and C. Each task takes let’s say a nice round number. 10 days to complete.

Now if we do these tasks sequentially, it’s going to take 10 days to complete each task.

But, we are supermen/women err people! We can multitask! Get everything done quicker! Is that the case?

Well, lets see. Say we split up the task so we work 5 days on each task to get something done of everything. We’re keeping it simple here.

So is it quicker to finish each task? Umm, no. We have actually doubled the time it takes to complete each task.

Now, this may not matter as the overall time for all tasks is still 30 days. The same as if we did it sequentially.

Where it comes into a problem though is that switching tasks is not free. There is a penalty. We have to dump our thought process on one task, and reload everything for the next. That takes time and energy. Especially if the time between multitasking is hours or minutes and not days.

Secondly, if there is any delay in completing a “portion” of a task – For example C took a little longer than first thought and you spent 6 days instead of 5, then you not only have delayed task C, but also completion of task A and B! And potentially the whole project! This then leads to stakeholders of A and B escalating as they need their stuff done NOW, so you stop, rearrange and the whole thing becomes a chaotic mess. Business as usual? For most people it is. So much so that for most it’s a fact of life. So much so that when developers look at how long something will take to complete, we ignore elapsed time and focus on work time, but stakeholders focus on elapsed time, so as with any mismatch, tension arises.

Caveat

Now I should probably mention that these techniques are not going to shorten the delivery time for a set amount of work in a perfect system without losses such as context switching or reorganizing regardless whether or not you have a queue size of zero or fifty or if,you switch tasks every few minutes. We are not doing any magic here. Just like the conservation of energy, the amount of work being done overall in the system is maintained. What we are doing here is rearranging things so that stuff gets done sooner and if you prioritize your items to give the most value, you get more value sooner as well. We are also dealing with a system that has reached steady state. As with anything to reach steady state, there is a ramp up time where the system is loaded and variances in work from one item to the next are minimal. Something that doesn’t come naturally in any knowledge based project.

Conclusion

I know my maths is a little off – I could probably explain it a lot better 20 years ago when I actually did maths in Uni, but Little’s Law shows a mathematical model on our ability to be Agile. It shows that “Pulling” increases your ability to respond to change as opposed to “assigning” work to someone. If you do assign, it shows that reducing the amount you load onto a person actually helps get things done sooner.

Finally, if you do overload someone by assigning tasks to them, as we are human, we tend to chop and change between those tasks for whatever reason. What this means is that for any one particular task to complete – it will actually take longer to complete any one task. Not only that, but a delay in one task could affect the delivery of other tasks that may be of a higher priority.

So keep your work in progress small (Preferably 1 thing at a time) try to keep the size of the work even and small in size to regulate the throughput to a steady state, and pull new work as required. You will get things done sooner, smoother and hopefully be one step closer to gaining control of the whole system. Better yet, you are doing this all with no additional cost!

Cross Pollination

Since I received my Lean Six Sigma Yellow belt from goleansixsigma I have been receiving a lot of emails about how to do things better. How to implement Lean and Six Sigma from doing your gardening to any project. Now, a lot of these posts include techniques taken from the Agile community such as Kanban boards, Retrospectives and such. What we are seeing here is a cross pollination of techniques across different disciplines. Its not surprising. Go Lean Six Sigma, mainly used, but not limited to the manufacturing space  as I understand it and Agile for the software industry have the same parentage in the Toyota Production System and both foster continuous improvement. It stands to reason that in improvement and practice in one discipline could be used in another.

To me, it just proves that we are all on the right track, be it Agile, Lean, DevOps, Theory Of Constraints, they are all on the same path, just in different lanes to the same destination of continuous improvement through feedback loops. Each lane a variation of solving the same or similar problems, but in different contexts.

So my thinking is that regardless of the methodology you employ, or even if you make it up yourself. Provided you are willing to question everything, have an open mind, diligently try to improve and implement a feedback loop to test those improvements and adapt to be better, you will eventually find yourself on or close to one of these methodologies, or potentially a completely different lane as your “context” may be different but still going the same way.

Retrospective Idea – Celebrate Failure

Ok, after more than 2 years of studying Lean and Agile and a little over 1 year since I got my Scrum Master certification, I am finally a Scrum Master (albeit part time) in a project.  I haven't got full control of the scrum process and I wasn't Scrum Master from the start (I was on leave when the project started) but it is a start and there have been and still are a few challenges.

Last Friday I did my second retrospective and I tried to do one of my own making this time.

After a successful showcase the day before (It was the only time we could get all the stakeholders together – so we had a 9 day sprint) I didn't want to focus on the success. Unlike most projects I've worked on, when something is successful – we tend to focus on the successes and the failures and problems get shoved under the rug. This time I wanted to make them front and center.

So, with the sprint report in hand showing a big cliff after 5 days of work, and buttering everyone up with doughnuts we went to work.

The question became "How can be make a sprint more linear in execution instead of the cliff we had?" This became the guideline for the retrospective, but what I was really after was any problems.

I had 3 rules for the Retrospective.

  1. No one can have a doughnut until they bring up a problem. This was to firstly give everyone an incentive to speak up. Doughnuts can be good incentives – except for those who are looking out for what they eat – but they still got involved.
  2. No Blaming, finger pointing. I don't want anything said to be held against anyone else.
  3. No excuses. I don't care there were BAU issues during the sprint.

The first step was to get a list of problems, issues, anything that you hated and anything that you think prevented you from completing stories in a linear fashion. We did this for the first 15 minutes.

Next we identified any duplicates and prioritized the first 5 problems.

The final step was to go through each of the 5 problems and work out the "Why?" the problem occurred. "How?" we can overcome the problem and finally any "Action" that needs to be done.

The board was broken up as follows.

In the Problem section, I inserted the first of the 5 problems.

In the Why, the team then brought up reasons for the problem with me prompting to drill down. I was trying to use the 5 why's technique to get to the root causes. I probably didn't do so well, as there was many root causes, but it is still early days experience wise for me.

In the How section, we brought up contingencies and countermeasures for the causes of the problems.

Finally in the Actions section, we bought up actions for the Scrum Master, Product Owner and Team Members either collectively or individually to do something. These were not assigned, but members decided to take responsibility for the actions.

I think the whole process went fairly well with the only problem that we went overtime by about 10 min. (From 1.5 hours time-boxed for the retro because it was a 2 week sprint).

The reason I liked this type of retrospective was that it actually focused the team on individual issues and problems that "they" found and had issue with. The sprint report gave focus  as to what was wrong rather than pie in the sky thinking.  Now we see what we can do about it in the next sprint.

As a personal note – Implementing Scrum is hard. Especially when you are doing it the first time and have no idea what you are doing, even after studying it for so long. I have this mental model in my head of what a Scrum sprint should look like and we have varied wildly from that. I'm not going to take this as a sign that Scrum doesn't work – but as a sign that I'm doing something wrong, which I know I am. I feel that my job now is to reign in the bad practices and try to introduce good practices as I understand them in gradually. For those practices that I don't quite understand, try something and see if it works while still staying to the scrum framework.

Once everything is reigned in, then start taking stats more seriously and be more aggressive in our improvements.

At least that is my thinking – which is going to be hard with a 4 sprint project. But who knows, it might help with BAU work in the future after this project.

Thoughts, Tutorials and Learnings specifically with regards to Agile, DevOps and SOA/EAI