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.

Agile Development Presentation

Please join Martin Olson for a presentation on Agile Development.  The presentation will be on June 26, 2007 at Visionpace in Independence, MO.  It will be from 11:30-1:00.

Explore how agile software development can improve your bottom line with just-in-time delivery of "clean code that works". Learn why the mantras "inspect and adapt" and "release early and often" have led to a revolution in system development and delivery.

Martin Olson is a Project Manager at Visionpace with over fifteen years of industry experience. Martin has been working with agile development and the Visionpace team for five years. As a Certified Scrum Master, Martin assists Visionpace's clients in defining and steering their projects to a successful completion.

To reserve your seat for this FREE LUNCHEON and presentation, Please contact Kelly at 816-350-7900 to RSVP no later than June 22.  See you there!!

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.

Shaking Things Up

We talk a lot about our experiences in this column about our agile software development practice...so much so, that perhaps it sounds a little self-serving at times. After all, we're heavily invested in agile methodology. So here's a link to another developer's (Russ Nemhauser's) blog...a developer who joined an agile team at a Large Software Company Somewhere in the State of Washington. His background was in BUFD (big up-front design) and he therefore approached this Scrum project (in .NET) with a great deal of skepticism. Read about his conversion here. He also gives an example of test-driven development and talks about why he's now a believer...so much so that he's uncomfortable writing code before he writes the test(s)....and how (at least in this example) it was a time saver. (YMMV, of course.)

An interesting idea:

This doesn't solve the problem of some clients requiring large functional specification documents, but it does offer at least one potential change to the way they're written: the functional specification can be written AFTER the majority of functionality has been developed and delivered. This is a huge step toward an accurate specification and it also drastically reduces the amount of time it takes to write the document.

Say it in tests

Visionpace has been working with a client, providing agile coaching, over the last few weeks. Like all of our clients, the organization is full of bright people, making a viable product, and struggling to balance new development projects against existing legacy code. In this instance, the situation has lead to a few critical people wearing multiple hats and juggling a lot of different responsibilities.

Since these resources are in such demand for a lot of competing things, there always seems to be a bottleneck around them. As one might imagine, the responsibilities that involve human interaction (managing people or supporting customers) take a higher priority than those that are more technology derived (like testing).

Some of the common problems that we’ve seen in this situaion include:

• The team has spent a significant amount of time refining and re-defining what the scope of a story is during the iteration.
• During the iteration planning the developers work with the customer proxies to define the stories and acceptance tests for them, but the tests are not always captured at this time.
• The tests are sometimes too narrowly defined or too broadly defined to be of any use in validating the code.
• There is often the desire to select stories to work on that have not been fully clarified. They are the highest priority, or are the next logical step, but during iteration planning some questions arise that need outside input. At these times, the notion is to work on what we know now and we’ll fill in the blanks before we run out of defined tasks. Usually the answer to the unknown things changes the ‘known’ items and leads to more questions. This cycle is repeated a few times before the dust settles.

Some of the smells associated with these problems are:

• Constantly adding tasks during the iteration to account for missed features
• Running out of tasks in the backlog mid-iteration because the features were misunderstood.
• Generating a lot of code inventory during the iteration because it is waiting on testing (developers saying that ‘I think it’s done, but it needs to be tested.’)
• Switching gears from implementing tasks to iteration planning (user story discussion and task breakdown) mid-iteration. This isn’t always bad. It just shouldn’t be the norm.

So what’s the proposed solution to these smells you ask? Inspect and adapt. We’ve been including the expert user in the iteration planning meetings and asking them to review the user story with the developers. This causes the developer to get into discussions with the customer proxy about the pros and cons of what is or isn’t included in the story. It causes overall confusion as to what needs to be tasked out, and can lead to a feeling of uncertainty about what needs to be implemented.  The focus of the iteration planning moves to architecture possibilities and eventually a ‘code speak’ between the developers about where we should go. To avoid this we’re going to try something new on the project that we’ve used successfully in the past with other Visionpace clients.

We’ll break the iteration down into to steps; iteration prep and iteration planning. The goal is to define what the user story is (and isn’t) in the iteration prep. The output from the iteration prep is a set of written acceptance tests and some low fidelity models of forms, reports, etc. for the user story. The tests are then used in the tasking portion of the iteration planning meeting to refine the scope of the conversations.  The features of the user story are described to the development team via the list of acceptance tests and the low fidelity mock ups are used to explain the tests. (Say it in tests!) Another benefit of this approach is that the acceptance tests are refined in the iteration planning and when the developer feels that they have implemented the feature, they have a series of tests to confirm their belief. Finally the tests from the iteration prep are either added to a manual test script or incorporated in an automated testing tool.

The takeaway for all of this is that the roles and responsibilities are leveraged in this situation to minimize chaos. The customer (or proxy), the scrum master, and other appropriate parties work to define what the user story is without worrying about underlying architecture or developer centric details. This definition is delivered to the developers in the form of low fidelity screen mock ups and documented acceptance tests, so they can focus on defining what they are being asked to implement.   

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.

Size, Layers and Intuition

As the holidays approach and the cold weather begins moving into Kansas City, it's a good time to reflect on our efforts and goals in the areas of custom software development and agile process coaching.

In the area of User Story Points estimation we made one seemingly subtle change in that we refer to the activity as "Sizing" a User Story rather than "Estimating". For us, it seemed to further focus the discussion on the size of a given User Story, especially when triangulating the story relative to other already-sized stories. This has been useful in a variety of ways, including helping move people past struggling to understand the concept of a story point.

We look at discussing and sizing a story in terms of the elements common to most stories (at least in terms of our software development) which tend to fall in the area of the classic three layers: UI, Business and Data layers. Traditionally, teams have relied mostly on free-form discussion and developer (sizer) intuition to determine point values and during triangulation. While we agree that expert developer opinion and intution is highly valuable, sessions can sometimes be prone to thrashing (excess discussion), fatigue and personality dominance.

When we conduct sizing (using the Planning Poker approach) sessions, we read a User Story card and then the customer answers questions from sizers (developers) until there are no more questions. This is fairly standard in most Planning Poker approaches. But instead of sizers flipping one card to reveal their overall size opinions, they use three cards. One for the UI layer, one for the business layer and one for the data layer. The idea is that since they are already thinking about the complexity and therefore the amount of work involved in implementing a user story and since they usually do this in terms of design,testing and development along the lines of the three classic layers of UI, business and data, we have them assign story layer point values (using the same point scale they would for overall story points) to generate discussion about differing opinions and to confirm assumptions even when their size opinions are similar the first time they flip their cards. In some cases, we'll even have the sizers shout out the objects (Forms, Reports, Classes, Controls, Tables, Stored Procs, Views, etc.) they had in mind across the layers and record those on the wall for a number of reasons, including for reminders of effort we already accounted for in sizing other stories. The resulting layer size opinions and object counts help with triangulation for an overall story size opinion. This is useful for current sizing sessions and for future triangulation as new stories are uncovered during subsequent iterations. The final consideration is developer (sizer) intuition. Even with object counts and layer assumptions in place, if the group feels that similar stories based on the above shouldn't share the same overall point assignment based on their gut that design, acceptance testing, etc. makes the story belong in another point column, then the story gets moved.

Doing the above does add some additional time to the sizing session but it also saves time by reducing thrashing and directing a portion of the discussion along the lines of the story layers. The net result is no more time is taken and a there is typically a higher degree of confidence in story sizes.

Agile Conditioning

Visionpace recently conducted another ScrumMaster Certification course and a few of our associates participated as well students from other organizations. (If you’re not familiar with the course check http://www.visionpace.com/developereducation.html.) The Visionpace folks have been engaged in agile development (XP and Scrum) for anywhere from one to three years as developers. This training allowed them to consider the agile development from the Scrum Master perspective. As such, it generated a lot of good conversation over some recent lunches.

One such topic that I think is universal to all learning, is that one can’t go to a training session and then expect to be fully proficient at the end of the training. Nor can one go to training and not use the skills presented in the training, and expect to retain them. In order to become proficient in a new skill set (be it a new language, new technology, new art form, or new project management approach) one has to continuously use, hone and train with the skill set.

This was the topic of conversation recently. It seems that a lot of people expect that if they send a person to a class and\or have them read a book that they will then be an expert in the topic overnight. (Does this sound familiar? “Jetson, we’ve been hearing a lot about agile development lately and figure if it can work at Chrysler it can work at ACME Sprockets. Attend this three day seminar next week and be ready to tell the Board what we need to do when you get back.”) It’s not unlike your boss telling you to go home over the weekend and read a white paper about swimming and spend a day or two at the pool swimming laps because you’re going to be the captain of the new company swim team. In order to be proficient at anything, you have to train. You have to condition yourself for the skill and continually build on it.

At Visionpace we strongly believe in the phrase ‘Inspect and adapt’ as part of this continual conditioning. Collectively and individually we look at our project and the associated process to see what we’re doing well and what we need to address. We have regular reviews and sessions to help each other get better at being more productive team members.  This is good because it allows us to review and reinforce our actions and processes. Over time we find the results continually improve and as one would expect proficiency increases. A simple concept, that often time is overlooked in organizations.

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.   

Agile 2006 Initial Thoughts

I’ve always enjoyed those moments when you realize “Wow, why didn’t I do this sooner?!” These moments are usually accompanied by the feeling that you’ve found something that will help you to do things a lot easier or more effectively in the future. This was my initial reaction to my attending Agile 2006 in

Minneapolis.

The conference is well attended (a little over 1100 at current count.) The attendees, based on the limited sampling of my conversations, come from all backgrounds and organizations. Developers, managers, owners and testers are represented. As a case in point, at lunch I sat between an instructor from a university in Haifa, Israel that uses an agile approach in teaching and a manager for an organization in Orlando that helps document living languages that a currently not documented; projects with about a 35 year life cycle.

If you are a student of the game, and always looking at ways to get better at what you do, then I highly recommend attending these events on at least a semi-regular basis. It’s hard to tell what will happen when the conference attendance grows to thousands (in about two years based on past growth.) I doubt it will be the intimate gathering that some current attendees describe when talking about previous conferences. But it is agile, it will scale and it will adapt.

It’s cool when a client inherently understands an agile practice and uses it in ways you hadn’t thought of.

Visionpace is working with a client that I was previously employed with a couple of years back. They need some clarity on the size of their project and want to make sure that their developers are focused as much as possible on the new development, and minimizing changes to the current application.

Since their environment was already quasi-agile, it was pretty straightforward for them to understand the benefits of putting enough process in place to help achieve the goals they wanted while not taking away from the communication and model storming that had always worked well for them. We conducted a user story session and had a Visionpace resource lead a beachhead iteration, and then walked them through the iteration planning and user story tasking. Once we tasked out the user stories we discussed the layout of the task board and how the tasks progress across the board during the iteration. The agreed that creating the board was something that they could do and I told them I’d stop back later in the week to check in.

This company’s war room is located in an office that was converted to a conference room. They have a large table, some comfortable chairs and even a video gamming system for stress relief. The war room also has a large window that looks out into the main office and developer cubicles. This detail is important for two reasons. By making this conference room the war room, the importance of the work at hand and the overall health of the project was easily visible to everyone in the office, and it overshadowed the niceties of things like the video gaming system.

This window also provided another benefit for the project. One of the principles of the company directed that the window be used for the iteration task board. So the columns for the task board were written on the glass. His logic was that he really didn’t need to know what the tasks were related to a user story. What really matters to him is are the tasks being implemented on a regular basis, and is the iteration on track. By putting the tasks on the window using sticky notes, he could look at the window and see where the groupings were at any pointing the iteration (e.g. mostly in the backlog a the beginning of the iteration, spread out midway through, and in the tested column towards the end of the iteration.) 

I thought it was a brilliant idea: Easy to do, easy to understand, easy to implement and effective.

Game Software Development Becomes Agile

Here's an interesting look at the Agile Process in the context of game software design and development. Rory McGuire explores some of the difference between the "traditional" Waterfall method and the Scrum method of building software. He goes into some depth in terms of the advantages of Agile vs Waterfall and how it is or may become a strategic advantage for those game companies who exploit its benefits. Read it  here: http://www.gamasutra.com/features/20060628/mcguire_01.shtml 

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?

Some common pitfalls on the road to being agile

Through our business endeavors at Visionpace and conversations at the Agile KC group, it’s pretty common that I hear of another company ‘going agile’. The term ‘going agile’ could mean a lot of things, but in general usually boils down to the fundamental belief the company in question has some problems/pains with their current development process, and have heard some good things form other organizations that have successfully implemented some sort of SCRUM or XP process. They figure that if it works for Company B, it will work for us. The success of this transition, and the effectiveness of the resulting process, depends heavily on a lot of factors like the company culture, the people involved and the project in question. Unfortunately, when I follow up to these conversations after a short time, I often hear about the failed attempts and misguided efforts and abandonment of the pursuit. It’s not that agile development doesn’t work. The problems that companies encounter most of the time when undertaking an agile approach are related to lack of planning, communication and expectations.

I bring this up, because I heard of another company ‘going agile’ recently. I wish them well. I wasn’t able to ask find out some specific information like who they have involved in the process, what they are doing, what their goals are, the scope of the project, etc. From what I gathered it’s a small team working within an organization that may or may not continue pursuing agile depending on the results of this project. It’s a good business move, to test the waters before you commit the ship. But like any R&D project, there are a lot of ways to fail. So I thought I’d share some of the common pitfalls I’ve seen in the past with the initial implementation of one or more agile practices in a more heavyweight environment.

Some pitfalls, and ways to avoid them are:

The organization does not commit enough people to the process, or does not commit the right people to the process.

• There is a misconception that since agile is lightweight, it can be done successfully with just one or two people. While technically it can, a small group often lacks the different perspectives that help define user stories, tests and an overview of the entire process effectively.
• Another common misconception is that developer A knows the most about the business processes, so he/she should be the one working on the project. The risk is that developer A is not suited to working in an agile environment that is going to be in flux. There will also be a lot of other pressures on the team as they work to get the project going. Being a business expert is good, but being more geared to working closely with the rest of the team is more important.

        The best way to mitigate this is to have some goals specified (more on that later) and review how the members of the team individually and collectively are suited for achieving those goals. Also consider what skills and expertise the team is lacking and either get those skills or bring in someone to coach the team until they acquire them. In the past, Visionpace has successfully worked with companies through first three or four iterations, at which time the process was understood well enough by the team that we scaled back our involvement. Another aspect to consider is making sure that the people on the team are motivated. The risk is that you’re changing the way people work and the tendency over time is for them to go back to what they know. A motivated individual, or better yet a motivated team, can help keep the process moving forward.

A second pitfall is that the organization thinks that by using agile, they don’t have to do a lot of up front planning and design, and interpret that to mean that they don’t have to have a plan for how the process will work.

• Often times there’s one or two individuals that have some experience with or knowledge about agile development, and the assumption is that they will be able to implement the process.

• The problems arise when the team starts struggling to define/refine the process along the way (during the iterations when they should be working on code) vs. having an understanding of how the process will work at the beginning of the project and incremental reviews at specific times throughout the project. (Have a plan for how it will work, and set up times       throughout the project for reviewing and adjusting the plan.)

• Other times, an organization will try to stretch too far and incorporate too many agile practices too soon. Sometimes it’s better to include a couple of practices and get them established and then add a few more each iteration.

        To avoid this lack of process understanding pitfall, make sure the team knows how the process will work for this project and how the process will be inspected and adapted throughout the project. Remember, the goal of an agile process is to develop working software in a predictable and efficient basis. A secondary goal of the organization in these instances is to define an agile process that carried beyond the current project. Plan time to review and work on both goals, so they don’t compete with each other.

A third pitfall when starting to implement an agile process for the first time, or even the hundred and fist time is not having  realistic expectations.

• The success stories that are touted by the agile community are real, but they weren’t achieved overnight.

• Just like learning how to become a good .Net developer takes time and experience, so does learning to work in an agile environment.

• The results when implementing agile are not black and white, but rather seen in shades of grey. Small, repeated increases in productivity and code quality add up over time.

        The easiest way to avoid this goes back to planning and reviewing the process regularly. If the organization understands what the problems they are working to resolve are, and how an agile approach is going to resolve them, it make for a clearer conversation about when the results will be realized.  Clear goals are also essential in setting expectations.

A fourth pitfall is the organization not being flexible enough in it’s incorporation of the process.

• One of the underlying aspects of agile development is to inspect and adapt. A company that looks to have the process defined and documented at the beginning of a project and not subject to change over the project life cycle is going to have a harder time with the ‘adapt’ part.
• Additionally the process may require resources that were not considered initially.

As a rule of thumb people change, markets change, businesses change, requirements change; so don’t expect the process to be static. It’s a good idea to review the changes to the process, and if it helps, keep that static, but the process must be allowed to adapt to the environment. Also, remember that a different project in the same organization may require some changes to the process.  The team has to be given time to fail, review, regroup, recover and move on. They don’t have to be given carte blanche authority, but they have to be able to commit to the goals and in control of the process enough to support that commitment.

.NET Test Driven Development Workshop in Kansas City

Test Driven Evangelist and Agile Coach, Jim Erwin,  will be delivering .NET Test Driven Development (TDD) workshops for Refactoring, Unit and Acceptance Testing in Kansas City on November 8th  - 10th. Jim is an active presenter on topics including .NET and Test-Driven Development.  He has also lead a VFP community effort for Test-Driven Development in VFP known as FoxUnit (http://www.foxunit.org).  He can be reached at jerwin@visionpace.com.

Test Driven Development is a vital component of any agile process and is a development approach that is effective for any development group or organization.

For more information visit http://www.visionpace.com/developereducation.html or call 816-350-7900 or 1-888-904-7900

ScrumMaster Certification in Kansas City

Lowell Lindstrom, agile author, speaker and coach, will be in Kansas City on Wednesday, October 11th and Thursday, October 12th to deliver the two-day ScrumMaster Certification course. Lowell is one of a limited number of people in the world certified to teach this course and Kansas City is one of a limited number of cities worldwide hosting this training in 2006.

No matter what agile process you're adopting or developing, Certified ScrumMaster training will provide you with fundamental insights into core practices of agile software development and agile project management.

For more information visit http://www.visionpace.com/developereducation.html or call 816-350-7900 or 1-888-904-7900

Beyond the standing meeting

I recently posted a blog with some thoughts about standing meetings so I thought I’d post some thoughts on another regular meeting we conduct at Visionpace. The goal of this meeting is twofold: to keep the company higher ups appraised of the status of  projects that we’re working on and allow us the ability to continuously ‘inspect and adapt’. I refer to this meeting as the PRM (Project Review Meeting, catchy huh?)

This meeting occurs weekly and includes Russ Swall (owner) and Doug Bliss (COO) and me. In the meeting we review all the projects that are in process or on the horizon. The amount of discussion about each project depends on aspects of the project (size, complexity, resources involved, customer requirements, etc.) We review the projects in alphabetical order of the last name of the developer involved with the project (seems to be as good as any other order) in order to make sure we cover all projects. Some of the information that we review include the projects’ velocity and burn down reports, any potential risks or issues that might need to be addressed in the project. If necessary, we’ll either determine a course of action or set a follow up date and time where we’ll continue the discussion.

The format for this meeting is fairly open. We don’t have minutes though each of us takes notes on items we need to do as a result of the meeting. We also don’t have a set time limit on the meetings. They usually run an hour or two. From a project management perspective, the real benefit of these meetings is that as I describe an issue or facet of a project, Doug and Russ can weigh in with a broader view of the subject, or identify a potential issue that the team might not be addressing. This provides a safety net of sorts, in that during the iterations we can focus on the work at hand by following our process, as well as keep an eye out for potential problems. We’re also able to separately step back from the projects and tweak the process.

The fundamental tone of the meeting is one of trust and respect, so I don’t feel pressured to try to defend my actions or protect my job. Rather I have the opportunity to openly and honestly discuss the projects, any thoughts or ideas that I have about the projects or the company in general, and any areas that I need help. Doug and Russ are also free to ask questions and make observations without concern that it might be misunderstood as a personal critique. This leads to two specific benefits for the company. First, the things that we are doing right can be leveraged even more because we discuss what, how and why as well as what’s next. Secondly, areas that need more focus are identified and the risks/issues are addressed fully and a plan to address the issues is determined.

Some of the key elements to the success of these meetings:

- Trust. All the participants understand that everyone’s motivation is to our customers, and in turn to Visionpace.  The conversations are never a personal attack. When Doug says something like, “Martin you need to focus on…” he’s not commenting on my abilities. Rather he’s identifying an aspect of my role and responsibilities that need attention.

- Focus. The meeting is to discuss ‘this piece of work, involving this group of people, in this environment, right now and right here.’

- Candor. Things that need to be said are said.

- Regularity. We have the meetings weekly allowing for a continual review and adaptation of our processes.

- Multiple perspectives. Both the long term strategy and short term actions can be discussed to make sure they are compatible.

- Shared commitment to our clients. I don’t have to be the one to come up with a solution or action to manage every facet of a project. I can rely on others in the company to help me, and help keep me growing.

Conducting a regularly scheduled, honest review meeting will not guarantee success for an organization in itself, but it goes a long way toward keeping the organization on the right track and continuously improving. If you’d like to learn more about this type of meeting and how to start doing this in your organization, please feel free to contact Visionpace.

In support of Big Visible Charts

If you’re not familiar with the concept of displaying critical project information in a very direct and low tech way, I recommend you do some reading on big visible charts. Ron Jefferies has an excellent write up on this at http://www.xprogramming.com/xpmag/BigVisibleCharts.htm.  I bring this up because we recently had a reaffirmation the benefit of big visible charts during an iteration review meeting for one of our .Net projects. During the iterations for this project we are tracking the iteration burn down in hours on a large sheet of paper posted in the war room. In this instance, a situation occurred that required us to task out user stories twice during the two week iteration. (We tasked out a week’s worth of stories at the beginning and the middle of the iteration.) As part of the daily stand up meeting, we update the iteration burn down with the hours remaining for all the tasks. This reflects tasks in the back log and tasks in process. It would go up and down as we reassessed the work remaining on tasks in process and, new tasks missed during the task break down, tasks implemented, etc.

The benefit of having this chart was that during the iteration review, when we discussed velocity and ways to increase the velocity, the developers got up and walked over to the burn down and began to discuss the changing slopes; when it dropped the steepest, when we tasked out new stories mid-iteration, when it wasn’t as steep a drop, etc. This conversation lead to two distinct behaviors that we’ll adapt on future iterations, to help maximize the iteration burn down and thus overall velocity. We might have determined to adapt these behaviors without the presence of the iteration burn down, but the amount of effort to create and update the chart is negligible and it provides a direct sight to what’s important to any project, progress. The best thing about it was that the developers had the discussion without any direction from management and determined the behaviors to adapt. This means that the behaviors are easier to implement and follow.

If you're interested in the behaviors we're adapting, email me at: molson@visionpace.com

Tasking User Stories

At a recent Agile group meeting in Kansas City, the discussion of tasking user stories came up. In principle it simple enough, have the team break a user story into tasks at the beginning of an iteration and then use the tasks to plan the work and track the progress through the iteration. In practice it’s a little more complicated than it appears on the surface.

There are a number of things to consider when tasking the stories: capturing all of the tasks associated with the story, having all of the team member involved with the tasking vs. only the one or two members of the team are planning on working on the story, making sure the tasks are granular enough so they can be forecast, but broad enough to allow for just in time discussions.  It takes a lot of energy to focus on defining two weeks worth of tasks for multiple developers. What follows is a list of some of the do’s and don’ts Visionpace has found while working on our projects.

Things to do:

-         Task the stories one at a time, and have all members of the team participate on the breakdown of the tasks. If one or two members are disengaged have them write the tasks to bring them back into the discussion.

-         Have the members of the development team, the ones that will implement the tasks write the tasks vs. having a non-developer write the tasks. These cards are for the developers and can have lingo or acronyms that might get lost in translation.

-         Use free form design and light weight modeling to describe the story and lay out the tasks. 

-         Have a facilitator that keeps the discussion moving. There needs to be some architecture discussion here, but it shouldn’t be too detailed. As noted above, effective tasking takes skill and effort.

-         During the iteration, if new tasks are constantly being discovered, go ahead and re-task the remaining story.

-         Use an iteration burn down chart to track estimated hours of work remaining for the iteration. Update it ever day after the standing meeting.

-         Have a standing meeting ever day based on the tasks.  This leverages the tracking benefit of breaking the stories into tasks.

-         Make sure the effectiveness of the tasking is a discussion point during the iteration meeting.

-         Have a list of common tasks listed in the war room to help facilitate the discussion. Also update the list of common tasks specific to the project at hand.

Things to avoid:

-         Don’t fall for the logic of, “That story involves XYZ logic and Jane is the only who can crank that out, so she should task it”. You’re giving code ownership to one person vs. having the team own it. In this instance challenge the team to task the story without Jane (Take away the crutch they used and force them to take a step or two.)

-         Don’t add tasks piecemeal through out the iteration. If there are one or two things that were missed, don’t sweat it. If there is more to it, stop and capture all of them at one meeting. 

-         Get too comfortable with the members of the team saying, “I worked on such and such. We don’t have a task for it and don’t need one because it was a one time thing.”  If it’s important enough to work on, it’s important enough to write a task card for.

-         Don’t expect to master this aspect of agile development over night. Inspect and adapt this as with everything in an agile project. Have open and direct conversations about what’s working and what’s not.

I’ll update this list periodically, or perhaps another member of the Visionpace team will.  Just remember that tasking is a critical component of agile planning and tracking and like everything else with agile development, it’s a skill that has to be honed for all members of the team.

Thoughts or comments?  Please let me know Molson@visionpace.com

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.

What do you think ... can Six Sigma fix bad management?

From the Agile Management Blog:

The speaker Greg Boal of ServiceMaster has just suggested that Six Sigma won't fix bad management. It will fix a lot of bad shopfloor and service delivery problems but bad management is not something it addresses. At first this seemed a profound observation that ought to be common sense but on reflection after a few minutes, this seems a curious observation.

Not having much experience with Six Sigma except for hearing my production colleagues while in Pharma talking about implementing it, what do you think ... Can Six Sigma fix management problems?  My guess is no.  If you're a lousy manager, no business process improvement can fix that.

Tags: Six Sigma, ERP, BPM

Once in an Agile Lifetime (apologies to the Talking Heads)

Being a Talking Heads fan, I can't in good conscience reprint this Agile-inspired parody.  However ... it was funny.  Okay not as funny as Programming Truth and Fiction, but still funny ... OnceinaLifetime

Tags: Agile, Talking Heads

Scrum plugin for Visual Studio

Via Chris Breisch's blog and scrum plugin for Visual Studio (in beta). And you might like to check out the main blog ... because I saw the magic words "scrum" and "podcast"  looks interesting to me.

Tags: Agile, Visual Studio, Scrum

New Agile software from Rally

New software for life cycle management for Agile teams ...

Rally Software Launches New Team and Pro Editions for Agile Software Life Cycle Management

Rally Addresses the Exact Needs of Both Small Projects and Distributed, Multi-Team Programs

BOULDER, Colo., Feb. 13 /PRNewswire/ -- Rally Software Development Corp., the leading on-demand provider of Agile software life cycle management solutions, today announced the availability of Rally Agile Team and Rally Agile Pro, two distinct editions that give software development teams the visibility and collaboration needed to deliver high-value software in short, rapid iterations. The new offerings continue the advancement of Rally's on-demand applications for helping software-driven organizations formalize, manage and scale Agile development practices -- one of the fastest growing trends in the software industry.
From Mobius Ventures

Tags: Agile Methodology, Rally Software