Years ago when I was taking a typing class, there were certain tests that were designed to test speed not accuracy. It didn’t take me long to realize that, since there was no detriment to making mistakes, the logical action was to mash on the keys in order to get 700 words per minute for that type of test.
Some IT organizations design their issue system to focus only on the speed of closing issues and not on accuracy. Working with these organizations gives me a lot of empathy for how the typing teacher felt when I turned in a page of random letters and got the highest score.
Agile is a set of principles for creating software. It doesn’t prescribe a specific methodology. So Agile says, “it is good to reflect on how things are going,” but doesn’t say specifically how to do it. Scrum and Kanban on the other hand are methodologies or frameworks for doing the actual work.
Scrum was created out of Agile, while Kanban comes originally from systems developed by Toyota for managing assembly lines starting back in the 1940s. Scrum is based around iterations while Kanban is based around flow. An iteration in Scrum might be a week long and start with a planning phase where the stories for the iteration are selected followed by development and end with a demo and retrospective. These iterations are typically called sprints. The idea is to get a cadence of a set of features being delivered on a regular basis–typically 1 to 4 weeks. The amount of work that can be in process at one time is limited because the number of stories committed to in an iteration is limited.
Kanban’s focus on flow is more concerned about moving stories through to completion smoothly. There are no iterations and work is limited based on the work in process limit placed on the different types of work. So the development column on a Kanban board might have a work in progress limit of 4 which means the team can’t pull another story into development until something gets pulled out of the development column. This is done to make sure that stories flow through the system and don’t get backed up in front of one resource or one type of work. The people responsible for work in one particular column pull in work from the column to their left when they have capacity. This ripples up stream as columns get an empty slot and can pull from their upstream column. In effect, one story being completed sends a signal up stream than another story can be pulled off the backlog and have work started on it.
Scrum has a Story Board with cards moving across it. Kanban has a Kanban board. Both look very similar, but the way they are used is very different. In Scrum the Story Board is a visual representation of what is being worked on where. In Kanban it is a visual representation, but also a control mechanism to manage the flow of the work. It controls how fast work is released from the backlog. In Kanban, it would be common to create another column to start gathering metrics whenever the team finds some type of impediment. That wouldn’t normally happen with a Scrum Story Board.
For an analogy of the differences between Scrum iterations and Kanban’s flow, you might think of Scrum as being similar to carrying a bucket of water between two points. The water represents work and the bucket represents the iteration. In Scrum you take the bucket to the destination and then talk about how you could do it better, then go back and do it again. Maybe this time you use a slightly different sized bucket, etc. Kanban is more like a gutter running between two points. You pay close attention to any areas that start backing up the water and make sure you don’t pour more water in than is coming out the other end to make sure it doesn’t build up and spill at a curve.
The team I’m currently working with is using Kanban so we have continuous flow for the development. However, we still use iterations for things that can benefit from a cadence–most notably the demos and retrospectives. We also continue to have daily standup meetings. So basically what we’ve done is removed the iteration based work from scrum and replaced it with the continuous flow of Kanban while still keeping the other parts of Scrum.
I’ve heard some people refer to this as Scrum-ban. I’m hesitant to use that term because it sounds silly to me…but I suppose no more silly than Scrum or Kanban.
In Greek mythology, there was a goddess named Eos who fell in love with a Trojan named Tithonus. She asked Zeus to make Tithonus immortal and Zeus did.
In a different myth, the god Cupid pricks himself with one of his own arrows and falls in love with a mortal woman named Psyche. Eventually they work through all the issues with the mother-in-law-to-be and Cupid makes Psyche immortal so he can marry her.
So both Tithonus and Psyche became immortal, but there was one small but significant difference. Tithonus was made immortal by Zeus who wasn’t really bought into the outcome and was just completing a requested task. Psyche was made immortal by the god who wanted to marry her. Psyche never died and never aged. Zeus left out the never aging part with Tithonus. Tithonus became so decrepit that his wife Eos eventually turned him into a grasshopper.
There is a huge difference in what you get when someone is just completing a task and when someone is really vested in the outcome.
If you are using a Redhat 6.4 AMI EC2 instance on Amazon Webservices and after a reboot you can no longer connect to SSH, this might help you. There appears to be a bug in
/etc/rc.local that tries to add the same lines over and over again to
/etc/ssh/sshd_config. Here is what the problem looks like in
cat <<EOL >> /etc/ssh/sshd_config
Everytime the machines startup it is going to append to the file and eventually SSH will stop coming up correctly. You may want to delete those lines or at least modify them to do something that you want them to do.
Also before you reboot take a look at
/etc/ssh/sshd_config and make sure it looks right. You may need to delete some of the extra entries from the end. You can test it by doing a:
sudo service sshd restart
sshd_config is bad, this will fail to restart sshd, but it should still leave you connected so you can change the config and try restarting it again.
If your machine is running but you can’t connect to it, you can disconnect the the volume, mount it on another EC2 instance, change those files and then put it back on the original instance and start it back up.
Here are some highlights and my notes from reading the Kanban: Successful Evolutionary Change for Your Technology Business by David Anderson.
The Agile Manifesto doesn’t say anything about quality, although the Principles Behind the Manifesto do talk about craftsmanship, and there is an implied focus on quality. So if quality doesn’t appear in the Manifesto, why is it first in my recipe for success? Put simply, excessive defects are the biggest waste in software development. The numbers on this are staggering and show several orders of magnitude variation.
There seems to be a psychological advantage in asking developers to write the tests first. So-called Test Driven Development (TDD) does seem to provide the advantage that test coverage is more complete.
In trying to organize stuff, you end up with much better results by asking “Where will I look for this when I want to find it?” instead of “Where should I put this?” The same thing is true of development. When you start by asking “How do I test this?” you generally end up with much better code.
The big bang for the buck comes from using professional testers; writing tests first, automating regression testing, and code inspections.
Professional testers understand edge cases. Getting them involved before the code is written can dramatically reduce the number of defects that get committed to the code base. Leveraging their skillset early in the process is one of the best ways to increase the quality of the code.
Longer lead times seem to be associated with significantly poorer quality. In fact, an approximately six-and-a-half times increase in average lead time resulted in a greater than 30-fold increase in initial defects.
Reducing work-in-progress, or shortening the length of an iteration, will have a significant impact on initial quality.
I found this to be insightful. The longer you drag out working on a feature, the more errors you’ll get. Things that shorten the amount of time it takes to finish a unit of work will reduce the amount of errors that slip in. Continue reading “Kanban Book”