Till Death Do Us Part :

Intro to Cumulative Flow Diagrams

Tue, 01 Jun 2010 17:28:00 -0700

In this episode a overworked team leader carries out a conversation with an Agile manager to help her present a business case to increase staff.

Team Leader: We are completely overloaded, we keep falling more and more behind and quality is suffering.

Agile Manager: How do you plan on resolving the situation?

Team Leader: Well I've been telling management that we need more staff, but they don't seem to be listening.

Agile Manager: Maybe they just have a hard time seeing the impacts of such a low staffing level.

Team Leader: You think so?

Agile Manager: Maybe. Imagine you're grocery shopping and you're prepared to check out. Since you are a busy professional you would like to expedite your checkout by stepping into the line that will give you the shortest wait time. How would you determine the best line to stand in?

Team Leader: Well, I'd probably take a moment, assess the number of people in each line, and how fast the line appears to be moving. Based on that I'd make a judgment call and pick a line.

Agile Manager: That's probably what I'd do too. It sounds to me like the act of physically observing the length of the line and how fast people are being processed is a key driver in the decision. How easy is that observation to make in our virtual world of project plans and tasks?

Team Leader: Well, that's a little tougher but, as a manager, I see the amount of work we're asked to do and it's too much.

Agile Manager: I'm sure it is. What if all of the information is there but it's a in a format that's a little hard for your management team to process? What if we had another way of organizing the information you have in your head that helps management understand the impact of the current staffing level?

Team Leader: Ok, I'm listening...

Agile Manager: Great. Let's return to the grocery store example. For the sake of discussion, let's assume that the grocery store consists of three lanes. We want to determine which lane is currently the most efficient at moving customers through. We can start this process by plotting the number of people standing in line across a given timeframe.

Arrivals by Minute

Agile Manager: So let's take a look at what type of information this simple chart tells us. The first piece of information we can look at is the Y-Axis. This tells us the number of people that have arrived at the lane over a 10 minute period. You can see that, in lane one, five people have lined up by the fourth minute and a total of 17 by the 10th minute. This is the total amount of work to be completed by the cashier, they have to check out 17 people in 10 minutes.

Team Leader: Well, that's interesting, but nothing to write home about. How does that help me?

Agile Manager: Well, it doesn't on it's own, but there's another interesting metric hidden in that simple line. It tells us how fast the line is filling up.

Team Leader: Uh, ok...

Agile Manager: You see, by examining the slope of the line, we can tell how fast people are walking up to stand in line. We call this the 'Arrival Rate'. If the line is running completely horizontal then we know that no additional people have arrived in line during that time. Lines with a steeper slope, such as the one we see between minute six and seven of lane three tells us that quite a few people are arriving at the lane.

Team Leader: Oh, I see, it's pretty clear once you explained it to me. Generally speaking you could take an average over time and get a pretty good idea about how many people use each lane.

Agile Manager: You sure could. We now know that this graph can help us visualize the number of people arriving at the checkout line, which is a key component to how you would make a decision about what line to join. We also know that knowing the arrival rate alone isn't sufficient to making a good decision about your lane choice. The missing piece of information is how fast people are being checked out. How do you think we gauge that?

Team Leader: I don't know but I'm sure you're gonna tell me!

Agile Manager: Of course I am, but only because you made me! Again we'll turn to a chart as our visualization tool. This chart, which is essentially the same as the arrivals chart, will plot the departures from our queue. As with the arrival rate, the Y-axis shows the total number of people that have completed checking out for that lane and the X-axis represents time. With this chart, we can see that about 18 people have completed checkout over a ten minute period. Once again, the slope also gives us an indication of the rate at which customers are being checked out, which we call the 'departure rate'.

Departures by Minute

Team Leader: All right, so now we have charted the two key data points I need to make my decision, but how do I use it?

Agile Manager: Good question. These individual graphs don't really help us make decisions on their own, but combined they tell us an interesting story.

Cumulative Flow Diagram

Agile Manager: These area graphs are created by overlaying the arrival rate graph with the departure rate graph. The relationship between the arrival rate (top line) and departure rate (bottom line) tells us whether or not the checker is able to keep up with demand. Consider lane one, the overall slope of the arrivals is increasing at a greater rate as the slope of the departures, meaning the checker can't keep up with demand and the line is continuing to grow. This checker probably isn't having a very good day. Look at lane three. What can we see happening there after 10 minutes?

Team Leader: Well in that case, the arrival rate is slower than the departure rate, so the checker is getting people checked out faster than people are arriving in her lane. It looks like she should get some of lane one's patrons to come join her line.

Agile Manager: Sounds like you've got it all figured out. Looking at lane two, the arrivals and departures are both pretty even, I'd say that lane two is pretty much in a state of 'flow'.

Team Leader: I'm tracking with you so far, this is a great way to track individual checker performance.

Agile Manager: I wouldn't go that far, but once aggregated it paints a pretty good picture of the store's ability to keep up with demand.

Agile Manager: There are a couple of other things to notice about this graph. First, it's ability to report on the amount of work that each lane needs to get done at any given time. Consider lane three again, by looking at the Y-axis we can see that at minute 5, we've got 8 people that have arrived at the lane. Scanning downward we can see by the bottom line that 3 have completed checkout. Doing the math then tells us that there are 5 people standing in line during minute 5 of our sample. That is what we call 'Work In Progress'.

Team Leader: That's interesting, I'm not sure why though.

Agile Manager: Well, it's interesting for a couple of reasons, but first I'd like to talk more about that X-Axis of our graph. Let's turn our eyes to lane one, around the 4 minute mark. You'll notice that we've got 5 arrivals. That means that at minute 4 of our sample, the 5th person walked up and stood in line. The real question is, when did he leave?

Team Leader: That depends, can he cut the line?

Agile Manager: No, for the sake of this discussion he stayed in his proper space in line.

Team Leader: Well, then he'd be the 5th one to get checked out.

Agile Manager: Exactly. Let's look at the departures now, at what point did we hit our fifth departure?

Team Leader: Minute 6.

Agile Manager: Yes. So looking along the X-axis will give us the amount of time an individual stood in line, in this case it's two minutes. We call this the 'cycle time'. One of the more interesting things about these graphs is that they show the relationships between work in progress and cycle times. Let me direct you to another area of interest in lane one: minute seven. Before I do, however, answer one question for me. What was the amount of work in progress at minute 4, when the 5th patron joined the line?

Team Leader: Well, based on what you've said previously, three.

Agile Manager: Correct. So at minute four, with a work in process of three, each patron takes about two minutes to get through the line right?

Team Leader: Yes

Agile Manager: So, now back to minute seven. Can you tell me what the work in progress is at this point?

Team Leader: Easy. Four.

Agile Manager: Right again. Now, following that across, what is the average cycle time at minute seven?

Team Leader: Umm, three minutes?

Agile Manager: Correct again. Notice that an increase in work in process leads to an increase in average cycle times. In other words, it just takes longer for people to get through the line.

Team Leader: Wow, that's really interesting.

Agile Manager: I think so. Now look at lane two. What do you think about it? If you had this information in front of you, what lane would you pick to stand in in order to get out of the store as quickly as possible?

Team Leader: Probably lane two, but lane three looks promising as well.

Agile Manager: Yes, I believe based on our data, either option is a good one for getting through the system quickly and out the door. And now back to the original objective, knowing what we know about how to visualize the work at individual lanes in a grocery store, how do we apply this to knowledge work and have some hard data behind your request for more staff?

Team Leader: Well, I suppose the 'patron' in our grocery example could represent a unit of work my team is supposed to process and we can track the arrival of work into and out of my department on a chart such as this on a daily or weekly basis. It will help us show in a more concrete form whether or not we have more work than we can handle.

Agile Manager: What about work in progress? Higher work in progress means longer cycle times. What if you put a price on the items in the queue? Longer cycle times would mean potentially delayed revenue opportunities for the company. Could you show that to management? Would that give them the information they need in a concise, no-nonsense way?

Team Leader: I think it could. I'm definitely going to give this a shot. Wish me luck.

Why I'm Returning the Coveted iPad

Wed, 14 Apr 2010 19:10:00 -0700

Since my last tweet I've gotten quite a few responses about why I'm returning my iPad tomorrow (unless of course someone wants to buy it from me for 1.50 on the dollar). I've got several reasons but the background should probably be first.

Background

I dig "reading". More to the point, I've got an Audible Platinum subscription and spend a lot of time listening to books during my commute and 5 hour spells working out in the yard on weekends. There's one problem with my use of audio books is that I'm constantly trying to remember the name of the book I got a concept out of. I read something, but where? This made me decide to augment my listening with an eBook reader. That way if I like a book I'm listening to, I can download it and have a searchable, annotatable, version of the book at my disposal for later reference.

Enter the iPad

Apple announced the iPad and I, like everyone else, was intrigued. I really didn't think that the iPad was a game changer or anything, but I thought it would certainly be a more versatile eBook reader than my other options and it only cost about 250 bucks more. I quickly dismissed the idea because I really didn't need that much horsepower and I was losing sight of my primary purpose for purchasing a device: to read on.

But it didn't last. By the time the iPad was released, I was examining my computer habits a little more closely. If you look, it says that around 50% of my time is spent on the web. I thought about the amount of time I spent lounging on the couch with my laptop and decided that the iPad was a good choice after all.

Pull the trigger

So I did it. Purchased the iPad, the ultimate book reading/web surfing device. Took it home and was pretty impressed. It was nice. It worked like my iPad Mini (aka iPhone). I downloaded Kindle for iPad and and iBooks. I also bought a couple of my favorite books. Then I started to actually use it...

Underwhelmed

Once I started using it on a regular basis I started to find some subtle things that I just didn't like.

Portrait Mode Keyboard. The size of the keyboard in portrait mode is a bit too big for me. I wasn't really comfortable typing on it (using my thumbs). If I tried to set it down on my lap and touch type, it's too small. I like the landscape mode keyboard quite a bit and I'm very happy with my ability to touch type on it.

I realized that I spend quite a bit of my web time doing things like responding to e-mail/twitter and jumping from site to site (yeah, I've heard of RSS, back off) looking at different things. All of these activities required the use of the keyboard which, as I stated above is much easier to use in landscape. Unfortunately, even in landscape mode I had issues.

Lapdancing. Whenever I needed to respond to an e-mail or switch to another URL, I would switch to landscape mode and set the device on my lap. Because of the back of the device being sleek, it would often slide around on my lap unless I was sitting just right. After adjusting to get into typing mode, the weight of the device got in my way. Pressing 'Shift+A' while typing a capital a would cause the whole thing to lean to the left and cause my right hand to make contact with the keyboard, giving me some interesting new words.

Mobile Safari. I don't like it one bit, not even at all. I use websites like Twitter and GMail, and when you click on a link it opens in a new window. My workflow is to open a number of tabs while going through Twitter and then go read them all after I'm done viewing the latest tweets. In Mobile Safari I get a new window on each link and have a two step process to get back to my original page.

Speaking of two step processes, have you ever tried to close a window in Mobile Safari?

Glossy Screen. The screen on the iPad is sweet, maybe just a little too sweet. When sitting outside in my yard and trying to read, there was a lot of glare. The eInk based readers don't suffer from that issue.

ByePad

So there you have it, all the stuff I don't really like about the iPad. Remember what I was looking for in the first place? An eBook reader. A plain old, boring, non-game changing, device. Bye Bye iPad, the Kindle's on its way.

Article posted on ProjectConnections

Sun, 28 Sep 2008 09:42:00 -0700

I have posted an article on ProjectConnections regarding how to prioritize your backlog. We're using it and it's working great so far. Check it out.

TDD vs. BDD? Really?

Thu, 10 Jul 2008 21:12:00 -0700

Is there a difference between TDD and BDD? I don't really think so. I have the debate occasionally and hear all about the goodness that is BDD with RSpec. RSpec is cool, ok, very English and all, but I can't help but to ask myself what's the big deal? If I were to write a test using JUnit I would write it like this:

public class AgileSoftwareDevelopmentTest extends TestCase {
	public void testShouldBeEvolutionary() {
		assertTrue(new AgileSoftwareDevelopment().isEvolutionary());
	}
}

So there it is, a test that ensures that Agile Software Development is evolutionary, TDD style. Ok, so on to the next example, one of the Ruby/RSpec variety.

describe "Agile Software Development" do
	it "should be evolutionary" do
	    AgileSoftwareDevelopment.new.should be_evolutionary
	end
end

I personally see little difference between the two... Now, with RSpec you can generate the nice readable documentation which, by the way, is totally sweet using the RSpec command spec agile_spec.rb --format specdoc

Agile Software Development
- Should be evolutionary

Using a tool called AgileDox I can get the same results, in fact, BDD was inspired by AgileDox and created by Dan North in order to eliminate some of the confusion and learning curve involved with proper TDD. Let's look at an AgileDox version of the JUnit test to see what we would need to do to the test to be able to generate the RSpec style documentation using AgileDox:

public class AgileSoftwareDevelopmentTest extends TestCase {
	public void testShouldBeEvolutionary() {
		assertTrue(new AgileSoftwareDevelopment().isEvolutionary());
	}
}

See the difference? It's subtle... It's so subtle it's invisible, no changes required. By simply removing the word test from the system, you get the same effect. I have no problems with using the term BDD, in fact I think it is very beneficial to focus people on what's important in the test. It unfortunately seems to me that whenever the two are brought up, they are promoted as competitors in the same space, not as complementary techniques. I guess I should get over it and tell people I do BDD using JUnit...

Eclipse to Visual Studio + ReSharper

Thu, 10 Apr 2008 19:52:00 -0700

Another keystroke I discovered today:

In Eclipse, I can type Ctrl+/ in order to comment out/uncomment a line of code. I've found a couple of ways to do this in Visual Studio:

Ctrl+K, C for commenting out a block and Ctl+K, U for uncommenting a block.
Ctrl+Alt+/ for toggling between commenting out and uncommenting

The latter is a ReSharper key combination which I find I prefer because I don't have to think about it, it just toggles between the two.

Eclipse to Visual Studio + ReSharper

Sat, 29 Mar 2008 19:05:00 -0700

Moving from Eclipse to Visual Studio + ReSharper is proving to be difficult. I thought I would post some of the things I figure out along the way so I won't forget them.

"Show In > Package Explorer"

When editing a file, I sometimes need to view it in the package explorer. In Eclipse, I can press Alt+Shift+W, P, which will activate package explorer and highlight the current file.

In Visual Studio you can achieve the same effect by pressing Alt+Shift+L while editing a file. This changes focus to the Solution Explorer and highlights the current file.

One shortcut down, only about 250 to go...

Standup Meetings Too Large?

Fri, 21 Mar 2008 19:21:00 -0700

We were having a problem with focusing on the stories during the standup meeting so we made a simple change. Moving the whiteboard containing the stories to the standup area. Normally this wouldn't be a problem but because the open workspace is not completely finished, we had to make some adjustments.

That was two days ago... So how did it work? Well, in a nutshell, not as good has we had hoped. As I thought about it some more, I think that part of the problem revolves around the fact that we've got a very large agile team, on the order of 20 or so people at each standup. This causes the standups to be incredibly long. We've ranged anywhere from 20-35 minutes a meeting, and that leads to people getting bored and not paying attention. Not to mention standing that long isn't the most fun thing in the world.

I'm thinking of trying something new. With a team this large, it may be better to focus on discussing the status of each of the stories instead of each individual. Doing so may do a better job of focusing the team on the current iteration's deliverables as well as bringing the meeting down to an acceptable timeframe (10-15 minutes). I see one potential problem with this scenario. By focusing on the deliverables more than the team, some of the team members may slip through the cracks, struggling through problem areas without asking for help, therefore adversely impacting team throughput.

Iteration Focus... It's the little things

Tue, 18 Mar 2008 18:09:00 -0700

After the stand-up today I got to thinking about how there didn't seem to be any focus on what was to be delivered at the end of this iteration; there was just a brain dump of each of the team members' entire day. We then did something drastic. We moved the whiteboard containing our iteration deliverables to the center of the standup, where no one could miss it. We'll see how it works tomorrow...

Out of the frying pan...

Wed, 12 Mar 2008 17:09:00 -0700

...and into the fire. I never cared much for distributed planning meetings and was looking forward to having an easier time doing planning when I started my new job... As if it isn't challenging enough, we now have distributed customers and distributed developers. I guess this means I'll earn some good experience with remote collaboration tools.

Jott + GTD

Sun, 17 Feb 2008 19:16:00 -0700

Added a new contact to my Jott contacts today. Instead of having an e-mail sent to my GMail account, it now will send the e-mail to my 43 Actions page and land it directly in my inbox there. Works for Backpack also. Yeah, I know that there are Jott Links for both of these sites, but I didn't like the way they worked. (Or don't work, as is the case for the 43 Actions site)