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

It’s never too late to go more agile.

Last week I met with Bill, a Visionpace associate, at the client’s location to go over the user story list and start tracking one week iterations. This fact that I met with Bill isn’t ground shaking but the reason for the meeting is blog worthy.  At least I think so. Bill has been successfully working with this client for the better part of two years without formally planning iterations.  So what prompted us to start formally tracking user stories, iterations and burn down? Put simply, we need the information that the Perfect Vision process provides.

Let me take a step back and provide some insight on the project. Bill has been working on the client developing a solution for working with insurance claims. They have been defining the work with user stories and using roughly defined iterations (not a specific duration, but defining work for a week or so based on the stories and their priorities.)  Visionpace has a couple of clients that this approach works for.  It takes a lot of participation and communication between the developer and the end user, and it doesn’t hurt that Bill, like the other Visionpace resources, is a very capable business analyst, developer and software architect.   When Bill has any questions or wants to bounce some ideas of another developer, he’ll contact me to see who’s available, or will email the Visionpace group at large.   

I can hear you ask, if this has been working well for the client for the past two years, why modify the process now?  We’re getting near the end of the story list and both the client and Visionpace want to make the transition smooth for everyone involved.  By establishing a consistent iteration length and forecasting the user stories, we can track the number of points implemented during each iteration and determine the velocity.  With the velocity we can project  when we think we’ll implement all the stories.  In the meantime, we can leverage the protocol that already exists and if a new story is discovered, it can be added to the back log.  This is just an example of how a little change in the development process can bring a controlled wrap up to a project.

The upside to all this is that we can continue to use what works for this environment and project, and introduce enough process to address the changes in the environment without missing a beat.  Hence the thought, “It’s never too late to go more agile.”

Everybody’s project is big.

The other day, Russ and I were on site with a potential client and they made the comment, “Our project probably isn’t that big for your company, compared to other projects you do.”  Since this was our first meeting with the client, we had no idea as to how large the project was.  More importantly though, as Russ was pretty quick to point out, the project is critical to the client, and thus was critical to Visionpace.  The relative size of one project compared to another isn’t relevant to how we approach the project.

The size of the project has bearing on the number of resources involved and/or the length of time that the project takes, and thus overall cost, but all of Visionpace’s projects follow the same overall agile process. We conduct a user story session with the customer to discover the overall features of the project and then forecast and prioritize the stories to determine an initial release plan. Then we begin working on the user stories in priority order per the customer.  At the end of the iteration we review the remaining stories, remove any old ones and add any new ones. Then we review the priority, select the stories for the next iteration and begin the process again.  (It’s important to note, that this isn’t a magic ‘one size fit’s all process.’ Each project is unique, and the process has to be adapted somewhat for each project. The underlying actions remain consistent from project to project.)

This is a pretty high level over view of the process.  If the project is requires more resources, we schedule more resources to meet the desired velocity. If the project doesn’t need as many developers, we schedule for that accordingly too.  Of course with more resources working on a project, the customer has to also allocate more time for feedback, discussion and review throughout the iteration, and we help manage this too.

The customer benefits from this approach because a project that is forecast to take two developers three weeks gets the same level of expertise and attention that a project that is expected to take a team of six, one year to implement.  Conversely, the process that is honed in working with a client to implement certain features in a short time frame is also used in a large project to keep the focus on delivering working software and value to the customer on regular basis. 

Over the years doing software development in Kansas City, we have developed an environment where everyone must always continue to learn and grow. We have an obligation to our clients and each other to continually strive to be better at what we do and how we do it.  This goes hand in hand with our Perfect Vision process, because we’re able to inspect and adapt our process and benefit our clients, regardless of "how big" their project is.