Innovative agile delivery with a chewy craftsmanship center
A couple of weeks ago I got the chance to speak about Apprenticeships and Software Craftsmanship at Ignite Tampa Bay – specifically how we grow the talent pool locally when so many businesses are complaining about a lack of talent. The talk has now been published!
Thanks to the entire Ignite Tampa Bay crew for letting me take part!
{ 0 comments }
(If you’d like to see the video, click here)
Earlier this year I was invited to be a speaker at SCNA 2012. At the time I was thinking a lot about quality and about the learning and growth process of developers. Back in March I helped launch the Florida arm of 8th Light, and now had several apprentices and craftsman under my mentorship. I noticed that when we did exercises where we let the code build incrementally – such as using Test-Driven Development – it ended up quite a mess during the process. Why was that? The code was clearly telling them what…
And then it hit me. The code was talking to them, but they couldn’t hear it. Or understand it.
The idea of code talking had been planted in my brain by Scott Bain and Alan Shalloway of Net Objectives. They introduced me to the patterns work of Christopher Alexander which stated that patterns aren’t recipes to be applied, but rather inherent in the problem itself based on the forces at play. For example – what’s the difference between an Adapter and a Façade? An Adapter is when you need an external class to be an explicit part of an existing class hierarchy. A Façade is used to simplify an interface your system has to work with. They both are implemented in similar ways – by wrapping an existing class – but the forces they resolve are quite different. As such, Adapting a class whose interface you need to simplify may be a sign that things aren’t quite as you think they should be.
But this idea that patterns are inherent in the problem itself – how do you teach that to beginning developers? That question led me to look into the way that we teach people programming languages as a whole. If you look at most any book, tutorial or webcast about a language, the writers tend to start with syntax – “Here’s what a loop looks like. Here’s how we do closures and lambdas”. Outside of “Hello, World” you have to muddle your way through syntax first, and then try to think through how to apply it to your real world situation.
Through lots of reading and research, I came across a model which seemed to explain why the above approach to learning programming was not ideal. And it came from a not-so-unlikely source: second language acquisition. It turns out that when we want to learn a second natural language – like German, Japanese or English – we don’t start by asking what nouns and prepositions are, and how to conjugate verbs. We start by transference – applying knowledge about existing situations to learn how they are expressed in the new language. For example, when I travel internationally I make sure to learn how to say 5 things in the native language – “Hello”, “Goodbye”, “Please”, “Thank You” and, most importantly, “Do you speak English?”. When we went to Germany for three weeks several years ago, I extended that by learning conversational situations such as being in an airport, asking where a potty was, etc.
This way of learning is captured in a model called the BICS/CALP model. This model lays out two key stepping stones for language acquisition. The first, Basic Interpersonal Communication Skills, establishes the skills necessary for social interactions. The second, Cognitive/Academic Language Proficiency, covers the skills necessary to succeed in academic or cognitively challenging situations. These skills, along with examples, can be seen in the chart below:
Another interesting thing came out of thinking about acquisition of development skills in the same way we look at acquiring a second language. Specifically the idea of dialects. Even if one does learn “English” or “Spanish” there are lots of local dialects and slang which can still trip up a non-native speaker. Similarly, in programming we create our own dialects. We tend to codify these through documents like Coding Standards, but also can be the mindset and approach to the task at hand. For example, taking a language designed around an imperative programming paradigm – such as Ruby – and applying principles and ideals from a different paradigm – such as logic or functional programming – we end up with a hybrid approach which may not fit the specifics of “by the book” teaching.
But thinking about dialects exposes the root of the problem of starting with syntax – even if one does learn the syntax, there is no guarantee that’s going to be the right one for the team or project they are working on. We need a different approach to bringing people up to speed. Luckily, we already have the tools, and we have a model we can use, so let’s put it all together.
One thing that really struck me about the BICS/CALP model was the idea of multiple baselines. We tend to give developers the ideal that if they have a REPL and 10,000 hours, they’ll be experts. And while 10,000 hours is an important metric (even if it seemed like I said it wasn’t in my video of the talk – it was a bad segue into the ‘C++ in 24 hours’ slide), it doesn’t give us enough information. Specifically – at what point can we begin introducing a developer to production code on a project? How do we help her get up to speed as quickly as possible?
I began thinking about what would establish a “Basic” baseline and an “Advanced” baseline given the constraints of the BICS/CALP model – specifically – how do we start with something that is cognitively unchallenging and provides a lot of context? Once that is mastered, what would be the next step of providing reduced context but still not being cognitively challenging? This led to the creation of the following model:
In this model, we start with Katas. Katas are exercised which are designed not to be challenging to solve, but to provide a test-bed to practice tools and techniques. They are the perfect fit since we have a lot of context (we understand the problem innately) and they aren’t cognitively challenging. We can simply say, “I know this is how I would approach the problem – how do I express that in this language or this dialect?”
For example, if we wanted to print “Hello, World” to the computer screen, the thought process could look like this:
puts and specify a string by putting it in quotes, so puts ‘Hello, World’”System.out.println and I have to pass to it a string to print. I can specify strings by putting the words in quotes, so System.out.println(‘Hello, World’). Oh, I guess I have to end every statement with a semicolon, so System.out.println(‘Hello, World’);”Once we have a grasp on transferring situations we already understand to the language, we can move to Koans. These provide an understanding of the Syntax of the language. For example, the Ruby Koans specify things like “about_hashes” and “about_nil”. We aren’t being cognitively challenged, since we are just following the guidelines in small steps, but we don’t have as much context because we may not completely understand nil.
Working through Katas and Koans establishes a baseline of knowledge for the language or dialect. At this point, we can begin to introduce more cognitively challenging situations, but provide them with a lot of context. This would typically be pairing on a new feature, or pairing on providing production support for an application. The developer is now having to really think through the application of the language, but has the context to see how other people have done it in that project.
Finally, they can begin to understand and listen to what the code is saying. This requires cognitively challenging work with little context. After all, if something is telling you to extract it as a method because it would resolve a force at play – you have to have a lot of inferred context and thought in your head to pick that out.
Over the next couple of weeks, I’m going to be publishing some additional articles on the implications of this method, how things break down in the lines, and diving deeper into some of the concepts like intermediate katas and listening skills for code. In the meantime, your feedback is more than welcome and encouraged!
If you’d like to see the video of the Foy-Z model being introduced at SCNA, you can watch it below.
SCNA 2012: Cory Foy – When Code Cries from 8th Light on Vimeo.
{ 1 comment }
Quick code post – We’re working with a client who needs to be able to select imprecise dates – either an exact date, the month and year, or just the year. Most date pickers aren’t set to handle this case, and I didn’t really want to write one from scratch.
We were already using the JQuery Datepicker so with some Javascript magic, I turned it into a DatePicker with Month and Year.
First, I created a method to register a Date Picker, since we have them in many places:
function registerDatePicker(element) {
$(element).datepicker({
changeMonth: true,
changeYear: true,
yearRange: 'c-100:c+10',
beforeShow: function(input, inst) { setDateFromString(input); }});
$(element).focus(function() {
$(this).datepicker('show');
if( $(this).datepicker('widget').find('tr#month-year-select').length == 0 ) {
var tbody = $(this).datepicker('widget').find('tbody');
tbody.prepend('<tr id="month-year-select"><td colspan="3" align="center"><p class="ui-state-default" id="datepicker-month-select">Select Month</p></td><td><p> </p><td colspan="3" align="center"><p id="datepicker-year-select" class="ui-state-default">Select Year</p></td></tr>');
tbody.find('#datepicker-year-select').click(function() { pushYear(element) });
tbody.find('#datepicker-month-select').click(function() { pushMonthYear(element); });
}
});
}
Notice that I’m adding in buttons to select the month or year right after the tbody. Because the Datepicker doesn’t actually select a date at default, or whenever you change the month or year, the following methods make the right thing happen:
function pushMonthYear(element) {
var shortMonthString = $('.ui-datepicker-month option:selected').text();
var monthNames = $(element).datepicker("option", "monthNames")
var shortMonthNames = $(element).datepicker("option", "monthNamesShort")
var monthString = monthNames[shortMonthNames.indexOf(shortMonthString)];
var year = $('.ui-datepicker-year option:selected').text();
$(element).val(monthString + " " + year);
$(element).datepicker("hide");
}
function pushYear(element) {
var year = $('.ui-datepicker-year option:selected').text();
$(element).val(year);
$(element).datepicker("hide");
}
Finally, because we want it to go to the right screen whenever there is something already in the box, there’s this method, called beforeShow:
function setDateFromString(element) {
var dateString = $(element).val();
var createdDate = null;
//Input element has '1994'
if(dateString.length == 4) {
createdDate = new Date(dateString, 1, 1, 0, 0, 0);
$(element).val("1/1/" + dateString);
//Input element has 'September 1994'
} else if (dateString.split(' ').length == 2) {
var splitDate = dateString.split(' ');
var monthString = splitDate[0];
var year = splitDate[1];
var month = $(element).datepicker("option", "monthNames").indexOf(monthString) + 1;
$(element).val(month + "/1/" + year);
}
}
Viola! A bit hackish, but it works well.
{ 1 comment }
Technology Community – let’s chat for a second. Over the past…well, since you were created, you’ve been a male-dominated field. Unlike some other fields, you are well known for your cutesy “lack of social interaction”. Of course, now you are getting popular – it’s cool to be a “brogrammer” and code and hang out at bars, making lots of money and sneering at the people who have held you down in the past. Also, I realize that even though you’ve been around for many years, you maintain a youthful edge to your appearance.
(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.
{ 6 comments }
“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!
{ 1 comment }
In a recent post, Jim Shore blogs about a “Minimum Viable Hypothesis.”
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:
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.
{ 3 comments }
Over the past couple of months I’ve been working with several clients struggling with doing incremental architecture and design. As an organization moves away from a typical waterfall method – with lots of time for analysis and design – they have to find ways to still build scalable, sustainable systems in an incremental fashion.
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:
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):
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.
{ 3 comments }
This afternoon I was teaching a public class on Lean-Agile principles and practices, and a question came up about the differences between Scrum and Kanban. As a fun exercise, I recreated Scrum using Kanban coupled with a set of Explicit Policies.
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.
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:
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:
Well, that was easy! What’s next?
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:
To recreate this in Kanban, we’ll need to do the following:
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.
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):
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.
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.
{ 7 comments }
Over the past couple of weeks, I’ve had the chance to work with several organizations who equate “efficiency” with “utilization.” This morning, I tweeted that if your organization is assigning people 10% to a project, no agile method is going to help you. Renée Ramirez asked for data or evidence supporting the point that this is A Bad Idea ©.
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:
If we actually map this to Bob’s time for the week, it would look like:
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:
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:
| Monday |
| 8-9: Zeta Call 9-11: TTime Update 11-12: ICWUD Code Review 1-3: ICWUD Analysis Session 3:30-5: Farrrgh Code Review |
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:
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.
{ 3 comments }
As someone who has been closely involved in both the “agile software” movement as well as the “Software Craftsmanship” movement, I have been following the work of Robert Martin for some time. So I was quite interested when I got my copy of his latest book “Clean Coder” where he “introduces the disciplines, techniques, tools and practices of true software craftsmanship”. Would his book live up to being a guide for the next generation of developers, or would it go on my shelf as another interesting book that I had read, once?
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.
{ 3 comments }
Cory is a developer, organizational change agent, speaker and Innovation Games facilitator and trainer with a passion for helping organizations grow rapidly and optimize the use of their technologies and processes. He currently runs the 8th Light Tampa offices. You can also find him on:
