(Yes, that’s me and a transformer)

Your brain is quite smart – looking at each individual neuron as a programmer, you have a lot of talent and good things to say. Unfortunately, the part of your brain that doesn’t filter what you say gets vocal from time to time and says things that are highly inappropriate. Like saying a key benefit of your event is “women”. Or digging yourself into a hole arguing on the internet instead of being responsible and taking the initiative to take things offline yourself (Hint: if someone is giving you negative advice that you think is inappropriate or you don’t like, either take it to email, or ignore it. It’s never worth it to engage publicly). Or giving talks filled with lingerie or negative connotations about people’s religious affiliations, race, sex, creed, family choices, etc.

And, to some degree, I can forgive you. The newer neurons haven’t had a chance to be through the same experiences. To know what it’s like to have the one community where you think you can feel safe among your kind actually be no different than the other vile, inappropriate communities you’ve been a part of. To have fellow geeks make jokes like, “Hey Barbara, I heard you have DSL!” and then hear your other peers laugh because they weren’t referring to Digital Subscriber Lines.

But you older neurons – you are supposed to be the leaders. And as such, it is your responsibility to be the wise old geeks. The kind to go up to those younger neurons and help them see that such talk has no place in a community such as ours. There’s no need for conference blacklists, or anything like that. Because old, wise geeks talk. And network. And communicate how well topics were accepted or not. And discover which neurons actually care about building a community versus getting a laugh using tired old content because their talk doesn’t have enough real content to actually stand on its own.

You older neurons also have to stand behind those trying to make a difference. How long do we want to be known as the community where you shut off the lights, slide pizza under the door, and keep our Steam wallets full and hope for the best?

Software Craftsmanship rejects the narrow role specialization that software engineering forced on developers and instead celebrates true craftsmen who can take a complete job from start to finish.” – Pete McBreen – Software Craftsmanship: The New Imperative

Metaphors aside, I have two daughters. One of my daughters said about a year ago, “When I grow up, I want to be myself so I can catch lizards and fix things”. I never want her to go to an event, or hear a talk, or read an article and ever think otherwise – especially from someone in my community. Software developers who aren’t white, male and nerdy from the get go have to struggle enough as it is without listening to those younger neurons try to be funny and the people in the audiences being totally OK with it.

And, as Pete says above, true craftsmen focus on the ability to take a complete job from start to finish. In addition, they focus on building the community – a community of professionals. That means it’s not enough to just “be offended” at these types of things – we have to take an active role in setting a standard that we won’t accept it as a community, and reaching out to bridge the gaps that we as a community have allowed to foster for a long time.

There’s something very wrong when I, as a dad, am more worried about my daughters being exposed to the software community at large rather than the little boys that will inevitably end up at my door step. Or when I have to worry that if I teach my nieces programming that they’ll then be ostracized by the very community I want them to be excited about. We need to come together and simply say, no more. We won’t stand for that, we won’t tolerate it, and we’re going to actively work to bring diversity into our community and help people see more role models than the white, nerdy and male ones we have right now.

“Software Craftsmanship rejects the narrow role specialization that software engineering forced on developers and instead celebrates true craftsmen who can take a complete job from start to finish.” – Pete McBreen – Software Craftsmanship: The New Imperative

For the past several years, my focus has been on helping organizations adopt lean and agile practices to improve how they deliver software. I tended to play one of two roles – either convincing managers and executives why it was critical to look at the whole picture, or convincing development teams that paying attention to the business and being involved was a Really Good Idea.

Around October of 2010, I made the decision to take a sabbatical from conferences, mailing lists, twitter, etc. Basically just spend a year reflecting on where I was and the impact I wanted to have. During that time I got to see things like Code Retreats and the impact that had on communities. I got to watch communities like Chicago grow and prosper because of the collaboration by the people who were part of it. And I got to participate as a minor role as a mentor with the groups participating in Gazelle Lab.

And it made me realize that – more than wanting to move to a place like Chicago or Silicon Valley – that I wanted to make that kind of community happen where I live in the Tampa area. We have great people, great companies, and great opportunities to continue with the momentum here. But, with a hectic travel schedule (I’m Platinum for the year on Delta – 75k miles – and it’s only the end of February) I knew that I’d have to find something different. But beyond just something different – an opportunity to be with a company or start something which valued the community, which valued building the skills and experiences of developers.

About three weeks ago, I talked with some people who had done something similar in Chicago – Micah Martin and Paul Pagel with 8th Light. And the more we chatted, the more it became clear that together we could make something amazing happen.

So I’m excited to announce that on March 5th, I’m going to be joining 8th Light to help expand an amazing company to a new market – Tampa, FL! We’ll be bringing a lot of the same principles to the Tampa office that are shared in Chicago – apprenticeship programs, 8th Light University and a company focused on building beautifully crafted software products that deliver the highest value to our customers.

We’ll be hosting several exciting events over the next couple of months, including bringing Uncle Bob Martin down to Tampa for presentations. More importantly, we’re going to be on the lookout for people interesting in becoming a part of an organization truly committed to a continuous learning process, and the growth of its people.

This also means I’ll be leaving Net Objectives which has taught me a lot about furthering my thinking around architecture and design, as well as scaling and adopting lean principles at scale. I’m thankful to Alan Shalloway, Alan Chedalawada, Amir Kolsky, Mike Cox, Scott Bain and Ken Pugh for their insights, discussions and partnership.

But I’m excited about the opportunities we’ll have here in the Tampa area to rejoin the communities and help build some amazing partnerships, products and events. My email address of foyc at cory foy dot com is still around, or you can email me at cory at 8thlight dot com, so if you have any ideas, or would like any information, be sure to let me know!

With MVH, the first step after figuring out the problem to solve isn’t to create a minimum viable product. Instead, the first step is to brainstorm market hypotheses. Which groups have the desire and funds for a solution?

What Jim is blogging about is another side of the minimal coin, and since we teach this in our classes, I thought it would be worth posting about how both sides look.

First, let’s imagine you have The Next Great Idea. Your mind buzzes with all of the uses, and ways it could help people and make money. You literally have a laundry list of the features, and markets. But now you are in one of two positions:

1. You are approaching a market where you have to sell a solution to someone’s problem. Of course, as the great Jerry Weinberg says, selling a solution implies that someone has a problem, and people don’t have problems (at least none they’ll admit to you if they didn’t hire you to solve it). Here you are proposing different or better ways of doing things, and quality and feature sets matter.
2. You are approaching a market with an actual need or void. Here, time to market matters because if you miss the market opportunity, someone else will fill it.

These may sound similar, but there is a key distinction in how we approach the Pareto solution – known as the 80/20 rule (20% of the system provides ~80% of the value). One chart we use shows the results of a Standish Group survey of 2000 projects at 1000 companies detailing the usage of features and functions in a typical system:

A key takeaway we teach our students is that, if you want to go faster, stop doing the 45% of features that are never used. And even if the Standish group numbers are debated – the reaction of my students thinking about their own systems easily validates that we waste a lot of time in the Never Used category.

But, the chart details something else. If we actually know the Always and Sometimes features up front, why would we wait to ship the product to complete the other features?

This, to me, is the key distinction of the Minimal Viable Product. We know the highest value items, so we work to build and ship those first. We then are guided by the feedback (and profits) of the release to incrementally improve the product. And, in my experience, you can only know those items if you are filling an actual need or void.

When we do release, it looks something like the chart to the left. We push out a release which gets a ton of value and revenue first, and then use the feedback so that each subsequent release adds incremental value to the product and the customers.

If, instead, you are attempting to fill a perceived need or void, or you think you can do better, then you don’t want to focus on what you think the 80/20 is, because you could easily be wrong – wasting a lot of time and money in the process (as Jim detailed in his post). Instead, what you are looking for is a release which gives you enough information to discover where the market is and what those 80/20 features are. I like Jim’s term of the “Minimal Viable Hypothesis” here, because that is what it is. You are making a guess – a hypothesis – of where the market is, and now you need to run some experiments to see if that’s actually viable – before you build an entire set of theories around it.

So, in a Minimal Viable Hypothesis release, we’d see an initial release with minor adoption and profits, because we are using it as a feedback loop. In fact, I joke with my students and tell them that, in this case, you should purposely deliver what the customer doesn’t want so that a) You are reminded that you are going to have to rebuild it anyway b) You get the feedback loop faster, since you know it’s what they don’t want and c) When you get people fired up, you learn a lot – and people mad at software are pretty fired up!

So, thanks Jim for a great label for the other type of release. I think that most people will find themselves solidly in the MVH camp – and that many startups would be very wise to heed the advice to get something to your customers to use as a feedback loop for making what they really want.

I just finished up an article for the Norwegian Developers Conference Magazine around iterative design. In talking through the article points with the ever wonderful Corey Haines and Pat Maddox, Corey brought up the notion that he tends to shy away from design patterns discussions with beginners because it tends to lead to large, bloated designs.

It’s unfortunate that the application of design patterns far too often does lead to large, bloated, unmaintainable designs. It’s a very common misconception that the patterns are “recipes” we apply to a solution to build it into something recognizable. But, in fact, patterns are actually inherent in the problem itself, and present options for understanding different approaches towards the design of a solution. It’s when we blindly apply that pattern or sets of a pattern as the solution that we get in trouble.

I have some larger examples in the article, but I thought it would be fun to apply the thinking to Conway’s Game of Life – a canonical example in many of the Code Retreats and other design and emergent code exercises. It’s a simple game with simple rules that produces some amazingly complex behavior.

To follow along, there are two key elements to understand. The first is the guidelines the authors of the “Gang of Four” (GoF) Design Patterns book laid out for the application of patterns. These are:

1. Design to Interfaces – This is commonly construed as meaning we should design all interactions to be through interface types. Instead the guidance is saying that we should design based on the interfaces and interactions between the objects – something we call Programming by Intention
2. Favor Object Delegation over Inheritance – Solving specialization through inheritance works OK – until we hit a second specialization case. So we should favor delegating work to other classes over creating specialized subclasses whenever possible
3. Encapsulate the Concept that Varies – When things vary – whether they are implementations, designs, relationships or anything else – we need to find ways make it appear to the calling classes that the varying issue isnʼt actually varying

These are critical guidelines to follow, and complement Kent Beck’s 4 Rules of Simple Design and Robert Martin’s SOLID Principles (See Derick Bailey’s post for a great explanation of SOLID – with pictures!).

The second is the rules of the Game of Life. The board is laid out with cells, and each cell has up to 8 neighbors. At each tick in time, the following transitions happen simultaneously (from the Wikipedia article):

1. Any live cell with fewer than two live neighbors dies, as if caused by under-population
2. Any live cell with two or three live neighbors lives on to the next generation
3. Any live cell with more than three live neighbors dies, as if by overcrowding
4. Any dead cell with exactly three live neighbors becomes a live cell, as if by reproduction

Normally we can start implementing this exercise using a test-first method. But what happens if we step back and look at the problem and see what patterns are inherent in it? We know that we have a cell, and that it has two variations – Alive or Dead. Each variation has different behavior. However – and this is key – the two variations don’t produce different versions of the cell. This matters, because we could implement a cell using subclassing for the states:

          |Cell|
|AliveCell|    |DeadCell|

But it would make our system more difficult because we’d have to swap cell instances every time the state changes. But it is a variation, and looking at the third GoF guideline above, we should encapsulate that variation, which does happen above. But, we violate the second guideline, which is to favor delegation over inheritance.

So, if we keep looking at this, a Cell doesn’t actually care what state it’s in – all it cares about is that it has a state. A Cell also doesn’t care about what happens because of that state – it only cares that it needs to see if its state should be updated. So, we could think about the problem with this design:

|Cell| <------- |Status|
           |Alive|    |Dead|

And now the job of the cell becomes to respond to a time tick and find out if it needs a new status. With that thinking, we can apply a Strategy based on the state to determine the next state to move into, or run the Cell through a Chain of Responsibility to determine the next state (each step would return the correct Status object, with the default to return the existing one).

Is this overkill? Having a Cell with a separate Status object which gets selected based on a Strategy or Chain of Responsibility? No! Because at this point, we aren't talking about solutions but about the patterns inherent in the problem. Certainly if we implemented a Cell with a Status object with an AliveStatus class and a DeadStatus class someone, somewhere, should slap us upside the head. But if we just use patterns thinking as an initial vector for our approach, we can think through some of the different scenarios, and then begin implementing the code test-first following the 4 Rules of Simple Design and probably end up with a Cell class that has a Boolean is_alive field.

So, when you are tackling a problem, step back and look at what the problem is trying to tell you. More than likely there is some type of variation which needs to be encapsulate, and several patterns inherent in that problem. Just don't blindly continue on with implementing the patterns based on a book. Patterns aren't the code you write. They are the ideas in the problem you are solving - and you should implement those ideas in the simplest way you can.

To give you a sense – our oldest BoA account was over 20 years old. We had 7 Checking and Savings accounts, plus our mortgage, credit card, business credit card, auto loans, etc. Here were the steps we took:

1. Prepare, prepare, prepare – We gathered up a list of everything that would need to change. Almost all of our bills are done through Bill Pay – not automatic withdrawal – so we knew we’d only have one place to go there. We have automatic transfers set up between our accounts, and documented those. We also made sure we had enough lead time to make the switch during a pay cycle, so that my paycheck would go in and we could pay everything from the USAA accounts
2. Open the new accounts – I called USAA and with one phone call was able to set up the initial checking and savings accounts, a joint personal credit card for my wife and I, and a separate credit card for my expenses while on the road. We also transferred our auto insurance from State Farm to USAA, which we did on the same call. All told it took about 20 minutes to get it all set up, and I was very happy with the experience
3. Switch Direct Deposit – USAA has a great “Switch Kit” which gives you everything you need to switch direct deposits and any other automatic withdrawals. So I sent everything to our HR administrator who made sure the direct deposit would be changed.
4. Setup Bill Pay – Probably the hardest part, since there isn’t really an automated way to move over all the payees. We focused on the ones that we pay out of the first paycheck cycle, and then moved over the rest once the first cycle had run.
5. Transferring Funds – What we did here was consolidate all of our BoA accounts into our main savings account, and then did a wire transfer to USAA. We had to pay $15 I believe for the transfer, but it was safe and secure – and fast. We did leave some money in our BoA accounts for the next section.
6. Monitoring the old accounts – We kept a little bit of money in our old accounts and monitored them closely for any automatic debits. There’s always something you forget – iTunes, automatic tolls, etc. As we saw them, we transferred them over. We did the same thing for our bills and watched for any automatic debits (life insurance, etc) and moved those over as well.
7. Closing out the accounts – Once everything had been up and running for about six weeks, we started closing down our old accounts. We started with the BB&T card I was using for my travel expenses, and my BoA Business Card. We had already closed out the savings accounts we had setup for the kids once they were moved over. We ended up leaving our auto loan and our mortgage with BoA, so we’ll still have accounts with them for a little while yet, but all of our banking is now through USAA!

For the pain I thought it was going to be, it was actually a fairly straightforward process. And seeing all the news stories of late around bank fee hikes ($20 a month for checking? Really?) I’m very glad we made the switch.

To briefly summarize the differences, Scrum is a methodology which consists at its core a "three of threes" – three roles (ScrumMaster, Product Owner, and Team), three meetings (Daily Standup, Iteration Planning, Sprint Demonstration), and three artifacts (Product Backlog, Sprint Backlog, and a Burndown Chart). In short, the Product Owner has a prioritized backlog (Product Backlog) of work that she wants done for the product, or for the next release. The team meets with the Product Owner (Iteration Planning) to commit to a subset of that work they’ll spend the next fixed-length period of time (Sprint) working on. The stories committed to become the Sprint Backlog. In addition, the stories are estimated using Story Points, and the team can not commit to completing more stories than what their Velocity is (the number of Story Points they can complete, on average, during a Sprint).

Kanban, on the other hand, is a continuous flow model. It also starts with a prioritized backlog, but does not define who the owner of that backlog is (though we highly recommend it being a Product Champion, who has the authority to make change in items and priority). The team pulls work from the backlog as they have capacity, working on the story until it is finished. They then pull the next most important story from the backlog, and repeat.

The team in Kanban limits the amount of work they pull in based on Work in Process limits. These are explicit limits, set by the team, of how much work they can have flowing through the system at one time. Forecasting of how much more time is left is done using Average Cycle Time (though there are other ways, as I wrote about recently). Outside of that, Kanban doesn’t set how often the owner of the backlog needs to prioritize the work (as long as there is work ready to be pulled when the team needs it) nor does it define when work will be demonstrated for the customer. This doesn’t mean that it isn’t important – in fact, it is critical. However, the way it is done is, again, through Explicit Policies – the team makes a decision of how often they want to meet with the backlog owner, and how often they want to demonstrate the work completed. They then publicize that decision as a policy.

It’s through the use of these policies that we can recreate Scrum using only Kanban. The key is defining the right set of explicit policies to make it all work.

Time

Let’s start first with the time aspect. We’ll assume we’re using two weeks as our sprint length throughout the rest of this article. If our sprint length is indeed two weeks, we are saying, from a Scrum perspective, the following:

• We have an input cadence of two weeks. This means that every two weeks the Product Owner will have a chance to reprioritize what the team is working on.
• We have an output cadence of two weeks. This means that every two weeks, the Product Owner will have a chance to see the work that has been completed
• Assuming we are doing retrospectives, we have a retrospective cadence of two weeks, which is how often we’ll meet to reflect on our work and our process.

Each of these items are, in fact, implicit policies we take on by using Scrum and by setting our Sprint length. So, recreating these in Kanban is fairly straightforward:

• We set an explicit policy that every two weeks we’ll meet with the backlog owner to update the backlog and make sure we have enough work loaded for the team. This sets our input cadence. Note that the normal policy in Kanban is that if work hasn’t been started, it can be reprioritized at any time, so what we’re really setting here is a meeting cadence.
• We then set an explicit policy that every two weeks we’ll meet and demonstrate whatever is in the done column. This is our output cadence.
• Finally, we set an explicit policy that we will meet every two weeks to reflect on our work in process, setting our retrospective cadence.

Well, that was easy! What’s next?

Velocity

One of the key ways we limit work in progress in Scrum is through the use of velocity. Knowing the average number of story points a team can complete in a two week period accomplishes two things:

1. We are able to forecast out how much longer we have before we are finished with what is in the product backlog
2. We are able to limit how much work we pull in based on what is presumed to be our capacity for work

To recreate this in Kanban, we’ll need to do the following:

• First, the stories will need to be estimated using Story Points. Pretty straightforward, since that is what Scrum does
• We set an explicit policy that every two weeks we will sum the story points in the done column, and call that our velocity

So, now we have our velocity, but it isn’t quite satisfying. After all, part of what we use velocity for in Scrum is to limit the amount of work we have in progress. So what should we do with the number here?

If we go back to the concept of WIP Limits in Kanban, they are usually applied at the column level. Also, WIP limits are traditionally defined as limiting the number of stories that can be in play at one time – not the size of stories that can be in play. However, there’s nothing saying we have to stick with that – after all, these are our policies!

So, we set a WIP limit on the Backlog column of our Kanban board that is equal to the velocity calculation we just used. The WIP limit here would actually be based on Story points, not story counting, so sometimes we might have 3 stories, and sometimes we might have 9 in the column, depending on their size.

At this point, we now have a Kanban board with an input cadence of two weeks, an output cadence of two weeks, a limit on the backlog column based on how many story points were in the done column after two weeks, and a retrospective cadence of two weeks. Pretty close!

At this point in the class, one of my students pointed out that, while we are close to Scrum, we’re missing the ability that the product owner know that the stories started at the beginning of the two week period are going to be the ones demonstrated at the end. This leads to our third section.

Commitment

In Scrum the team is committing to the work in the Sprint Backlog. To make sure that goes well, we generally recommend teams don’t pull in stories above a certain size. For example, teams using a Fibonacci sequence may not commit to stories which are larger than 5 Story Points, because of the uncertainty involved. This is challenging, because we don’t really have a way of setting explicit policies around commitment models, but perhaps we can do something to improve the odds that a story entering the backlog will be demonstrated in two weeks.

To do that, we can do one of two things (or both):

1. We set an explicit policy that stories entering the board have a Service Level Agreement of being completed in two weeks or less. This may impact the way work is pulled across the board.
2. We set an explicit policy of entrance criteria which prohibits stories that have an average cycle time greater than some threshold – say 5-8 days. This can be done by sizing the stories using something like T-Shirt sizes (XS, S, M, L, XL) then calculating the average cycle time for each size. You can see my post on estimating in Kanban for more information.

With those in place, we can’t guarantee the work will be demonstrated, but we can come close into a high confidence level that the work will be ready by the next demonstration.

Summary

Now, of course, this is all a bit silly. But, it does raise a very critical point. Explicit Policies in Kanban are the magic sauce to a successful implementation. It’s also important to note that the policies need to be owned by the team. That way, even if they did set all of the above policies, they had the ability to change the ones that weren’t working for them.

Both Kanban and Scrum are rather interesting methodologies that can be applied to various teams. But no matter which you choose, the team should own the methodology and the implementation so that they can make it work for them. Every team and every implementation is different. The key is that when your team differs, make it explicit what it is your team does and why – and reflect regularly on it.

Let’s start with the simple approach. Take a look at this picture of a traffic jam. How many of us would be excited seeing this, because the red circle indicates a spot just right for our car to fit in? Would we actually go, “Goodie! A spot for me!"? Probably not. Seeing a traffic jam like that would encourage us to sleep in a little longer, or perhaps work from home. Yet, for some reason, we don’t tend to think about our time in the same way. “Oh, Bob is only 80% on Project Zeta, so he can spare some time to help us out on Project Farrrgh Phase 2Ai.”

This thinking is what happens when we focus on utilization as a metric of efficiency, instead of throughput. On a road, throughput would be measured by the amount of cars that can flow through it. It may seem more efficient to jam pack the cars together, but if you actually measured it, you would likely find that by flowing less cars at a time, they can go faster, and more can get through.

On software teams, this measure of throughput is often considered the teams velocity, or capacity. And when we fill it completely up, we leave no room for slack in the process. In the great book Slack: Getting Past Burnout, Busywork, and the Myth of Total Efficiency, Tom DeMarco states, “Extreme busyness is injurious to the real work of the organization.” He goes on further to state that we can only achieve 100% utilization by allowing buffers to build up at each stage in the cycle, which actually increases the amount of time for work to flow. In other words, to keep people maximally busy, value-added work has to be sitting there – waiting for them – when they finish whatever they are currently working on. Work that is just sitting is delayed. Delays lead to inventory as work just sits, not being used. Inventory and delays, in Lean Thinking, are considered waste. Why would we introduce waste into a process we are trying to improve?

But, let’s look at this from another angle, through the lens of “Shared Resources”. Let’s go back to poor Bob from earlier. Only now, it’s worse. Two new projects have come on the horizon that need his expertise, and they were more important than Project Zeta. So, now Bob’s utilization schedule looks like:

• Project Zeta: 15%
• Project Farrrgh Phase 2Ai: 20%
• Project TTime: 25%
• Project ICWUD: 40%

If we actually map this to Bob’s time for the week, it would look like:

• Project Zeta: 6 hours
• Project Farrrgh Phase 2Ai: 8 hours
• Project TTime: 10 hours
• Project ICWUD: 16 hours

But this doesn’t tell the whole story. In our own workings with organizations doing value-stream mappings, we find that most people are lucky to get 6 hours of value-add work in an 8-hour day. Meetings, coffee, phone calls, bathroom breaks, etc. all work together to eat our time up. So poor Bob is actually further behind with a map of time like this:

• Project Zeta: 4.5 hours
• Project Farrrgh Phase 2Ai: 6 hours
• Project TTime: 7.5 hours
• Project ICWUD: 12 hours

This might work if Bob could do this sequentially. So, on Monday, he would work on Project Zeta for 4.5 hours, then spend 1.5 hours on Project Farrrgh. On Tuesday, he would spend 4.5 hours on Project Farrrgh, and 1.5 on Project TTime. On Wednesday he would spend 6 hours on Project TTime, leaving Thursday and Friday for Project ICWUD. But, if we look at Bob’s calendar for just Monday, it actually looks like this:

Anyone who has had a meeting schedule like this can attest that during the in between times – as you are getting ready to leave, and right after you’ve arrived – you are in a transition state. We call this “context switching” – and it costs you. Gerry Weinberg posits that this cost could be as high as 40%. But, let’s imagine that it is 15 minutes on either end to context switch into and out of the projects. So, the schedule really looks like:

• 8-8:15 Context Switch
• 8:15-8:45 Zeta Call
• 8:45-9:00 Context Switch
• 9:00-9:15 Context Switch
• 9:15-10:45 TTime Update
• 10:45-11:00 Context Switch
• 11:00-11:15 Context Switch
• 11:15-11:45 ICWUD Code Review
• 11:45-12:00 Context Switch
• 1:00-1:15 Context Switch
• 1:15-2:45 ICWUD Analysis Session
• 2:45-3:00 Context Switch
• 3:30-3:45 Context Switch
• 3:45-5:00 Farrrgh Code Review

So, in his day, Bob spent over 2 hours context switching. This can be much worse when you deal with conference calls, videoconferences, powerpoints, rooms that aren’t set up, etc.

Now, let’s equate that to dollars. Assume that Bob’s schedule is similar throughout the week, causing 10 hours of context switching a week. And across all 4 projects, we have a similar ratio, meaning that everyone is assigned to multiple projects. So if we had 30 team members total, each losing 10 hours a week to context switching, then it gets expensive very quickly.

How expensive? Let’s assume an average salary of $60,000. We then add 25% for operating costs – benefits, taxes, etc., giving us a total of $75,000. Dividing that by the approximate number of working hours in a year – 2000 – gives us a cost of $37.50 per hour. 30 team members * 10 hours context switching * $37.50 per hour = $11,250 per week we lose to context switching, or close to $600,000 per year.

Unfortunately, for a vast majority of companies, the hidden costs of delays, waste, inventory and other problems stay hidden behind a veil of utilization measurements, individual reward structures, and a culture that lacks a continuous improvement mindset.

So next time you feel yourself being drug into a traffic jam, take a look at how long it really takes you to get settled, and think about how much value add work you are really getting in. You might just find that the cost of “Shared Resources” is what is creating the vicious cycle that makes you think it is your saving grace.

Before even getting into the book, it is good to know the style of Robert Martin, affectionately known as “Uncle Bob” to many people. Bob is a former preacher who comes at life – and topics he teaches – with a no-holds-bar approach. So when he approaches topics such as “Professionalism” and the software industry, I come expecting passionate discussion and serious assertions. The Clean Coder is no exception.

The book starts off with an overview of the Challenger space shuttle disaster. As a native Floridian who could see shuttle launches from my house (and, in fact, saw the Challenger explode just as it crested the trees from where we lived) this really resonated with me. The accident was a result of engineers saying no, but management overriding the decision. With this introduction, Bob makes it quite clear that when we choose not to stand up for that which we believe, it can have dire consequences.

We then dive right in, starting with the topic of Professionalism. The assertion is made that the key to professionalism is responsibility – “You can’t take pride and honor is something you can’t be held accountable for”. But how do we take and achieve responsibility? Chapter one lays out two ways. To start, it looks at the Hippocratic Oath, specifically the rule of “First, Do No Harm”. The book maps this to software by saying to do no harm to function or structure, ensure that QA doesn’t find anything, know that your software works, and have automated QA. In fact, when I work with teams, I teach them that if your testing “phase” finds bugs, it’s a problem with your process that needs to be addressed immediately, so the concept of ensuing that QA doesn’t find anything is a great concept to bring out.

Then we move on to Work Ethic – specifically around knowing your field. This means continuous learning, practice (through things like Katas and Dojos), collaboration, mentoring, identifying with your employer/customer, and practicing humility. To help with that, Chapters 2 and 3 talk specifically about saying “No” and “Yes”. When we say no, and when we want to say no, we should mean it. Saying, “We’ll try” means that you, or your team, isn’t already giving it their best, and that through some extraordinary effort you’ll pull it off. Say no and stick to it. But, when you say Yes, mean it. People are counting on you to be truthful with them.

Chapters 4, 5, and 6 begin to talk about the specific practices of coding. Chapter 4 talks about the coding process itself. One of the hardest statements the book makes here is to stay out of “the zone” when coding. Bob asserts that you lose parts of the big picture when you go down to that level. While I may struggle with that assertion, I do agree with his next statement that debugging time is expensive, so you should avoid having to do debugger-driven development whenever possible. He finishes the chapter with examples of pacing yourself (walking away, taking a shower) and how to deal with being late on your projects (remembering that hope is not a plan, and being clear about the impact of overtime) along with a reminder that it is good to both give and receive help, whether it be small questions or mentoring others.

Chapters 5 and 6 cover Test-Driven Development and Practicing. The long and short is that TDD is becoming a wide-spread adopted practice, in that you don’t get as many funny looks from people when you mention TDD as you once did. And that coding at work doesn’t equal practicing your tools and techniques – instead you should set aside specific time to become better through coding exercises, reading and researching other areas (languages, tools, approaches), and attending events and conferences.

Chapters 7 and 8 cover testing practices. In Chapter 7 the book looks at Acceptance Tests and the cycle of writing them – specifically at what point the customer is involved (hint: continuously) and how to ensure they stay involved. Chapter 8 goes to more of the unit testing level, and defines some strategies and models for looking at unit testing, including an interesting “Test Automation Pyramid”

Now that we’ve covered the developer herself, coding and testing, the book moves on to discussing time. Chapter 9 covers Time Management strategies – staying out of “bogs” and “blind alleys”, using techniques like the “Pomodoro” technique to create focus, and the law of two-feet – if you are in a meeting and aren’t getting value out of it, you should feel free to (respectfully) leave, or otherwise modify the meeting to get value from it.

Chapter 10 covers several different methods of estimation. In the teams I work with, estimation is perhaps one of the hardest things – not because estimating can be hard (which it can be) but because either they are held so tightly to the estimates that they are afraid to make them, or, worse, they are told what the estimates are going to be. The book really only skims the surface here, covering several techniques from Planning Poker, to PERT, to “Flying Fingers”, but gives a decent overview of how to do those techniques.

Rounding out the discussions of time comes Chapter 11 and talking about Pressure. The key of this chapter is that because you have committed to your principles, practices and disciplines, you should be able to stay calm under pressure. I can certainly say from experience that the worst experiences in my career are when people weren’t able to stay calm, and the way the book is laid out, if you are following the practices outlines so far, you should be able to be the voice of reason and calmness.

The last three chapters cover teams and collaboration. Chapter 12 talks about important practices such as shared code ownership, pairing, and respect for other team members. Chapter 13 covers teams and the importance of having teams that gel together. The book finishes with Chapter 14 and discussions of the importance of apprenticeship, mentorship and craftsmanship.

As I mentioned earlier, I’ve been involved in the “agile” movement for quite some time, and have spoken with Bob on many occasions, so many of the practices in the book weren’t new. I did quite appreciate the stories he had to tell about his experiences. However, I think that some people may be turned off by the hard line around “professionalism”. Sometimes you do need to say no, and I think it is good to have encouragement from a book to do that. But sometimes things are more complex, and I think that you would have a harder time looking to this particular book for help with the edge cases.

In conclusion, I think this is a book which provides worthwhile information and an interesting look at how people are looking at software development as a profession. If you read between some of the hard lines made, there are some great nuggets to be gleaned from the book for software developers of any level.

One of the biggest changes for many team who are adopting agile is in the way they slice, track and measure their work. They learn about “User Stories” which are sized using “Story Points”. The team adds up the number of Story Points in a given “Sprint” which gives them their “Velocity”. I don’t put the words in quotes to belittle them, but to point out the official terms.

In fact, there are some very good elements to this. The story format can be quite helpful for focusing teams on what it is they are trying to deliver. Further, the idea of breaking down the work into small, incremental chunks is fantastic. And story points have a great attribute about them – they are relative. You aren’t trying to measure the exact amount, but rather a relative estimation (“This story is twice as hard as this other one, so we’ll call this a 4 and that one a 2”).

But the one drawback comes when you begin interacting with other teams, or looking at different methodologies. Specifically:

• How do you deal with teams with different sprint lengths?
• How do you know teams are estimating the same way?
• Can you ever really trust velocity numbers across teams?
• How do you forecast estimates across teams?
• What happens when you remove the timebox of the sprint completely?
• How do you “credit” stories which aren’t completed during the Sprint?

In fact, there are several solutions to the above problem. For example, you can have an estimation session where members from each team estimate a set of items, and the teams use that as the baselines. You can do other mathematical tricks to make it work, too. So it is possible.

But what if you didn’t have to do that? What if there was a way to get a more quantifiable estimate without resorting to detailed hour estimates, without removing the relative estimation and whose accuracy and confidence levels could be proven?

To understand, let’s take a look at a scenario that I see played out quite often. We have a user story which a team has committed to, say to change a user entry screen. The team “completes” the user story. In fact, all of the teams complete their user stories. But yet, the application still isn’t shipping, there are lots of delays, and it isn’t clear why.

Well, at least at the surface it isn’t clear why. If you step back, you discover that after the team is finished, it goes into User Acceptance Testing, and then packaging, and then deployment. In other words, the User Story isn’t actually done – even though the team said it was. This may not seem like a huge deal, but let’s look at the consequences:

1. The team isn’t honoring their commitment to their process
2. Forecasting based on the velocity is useless, since there is additional work happening behind the scenes not being accounted for
3. The team grows frustrated because they know the velocity number isn’t reality

Note that none of the above is the fault of the methodology itself. The team isn’t adhering to it, and from that are causing potentially very large problems. So, if this is our reality, and it isn’t possible to shrink the UAT/Packaging/Deploy to the size of the sprint, what should the team do? And since these are variable length stories, how can we accurately forecast and estimate?

Luckily we actually have a very simple method which combines relative estimation, Cycle Time and Classes of Service. Let’s tackle the first two first. Going back to our story above, the team pulls a story to change the screen. In Scrum, they would discuss the story with the customer, break it down into tasks, and estimate it using Story Points. Instead of doing story points, let’s imagine they used T-Shirt sizes – Extra Small, Small, Medium, Large, Extra Large. So far it isn’t that much different – I generally advised teams that anything larger than an 8 shouldn’t go in a sprint.

But here’s where it gets different, Rather than add up the story points completed during the sprint, they measure the cycle time of the stories. The Cycle Time is the amount of time that it takes for a story to go from initially being worked on through shipped. It includes any loopbacks or rework. Now, let’s imagine we charted the T-Shirt Size and Cycle Time for each of our user stories. We might get a chart that looks like this:

You can see a couple of things. First, we can quickly calculate the Average Cycle Time for a given size story:

• Small – ~4 days
• Medium – ~15 days
• Large – ~27 days

But, more importantly, we know the confidence in those estimates. For Small stories, we know that the minimum is 3 days, and the max is 5 days, with a standard deviation of only about 1 day. But for Large stories, the minimum is 23 days, and the maximum is 31 days, giving us a standard deviation of just over 4 days. So the risk is higher that we won’t meet the Average Cycle Time.

So now that we have our Average Cycle Time, we can use that for forecasting. If a certain feature consists of 5 medium stories, 3 large stories, and 10 small stories, we can estimate out approximately how long it will take us – (5*15) + (3*27) + (10*4) = 196 days. But in reality, it could take us as long as (5*16) + (3*31) + (10*5) = 223 days if every story took the maximum amount of time.

What’s nice about this way of looking at forecasting and estimating is that the calculations are based on the actual time it takes the teams to do the work. And it is easy to calculate across teams, since you can take into account variances and differences as part of the calculations.

If you remember earlier, I mentioned there was one more element to Average Cycle Time for forecasting – Classes of Service. Jeff Anderson has a good blog post on the concept, but in a nutshell, classes of service are a recognition that all work is not the same, and should likely not be treated the same.

What this means for us is that we can extend out our Average Cycle Time estimation to include Classes of Service. Let’s say that we’ve defined three classes of service: Normal work, Bug Fixes and Critical Fixes. By simply having those marked on our board, we can track the Average Cycle Time for each category of work. In fact, I use this with teams to help them understand how to get a better handle when some work requires the assistance of a certain part of the organization, and when other work requires a different part.

Let’s imagine that we have a separate department which houses the Database Administrators. When we make a change that requires a database change, it has to be handed off to them. That’s a type of work which has a different workflow, and different policy requirements – meaning a good candidate to be labeled as a different class of service. Now our table might look like:

Should you actually break your work and forecasting down to this level? Not necessarily. After all, if you have flexible dates, or can cut scope to account for work changes, then going through all of the work to understand the averages, deviations and probabilities may not be worth it. But if you have a high need for better estimates, then using Average Cycle Time may give you what you are looking for.

One final note – even if you are using Scrum, I still highly recommend tracking the Average Cycle Time of the stories. You don’t have to throw out your Story Points, but you might find that you look better wearing a T-Shirt instead.

Are the 5 whys only for root cause analysis? Can they be used to find out the purpose of a new user story or theme?

There are many ways to break down user stories to discover their purpose. Three of the most useful are 5 Why’s, Given-When-Then, and Use Case Scenarios.

Let’s imagine we’ve gotten the following feature request from our business customer:

We need the system to handle multiple allocation requests

(Note: This is a scenario from a customer I was talking to this morning. They had a little more detail, but we’ll pretend we just have the barebones)

Let’s take a look at what happens to this feature using each of the methods.

5 Why’s

In the 5 Why’s scenario, we start asking why the customer needs this. It may not drive us to user stories at the end, but we will have a better understanding of what is going on, and we may find user stories along the way. Let’s watch.

Developer: Why do we need the system to handle multiple allocation requests?
Customer: Because some orders will need to be split up.
Developer: And why do they need to be split up?
Customer: Because not everything will fit onto one pallet.
Developer: Why won’t it all fit?
Customer: Because we can only put so many of an item onto a single pallet. There’s just only so much room available to stack stuff safely.
Developer: So why does that affect the system?
Customer: Because we don’t want customers to have to think about pallet splitting. We just want them to be able to place the order, and the system figure out how many pallets it needs to go onto.

We can see from that exchange that we learned a lot more about the system than we initially had:

• Pallets have an upper bound of how many items can fit onto it
• The system should know how much of an item a pallet can hold
• Customers will order more than one pallet’s worth of stuff in a single order
  • We’ll have to ship multiple pallets
  • We’ll have to track multiple pallets
  • We may have to handle returning multiple pallets of items
• Multiple pallets should still be considered a single order
• It isn’t clear if we can mix different items from the same order onto a pallet

We can then begin to turn these insights into user stories which capture what we need. But what if we tried just going straight into understanding what we would need from the system to make it work?

Given – When – Then

If you’ve seen the wonderful Ruby tool Cucumber then you are familiar with the syntax of Given-When-Then. It basically says that Given some preconditions, When an action happens in the system, Then post conditions should be met. We can apply that to our original feature and see what happens.

Developer: Ok, so you’ve said that the system should handle multiple allocations. At what point should it be able to handle those?
Customer: Well, when the customer places the order
Developer: Ok, so When the customer places an order…what should happen?
Customer: Well, it’s not just any order. When a customer places an order that doesn’t fit on a single pallet.
Developer: Ok, so Given we know how much can fit on a pallet, and Given that the customer has placed an order which is larger than a single pallet can handle, When they place an order, what should happen?
Customer: Well, the order should be split up among multiple pallets
Developer: Ok, and should those be treated as the same order, or should they be shipped as separate ones?
Customer: No, no, they need to all go out and be tracked as one order

So from this conversation we might be able to create a scenario like the following:

Given a pallet can hold 15 items
When a customer places an order for 45 items
Then the items should be split among three pallets
And all the pallets should have the same order number

We can then continue to create scenarios around the various things that will come up about the system. What about orders with different item types? What about orders which don’t fill up a pallet fully? What about returns? We can use the Given-When-Then syntax to come up with each of those.

Use Case Scenarios

When you start running into complex scenarios, a cautiously handy tool can be Use Cases. I say “cautiously handy” because Use Cases can tend to focus our thoughts away from communication and closer to the realm of documentation focus. We should always be thinking about the “Working Software over Comprehensive Documentation” line from the Agile Manifesto and use that to guide us on what our focus should be (and see Alistair Cockburn’s article Use cases, ten years later).

At their core, Use Cases define several flows, similar to what we saw in the Given-When-Then syntax. There is the normal flow, which is the “happy path” through the system. There are alternate flows which are different paths the user can take. And then there are exceptional paths, which define what happens when a user runs into a problem (for a more in-depth look, see Alistair’s Basic user case template).

Let’s go back to our developer and customer to see what happens:

Developer: Ok, explain to me how the user would see multiple allocation working
Customer: Well, they would start by placing an order on the entry screen which includes a quantity greater than a single pallet can hold. When they placed the order, the system would split the order up into sub-orders or something and put the correct number of items onto the multiple pallets necessary. The customer would only see one shipment with multiple pallets.
Developer: What if the order contained different types of items? (Alternate Case)
Customer: The system should pack the items in such a way that we use the minimum number of pallets.
Developer: So different types of items can be on the same pallet?
Customer: Sometimes, yes. Other times they should be on different pallets. We have an identification for each type of item which must be packed separately
Developer: So what should happen if the customer puts incompatible types into the same order? (Exceptional Flow)
Customer: Nothing, I suppose. They’ll just have more pallets. Well, actually, I think that we should notify them of the number of pallets it will take to process their order
Developer: Do they have the ability to cancel the order at that point? (Alternate Flow)
Customer: No, no. It’s informational only. Obviously it’s better for us if we minimize the number of pallets we have to use, but no one is going to not order because they have to be put on different pallets

When we work with teams who use the Use Case format, I explain that a Use Case is not a User Story. Instead, we take the different flows through the Use Case and generate stories from it. It actually works out quite well, since the Use Case document tends to capture a higher level vision of what is going on, and then we drive out that implementation using User Stories. At a minimum, the normal flow, the alternate flows and the exceptional flows will all have their own User Stories.

I hope that helps show some different ways you can approach the problem of breaking down user stories. Remember, the goal is not about following a process, but ensuring that you are focusing on how whatever it is you are doing is helping you communicate more effectively with your customers or business owners – and ultimately helping you build your software faster and better.