Jim, I hate you.

I was working on site for a client recently when I said, “Jim, I hate you.”

Jim’s head pops over the side of the cubicle next to me. He flashes me a quizzical look and asks, “Why is it that?

“Because, I can’t write a single line of code now without writing a test to support it. It is all your fault.”

He smiles and replies, “Well, if you are blaming me for writing better code, I’m ok with that.”

Just in case you don’t know, Jim Erwin is our resident rock star (literally, he was a musician in a previous life) and the author of FoxUnit, a unit testing framework for Visual FoxPro. He is also the Software Development Practice Manager and the evangelist for Test Driven Development (TDD) at Visionpace. In addition to having a great sense of humor he is my ever patient coach on TDD.

I took my first TDD course from Jim and I have been incorporating it into my development practices ever since, but not without some trepidation. I try to keep myself open to new methods and try not to discard a new idea until I have tried it. I will usually adapt a new idea into my development and practice it for a while before I make up my mind on how useful it is. My first impression of TDD was that it really wasn’t that different from how we always did things. Other than that whole idea of writing a test that was bound to fail before you even start, how different could it be? We always test our code, right? I mean, it is not like we write some code and just throw it out there for our users. So how is that TDD thing so different?

It wasn’t until I developed the habit of testing my software with unit tests that I really found that out. I have to admit that it wasn’t easy at first. There were all kinds of problems. Most of which I created by not following good practices. Early on I wanted to test everything with FoxUnit. I tested forms and reports and anything that was part of my application. But that is not what unit testing is all about.

As I progressed as a student of TDD, I began to realize that unit testing meant just that. You test units, not complete applications. As developers we are familiar with the concept of writing small pieces of code with discrete functionality. I realize that I’ve known that for years. It was something that I was taught in college, and that was longer ago than I want to admit. However, it wasn’t until I started unit testing that I really became aware of what that meant. I thought I knew and practiced that.

The more I tried to test my software the more I started thinking of how I could break it down into testable units. There were times I wanted to test some object but I would end up testing ten other things at the same time because of the built-in dependencies.  That forced me to look at how I could reduce those dependencies.

As I continued to practice TDD I found myself thinking of how I was going to test the software before I wrote it. When I realized that, I also realized that I wasn’t really doing TDD. When you practice TDD, you write the test first and the code later. What I had been doing was writing the code first and trying to find a way to test it later. When I started writing the test first, I started finding ways to reduce the dependencies. 

Jim, I hate you because I can never write code the same again. You taught me to use TDD. You opened my eyes to a different way to write software. You forced me to see some of the imperfections in how I write code. My code is cleaner because of you, and I have the tests to prove it.

Jim is smiling, and he is ok with that.

…

If you are using FoxUnit or practicing TDD, I would love to hear about your experience. Send us an email or stop by FoxUnit.Org and let us know what your experience has been.

Why use Tasks?

As we coach software development teams in Kansas City, we are often asked about the process of breaking User Stories down into development tasks (anything related to implementing and verify a User Story). This is one of the areas teams struggle with when adopting an Agile process. It's actually something they often struggle with using most any process but most Agile approaches rely heavily on it for a number of reasons.

1) Iteration Planning

Tasks are a good last check for iteration planning purposes. Even though we can rely (to some extent) on past  actual velocity to get a sense of what a team might be able to achieve in subsequent iterations, breaking stories down into development tasks/hours allows the team to leverage what they've learned so far during a given release in terms of some stories being potentially larger or smaller than previously thought. They can use that information to develop a better, more reliable/realistic iteration plan.

During planning, openly discussing development tasks gives all team members a view of what will take place while implementing the stories selected for the iteration. During that discussion they can help each other clarify and improve their development plan and discuss lesser known areas of the code, database, etc. to help other team members learn and become more productive in their development.

2) Iteration Burndown (what's left <how many hours> to do within a given iteration)

Having tasks with hours estimates enables the team to discuss (during the Daily Stand Up meeting) why certain tasks might be taking longer than planned, why some tasks were overlooked when a story was initially discussed, why some tasks weren't ultimately needed. With this information, it becomes apparent that at times, developers may be struggling with a given task and may need help.

It also enforces thinking more thoroughly about tasks needed to complete a story and aides in becoming better at tasking and task estimating during subsequent iteration planning meetings. It also allows the team to get an earlier sense of whether the goals and story points planned for a given iteration will be achieved and allows the team to consider adjustments sooner.

3) Accountability

Defining and estimating tasks makes team commitments to an iteration public knowledge and increases
the sense of urgency of getting better at task definition and estimation. It also can help with maintaining a sense of focus on agreed upon tasks and indirectly trims waste related to gold plating. It can encourage team members to seek assistance on tasks they might be struggling with as their 2-hour task still isn't done after a couple of days effort while the teams velocity begins to become negatively impacted.

Developing for a story without tasks can lead to stories that don't get done or done as hoped. Without tasks, the team loses the ability to provide assistance (since nobody knows what you're doing) and overall iteration and ultimately release predictability suffers.

4) Shared and Individual Learning

Discussing, defining, estimating and tracking tasks allows the entire team to learn about the problem domain, especially when the domain or parts of it might be new to certain team members. It also helps all team members become better about planning the work needed for all stories and helps them to become better definers and estimators of tasks.

5) Tasking Encourages Better Design

Thinking through a plan of attack for implementing user stories and creating steps (a.k.a tasks) to achieve it tends to create a higher level of focus and optimize overall productivity. It also facilitates design discussion often resulting in better and more complete story implemenation.

6) Forecasting Velocity

When you don't have the luxury of running an iteration to get an actual velocity but need to provide stakeholders with some sense of cost and schedule, you need to forecast the teams velocity. Using tasks is very effective for this. Do this by estimating team capacity, breaking stories down into tasks/hours until the capacity is filled and adding up the points for the stories you just tasked. You now have a forecasted velocity to provide a preliminary forecast of cost and schedule.

7) Tasks Serve as Reminders

When you task, typically at the beginning of an iteration (during the planning meeting), you have the users  attention and are able to ask questions to which you'll need answers to enable you to think about your plan of attack for a given story in terms of development tasks that will be necessary. Even a few days into the actual iteration, you'll forget at least part of what you discussed with the user if you don't have recorded tasks and you'll have potentially less access to the user to confirm/reconfirm tasks and/or stories.

8) Talk to the Dog

Having to talk out loud and/or in a public setting about tasks you'd need to complete a user story tends to create greater focus than just beginning to code. It typically creates better overall productivity and thoughtfulness in approaching the implementation of a story.

9) What if you hear, "I can't/won't task."?

If a team or team member simply says they won't task, that's more of a personal discussion. Obviously asking them why they won't task would be a useful starting point, it may ultimately speak more to ego, personality or an underlying resistance to change.

When a team or team member claims they can't task you have more information to work with. A common stated reason is that they "just have to start coding" and don't really know about the tasks until they start working on it. One approach is to say "Fine, then write down the tasks as you uncover them during coding and we'll discuss and learn from those to make you a better up-front tasker.". You can also allow a "research" task (2-4 hours) to allow a developer to spend time looking at the code, database, etc. for purposes of ultimately tasking a user story.

Above are just a few broad reasons why tasking is useful for software development, in particular for Agile processes.

Liar, liar, pants on fire!

Before I start this diatribe, give me a minute to get up on my soapbox. Ah, that’s better. The air up here is not as polluted and I can see more clearly now. Too bad some of you can’t get up on the soapbox with me to enjoy the view, but I digress. OK, before going any further, I warn you that I am about to offend a lot of “kool-aid drinkers”.  If you are one of them, tough toenails, because I’ll give you the bottom line right now – you, my friend, are an idiot.  If you don’t have thick skin, read no further. Those of you brave enough to face the truth, continue on.

We here at Visionpace make every attempt to practice the Agile methodology of software development. We are proud of the fact that this practice serves both us, as software developers, and our clients extremely well. Many of our clients were reluctant at first, but once they understood the benefits, most of them gave it a chance and haven’t looked back.

Agile practices are a good thing, but I do have one beef that I am VERY passionate about and I am about to discuss (some of you might even say, proselytize) it. In many agile discussions, as well as discussions about other software disciplines, one often hears the phrase, “All comments are lies.” Those of you who believe this are (as I have alluded to above) idiots! However, those of you who do NOT believe it, COULD still be an idiot, and so, be sure to get a second opinion.

Hey, I get it. Don’t trust comments. They are not always accurate. Duh! I feel that there are a certain percentage of you out there who actually embrace this belief because it validates the fact that you were doing the right thing all those years by NOT putting comments in your code. No, it just validates that you are lazy. Lazy is not, necessarily, a bad trait in a software developer, but NOT commenting your code WITHIN the code makes you, dare I say it, an idiot. That is the last time I will use that term, because, hopefully by now, you are riled up enough to really listen to me.

Other than the fact that someone either knowingly wrote an inaccurate comment or wrote a comment, modified the code pertaining to it, and then did not update the comment, can any one out there give me a reason NOT to trust a comment you discover in code? We will exclude that person from the discussion because he is a “psycho programmer”; you know the one that NEVER follows any kind of standard and use one character mvars. Besides, most “psycho programmers” don’t comment anyway.

Here are the reasons why you SHOULD comment your code.

1. Let’s get the “trust” issue out of the way right now.  If YOU put the comment in yourself, you BETTER believe that the comment is accurate. You did it (primarily) for yourself.  The fact that an accurate comment will benefit a maintenance programmer who comes down the pike a year later is an extra benefit; a benefit which I appreciate when I am called in to do the maintenance. I will be more than happy to ASSume that the newly discovered comment is accurate because THAT developer put it in there and, like you, why would they want to lie to them self? Yes, there is that chance that the comment is now inaccurate.  Studies have shown, statistically, that approximately 93% of comments ARE accurate.  Right here, you should be asking yourself where I got those numbers, and right here, I will tell you that I made them up.  Who would waste their time researching that fact? Nevertheless, think about it, most comments ARE accurate because the person who writes them WANTS them to be accurate.

2. OK, I can tell you are getting a little bit peeved right now. Dave, I thought our code is supposed to be “self-documenting”? If I write bug free code, why do I have to comment? Oh, grasshopper, you will learn someday.  Until then, trust me, write those comments! In all honesty, I, too, am a believer that under most circumstances, the code SHOULD be self documenting. However, consider the following code:
   
   

REPLACE Name WITH UPPER(SUBST (LastName, 1, 2) + LOWER(SUBST (LastName, 3)

That code is self documenting, if someone wanted to take the time to figure out what it does, they could easily do so. The real question the person should be asking their self is... WHY is that code there? It looks kind of goofy anyway.  When I first saw it, I thought that perhaps the coder didn’t know about the PROPER function, but then, they were really capitalizing the first TWO letters of the name. Maybe the parameter of the first substring should have been 1, 1.  Maybe I should refactor using the PROPER function.  I am soooooooo confused!  Close to an hour of my time was spent determining WHY this code was here.  Imagine how much easier it would have been had the following comment been in place.

DLA/Visionpace 04-01-2004 Mr. Jones, the COO, bought 113 file cabinets at an auction. He has decided that the new company wide filing system will be based on the first TWO letters of the customer name. EACH drawer will have a two letter designation and the file will be placed in the drawer base on the first two letters of the customer name. To make it easier to file, he wants the first two letters emphasized for easier reading.

Immediately, we can see that the code is correct and that there is a reason WHY it was written.  Additionally, as often happens to me, in some scrum, when asked why this was done or who requested it, the answer is there.  Not only for me, but for you when you come in to do the maintenance. Two minutes to initially write the comment or 60 minutes to figure out the details three years later. You do the math.

3. Additionally, what one developer feels is self-documenting, another might not. Why not eliminate any potential confusion and explain the reason for the code’s existence? Again, it will save the next person who comes along much valuable time for there is a real good chance that they will know nothing about the project and the code. Believe me, you will benefit also.  One of my favorite phrases is... “When you are coding, you and God know what you are doing.  Six months later, only God knows.” I can not begin to tell you the number of times when I have gone into some legacy code and the comment I wrote three years earlier IMMEDIATELY brings back to life the exact reason for the code.  Many is the time that it has saved my fanny. Those are the times that I almost dislocate my shoulder patting myself on the back for a job well-done.
   
   

If you have made it this far, you are just not getting enough billable hours in.  However, thank you for reading along and agreeing or disagreeing.  Either way, I would appreciate hearing your thoughts on this very polarizing topic. I promise to bring an open mind if you do the same, but I will say right up front, that it will take a Herculean effort to change my mind.  Care to give it a try?

Let the Ultimate Metric Build your Team

At a recent Agile KC meeting in Kansas City, Missouri we met to discuss, among other things, topics that might interest software developers and managers alike for upcoming meetings. One of the topics that always comes up when such a list is discussed is testing. It's interesting to see how software developers increasingly are discussing ways to test software. Everyone (QA, developers, managers, customers, etc.) wants to know what "done" means.

I know we have seen increased interest from our consulting clients in Kansas City where we coach software developers on agile software development techniques and teams and managers on agile project management. Software developers are interested in defining "done" (just as other stakeholders in the project)through the use of not only unit tests, where they're able to demonstrate the integrity of the code at the unit level, but also in terms of acceptance testing or functional testing where the focus is on defining "done" in the customer's eyes.

Acceptance tests sometimes known as "conditions of satisfaction" define the requirements for software features which are most often comprised of one or more user stories. They are defined from the perspective of the customer for a given business need, exactly where the emphasis should be in the first place. So the combined set of tests ideally maintained and run in an automated fashion to help speed up development, make up the overall requirements for the system.

Having the requirements defined in advance of each iteration planning session is a highly effective way to keep the team pointed in the right direction and create a focus for software development efforts.  The idea is that at the end of the each iteration, working software is available to potentially ship because it works or is "done" in that it has passed the tests defined at the beginning of the current iteration and all tests defined in previous iterations.

Knowing what targets to shoot for each iteration lets the team focus on what needs to be done, eliminates gaming other metrics in use and helps a team identify what adjustments they need to make to reach the goal of delivering running tested software every iteration in a just-in-time manner.

This emphasis not only ensures the software output matches the requirements but it results in leaner, more concise and targeted code that's developed with those conditions of satisfaction in mind. There's less of a tendency to get off track and build features that weren't requested resulting in overall lower maintenance costs and an overall better team in that they develop a shared understanding of the business domain and the software that supports it. It also helps with schedule and cost predictability in that untested code represents an undefined amount of work (potential bugs) that, if left to deal with toward the end of a project, can create wack-a-mole development that often accompanies the classic "stabilization" phase.

We have found that this "ultimate" metric is the best target to hang out at the end of every iteration. Even if it takes a number of iterations to establish the necessary rhythm to achieve the frequent and consistent delivery of running tested software, it's a goal worth tracking and building a team process around.

Static, Thrashing and other Communication Dysfunctions

I was recently in a planning poker meeting which is a step in the release planning phase for agile software development projects where user stories are sized relative to each other. This is a critical step to estimating the cost and schedule of a project. By the way we typically call these meetings in our process "sizing" rather than estimating because we are specifically sizing the stories relative to one another, followed by another step to actually determine the estimate in terms of hours and therefore cost and schedule. 

This was one of the most painful meetings I've attended in recent memory. Painful because of the communication (or lack of) taking place during the meeting. While there was no shortage of experienced and talented developers and other stakeholders in the meeting there was a significant shortage of meeting etiquette which resulted not only in the typical thrashing that can plague such meetings but in interruptions, sidebar conversations and conversation threads that didn't pertain to the specific user stories or in some cases the project being sized.

We typically track the time it takes on average per user story across projects when it's feasible to do so in order to inspect and adapt and find ways to optimize the time we spend sizing each story.  What we noticed at the end of this particular meeting was that over 80% of the time spent was in the area of discussing items not specific to the story or in some cases far too specific, which was an indication for us that not enough time was spent in the most productive parts of sizing a story.

Based on this performance we have decided to display simple meeting etiquette rules similar to those types of rules we've seen in other corporate meetings reminding people to focus on participants as they are speaking and to try to limit interruptions unless they feel they're absolutely necessary in terms of understanding the point at hand and limiting side conversations, again unless they're seen as necessary. 

In the context of a user story sizing meeting we've also reminded ourselves of simple adjustments such as letting the customer read the story and then letting developers ask questions by taking turns. We'll ask those people not speaking to write down points or comments they feel they need to make. We hope these steps will go a long way towards focusing the conversation and reducing the needless amounts of static that we witnessed during this meeting and in general help optimize the time spent sizing stories across all of our projects.

While we acknowledge the fact that it's impossible to completely eliminate things such as interruptions and thrashing and even some sidebar conversations especially when you have very bright and creative people in the room such as we did for this meeting, we also feel strongly that if this isn't addressed it will result in not spending resources wisely.

On Being Agile

As you've worked on or with teams making the change to more of an Agile Software Development approach, you've probably heard comments along the lines of, "Hey, this is just assigning a name to what we've already been doing." -or- "These are all just common sense concepts.".

As we coach teams on adopting Agile principles we try to respond to comments like this confirming that yes, Agile principles mostly represent filtering out activities that don't seem to be useful (at least not in every situation) and doing more of the remaining activities most of the time. These activities (or Agile principles) tend to be the items that people list as being useful to deliver working and testing code on a frequent/consistent basis. These also tend to be the elements that people list as existing on teams they've worked on in the past that they viewed as successful.

We encourage teams to not get bogged down in calling the process Agile (or not) but to just focus on identifying and alleviating their software development pains by applying principles that may or may not be a traditional part of one or more Agile methodologies. It goes without saying that every team and situation is different, so one way to view Agile principles is that they provide a framework of useful concepts that you can introduce (gradually in some cases) to attempt to fix a broken process. Some of them will be common sense (depending on which team member is viewing them), some fill in holes in a current process that isn't working and others add "just enough" structure to provide useful metrics and oversight for management and all stakeholders.

So on the topic of being or becoming Agile, the debate shouldn't focus on "installing yet another methodology". It should focus more on identifying and admitting process pains and deciding which principles (and how deeply you employ them) will be useful to begin addressing the pain.

Want to Build Better Software? Better Teams? Build Trust by Putting People (including yourself) at Ease.

Last night, at AgileKC, an agile software development professional group in Kansas City, our discussion began with writing the word 'trust' on the whiteboard. A couple of hours later, we had covered a lot of ground and one of our members finished at the board collaborating with the group to help him generate ideas for an upcoming column he's writing which will mostly focus on 'Agile Smells', identifying symptoms of and suggesting remedies for software development team and process issues. Not surprisingly, 'trust' was a recurring theme during that discussion as well.

We started AgileKC approximately one year ago and these meeting formats tend to be my personal favorites as the ideas and perspectives are openly shared and discussed and I always walk away with useful things to include in Visionpace agile pursuits. Next month we'll have a format where we'll meet in a private room at a local restaurant and sit around tables informally discussing a variety of topics and enjoy a meal in addition to hearing a more formal topic presented by a member of the group. In my experience attending professional meetings over the years this is by far the best format for maximizing learning and networking.

So back to 'trust'. I stumbled across a post on an XP list I'm on that referenced a video featuring Kent Beck discussing, 'Ease at Work' which among other things, related to the softer or more personal side of software development teams, including accountability, responsibility and of course, trust. I think there's a lot of valuable overlap with last night's discussion and as always, Kent shares a number of useful perspectives.

Here's a link to one review of the video on Reblog. You can view the video on Google Videos and YouTube.

The problem with percent-complete

Does this sound familiar? 
PM: “Jason, what is the status of the XYZ Modulator?  Last week you were at 55% and management is breathing down my neck.”
Jason: “Well, I implemented the auto-reload, and the changes from QA. I’d say were about 70-75% done.”
PM: “Great 20% more than last week!  That will make the Powers that Be happy.”
… One week later …
PM: “Jason I need an update on the project status.”
Jason: “Uhhh, yeah about that. Well I found that the auto-reload didn’t work for have the new data types so I spend the last week fixing that.”
PM: “Oh.  Well what should I put as the percent complete? It’s 75% now.”
Jason: “Ummm, how about 80%...???”

When I witness these conversations, or hear about them, I see red flags everywhere.  Percent complete seems to have taken a life of its own outside a Gantt chart.  It has become, in some instances, the measure of all work.  Don’t get me wrong. I think it’s valid to say that we are X% to implementing a piece of functionality provided you also include a reference to a percent complete of what you’re measuring.  (I.E “We initially thought this was going to take 30 hours. That’s still valid and were about 50% there.” From this, one can deduce that about 15 hours have been worked on the code, and about 15 hours remain.) 

One problem with the initial, and far too common, example above lies in not having an underlying measure to use as reference.  If you don’t have some reference included the use of percent complete gets clouded.  Even trying to say ‘I’ve been working on the code for the last three days and I’m 60% through’ leaves some information out of the status.  Were you spending all of your time for the last three days on the code, or were you working on other tasks as well?  What are the plans moving forward?  Are you saying that you anticipate being done in two more days?  In 16 hours?    You’re 60% of what?

Another problem is using percent complete as the only measure of progress in a project.  By updating percent complete as the only means of a project metric, a project can appear to be progressing all the time at a steady pace when its not. The risk is that a culture can develop that the developers are conditioned to give some number greater than the last number they gave for percent complete.  Unfortunately for the developer, the number can’t go above 100%.  So what usually happens is a feature is started and the developer spends say two days working on the feature and feels that they are making good progress and say at the first status meeting that they are 30% (or some other optimistic number) complete.  The next two days they find that they didn’t account for a needed architecture originally in the first two days, so they spend the time implementing it. In the larger picture, in terms of having the feature implemented, they are at the same place as the last status meeting, but have a better architecture.  Since the metric is percent complete, not updating the metric would indicate that they didn’t do anything for the last two days.  So they have to give a number to justify their efforts.  So they choose a number like 15% and report that they are now 45% complete.  You get the picture.  Before too long the status chart shows the code at 80% complete, and in terms of hours spent to date over the overall amount of hours forecast, the number is much less than 80%.  Usually the percent complete starts to increase much more slowly; in increments of 1-5%, until the measurement is finally reset.  Eventually the reporting becomes a dance that everyone feels they have to perform, but nobody on the team has any faith in it. Unfortunately the memo to the executives is seldom sent…

It doesn’t always work out this way, but often I find that projects that rely on percent complete do so because management likes it.  It’s an easy thing for management to understand.   In addition the management in question often hangs their hat on the number and holds it to assumed (and often not-discussed) standards. 
Some of these standards include:
- If you’ve spent time working on the project and the percent complete didn’t increase, you didn’t provide any value to the project. (As described in refactoring example above.)
- Percent complete shouldn’t go backward.  If a house if 50% complete this week, it won’t be 40% complete next week unless some outside factors are in play (like a wind storm.)  Software development doesn’t work like this.
- Percent complete will increase at the same rate during the entire project.  Reporting that the project is 20% complete after two weeks often times allows people to assume that the project will be done in eight more weeks. 
- Percent complete is perceived to always be accurate.  If you say that you are 86% complete, it is assumed that there are empirical calculations to back that up.  Often times, the only thing to back the number up is the number a developer pulled out of the air during a meeting.  Even worse each developer throws out the number for the things they have been working on, so there isn’t any consistency between the metrics for the different tasks the team is working on.

This is why Visionpace follows the model of forecasting pieces of work in ‘story points’ and then when we start working on a specific feature, we break the feature into tasks.  The tasks are estimated in hours, and ideally the entire team is involved in determining the estimates.  This allows for multiple viewpoints and voices, and tends to create more realistic estimates.  As the tasks are worked on the status meeting focuses on:
- What did you work on yesterday (how many hours did you get to spend working on the task)?
- What are you going to work on today (how many hours are left on the task at hand)?
- What are the roadblocks, if any? By asking these questions regularly, the entire team is involved on all of the development.  Tasks that are underestimated initially are identified quickly and the factors that led to the underestimation are presented to the entire team, so they can be understood for the next estimating session.  Additionally, with this approach, if a developer is struggling with a task, it is apparent to the entire team and assistance can be addressed sooner rather than later.   One final benefit of measuring the tasks in hours, is that it’s easier to plan on when the tasks is expected to be implemented.  (Consider the statement, ‘I think there are six hours remaining on this task. I’m out half a day tomorrow for my kid’s doctor appointment, so I expect to have it done before lunch the day after tomorrow.’  This explains in succinct detail, what is going with the task.

If you’re interested in this approach feel free to contact me at Visionpace. We deliver custom software development following agile principles in Kansas City.   

What’s your Bus Number?

I really like when an idea can be illustrated simply and effectively in a simple term, one that everyone can understand. I recently came across one of those terms on the web and shared it at the AgileKC group last night.

The term is ‘bus number’ as in “What’s the bus number of this project?” The underlying idea is how many people need to be removed from the project (walk out in front of the proverbial bus)  before the project is in jeopardy. If you have one developer who is the only person that can only work on a specific part of the code, and a hundred developers that can work on everything else, your bus number is one. If every developer can work on every aspect of the code, and you can reasonably bring new developers up to speed on all aspects of the code if needed, you can answer the question by saying, ‘There aren’t enough busses in New York City to affect this project.’ (Swaggering while walking away after saying this is optional.)

The goal is to have a very high bus number, or said another way have a lot of code ownership in the project. But code ownership might be difficult for everyone to understand. The concept of a bus number isn’t. The context of the conversation last night was in relation to pair programming. The proposition I was making was that pair programming is an effective way to increase the bus number on a project.

I don’t know if there will be a big visible chart in our war room for bus number in the near future, but if I come across a project that code ownership (or the lack thereof) can cause a spectacular failure (ala Scott Ambler) I think I would create a chart on a 3ft. x 3ft. piece of paper that had the title Bus Number, and have one element, the project’s bus number. It would be effective in generating the appropriate conversations and would most likely put focus on resolving the issue.

So what’s your bus number?

When the story doesn’t fit

On a recent .NET consulting project in Kansas City, where we were doing software development and agile project management coaching, the team was struggling with sizing our user stories to fit our iterations.

Invariably during our projects we find that some of the user stories we came up with during the initial story workshop don’t really fit in the project development as written. Sometimes they are too large for the time allotted and/or have some high priority tasks and some not so high priority tasks. Other times we’ve learned so much about the project, the initial story doesn’t encompass all the facets it should. The question is what to do with these stories. Should the entire story be tasked out and carried over to the next iteration, should only the necessary tasks be focused on, and the story carried over, or should the story be broken down into smaller stories?

The answer, like a lot of answers when following an agile approach is; it depends. One can make an argument for any of the scenarios listed. Since I’m the kind of person that has a ‘I want to show progress on the burn down’ perspective, I prefer to break the story into smaller stories that ‘slice the cake’. (The stories aren’t all user interface or all back end processing. Rather they have some user interface, some middle tier logic and some back end processing.) What’s important is to capture the stories based on the current understanding, scope them in an appropriate size as much as possible so they don’t have to be broken down again later, and make sure that nothing falls through the cracks.

Once a story is broken into new stories the next thing to consider is how to forecast the new stories. Often times there is the desire to say that since the original story was forecast as a five points, and since we broke it into three new stories, one story that is three points, a second story that is one point, the remaining story must also be one point (5=3+1+1).  Don’t do this.  Another pitfall is for the team to say “When we started these stories would have all been threes, but since we have a better idea about what we’re doing, they all look like one’s now.” The key is to forecast each of the resulting stories independently and triangulate them against the existing stories for the project, making sure they are put in the right bucket.

The take away is to make sure the user stories reflect what you are doing in an iteration rather than trying to make the iteration fit the stories defined. If this means that some stories need to be removed and rewritten, do it. Just pay attention to the stories that are created to make sure they will fit in the future and that you don’t lose anything in the transition. Also remember that the forecasting for the stories follows the same triangulation used in the original story workshop.

Software Inventory

How much money will the organization make or save by having a new software feature in use?

The process of prioritizing the selection of proposed software features based on business value and determining the business value of software features can be as much an art as science. Beyond the more obvious examples of forecasted new sales or cost reductions that some software features somewhat easily map to, most features and their underlying business value are harder to determine.

Return on investment (ROI), Payback Period and a number of other approaches attempt to assign a tangible value to software features for purposes of making decisions on what to build next and in most cases, entire projects or release items. While these methods do work in a number of circumstances and are getting better in aiding business value prioritization, often times it comes down to the intuition of business domain experts. The people that are closest to the business problem the software features support can often see the value of a feature, at least relative to other features.

Having done software development and consulting in Kansas City for some time, one of the most important points of analyzing the business value in our opinion has been to have the discussion in the first place. Regardless of the analysis and approach used (ratios, intuition, etc.), merely spotlighting the need to make decisions on software features to build based on the value they'll add to the business (and how soon they'll add it) is a significant positive step. Another important point is to continually revisit the value discussion throughout the project not just in the beginning. Learning is a part of any software development (or any R & D process) project and a lot can change and be learned during the course of development efforts. Learning also takes place as business stakeholders see software features in action so getting working, tested features in at least a staging area to promote feedback is important to revisit business value discussions. Having business domain experts (armed with the latest intelligence about their domain [market changes, organizational changes, etc.]) reviewing features is critical for moving software out of inventory and into the business and adding value.

Take a look at your software inventory. Some say that any software development item not being used by your customers/users is considered to be in inventory and therefore doesn't have any real (tangible or intuitive) business value. Some items such as certain project artifacts (documentation, models, etc.) will never leave inventory status so carefully decide their importance in understanding what needs to be built or perhaps create throw-away artifacts, spending just enough time to reach an understanding about a particular issue and moving on.

The goal is to put things in inventory that will ultimately be valuable and then move them out of inventory to begin delivering value to an organization as soon as possible. And, if you're wondering what's valuable (working code, certain artifacts, etc.) to your customer or how they would like you to spend their money -- ask them.

Failed IT Projects Cost Billions: Train wreck in slow motion

Regardless of whether you are developing a new application, website, or implementing a new software system, failures and setbacks occur.  It happens.  It's inevitable.  It costs.  Billions.  This article from the Globe & Mail (Canada) talks in depth about the scale of IT failures and some of the potential "whys" .

Let's lay some groundwork here:

The UK public sector alone spends circa 22.6-billion pounds each year on IT, and some reports suggest that 1.5 billion-pounds have been wasted on failed IT projects since 1997. A 2004 report from the UK Royal Academy of Engineers and the British Computer Society estimated that only 16 per cent of these projects succeed, and confirmed that billions of pounds each year are wasted on them — throughout the EU.

Indeed, statistics suggest that 50 per cent of all IT projects fail, while 40 per cent are late and/or over budget, and ultimately delivered with reduced functionality.

These various controversies have led to a major reform of how the Government in the UK and Ireland handles large scale IT projects, but the jury is definitely out, and public trust in elected officials has visibly eroded.

But lest we get smug here in North America, it is abundantly clear that such wanton waste is not just an EU concern. It is a global pandemic that needs urgent attention. And Canadians have plenty of home- spun examples to call upon.

In the US, the FBI recently disclosed that a post-911 IT project that has cost $170-million (U.S.) to date has been an abject failure, and that they will have to start again. Sen. Patrick Leahy of Vermont, the senior Democrat on the Senate Judiciary Committee, was quoted in Wired magazine as describing the whole fiasco as "a train wreck in slow motion."

Source: Globe & Mail: GlobeTechnology

You're not going to read any smug "it's never happened to me" lines here.  There are still a few projects I'm sure we all wish we had never started.  Several projects that, although they were eventually completed, were over-budget or somehow short of expectations.  So the question remains, why.