Agile Management | NOOP.NL

How to Handle Multiple Customers

Some time ago I wrote a blog post on how to do resource planning when you’re dealing with multiple small projects. It seems to be a tough problem, as I noticed many people are struggling with it.

To cope with such a situation, some experts will tell you that you should try and prevent working on multiple projects. Unfortunately, for people working on small projects, such advice is both true and useless at the same time, as many of us are not in a position to tell customer A that he should stop bothering you until you’ve finished the work for customer B. Optimizing just one customer’s happiness will get you out of business in no-time!

The solution is to make all customers just a little bit happier.

The only way to deal with this multi-tasking problem is to applying rigorous discipline to your weekly schedule. You must make it clear (to yourself and to your customers) how much time you can make available for which projects. Not doing so results in overcommitment to one (spoiled) customer, while the other customers suffer from neglect.

Here I give you an example, showing you how to handle scheduling with multiple customers. It might be a bit extreme, but it reflects the most common situations I have encountered in our own organization:

<ExtremeExample>

Suppose you are working on some big project (A) that requires as much attention as you can afford. How much time do you think you will have available in a period of four weeks? 160 hours? 120 hours? 100 hours? What will you say when the ScrumMaster asks you how much work you can do in the next sprint? If you do not carefully schedule all your other responsibilities, you could think that you have 160 hours available in four weeks.

 

Figure 1: four full weeks allocated to one big project

However, you might recently have worked on another big project (B). If you’re a bit like me, the product you delivered will still have a (small) number of bugs, flaws and other problems that need to be resolved right after the first release. In our organization we call this the “aftercare” phase, which is like a warranty on our products. The customer is entitled to have all problems fixed that are discovered within a few weeks after a product’s first release. You have to reserve some time in your schedule to take care of the aftercare phase.

 

Figure 2: warranty period for B takes some hours away from A

You may also have contributed to some older projects. It is said that good products require more maintenance, because users often request more improvements in products that they really like. Those earlier customers, the ones you helped by giving them some really stunning products, will keep asking you to add and change features. Provided these customers have some sort of maintenance contract, the time required for maintenance has to be schedule separately. In our organization we call these days “issue days”.

Figure 3: maintenance work takes some more hours away

If you’re lucky (given the current financial crisis) you will have customers asking you to do some new work that doesn’t fit into regular maintenance work. Of course, you already know you should try and do only one project at a time. So you tell those customers to wait until project A is finished. However, if the amount of work is small, your customer will find it very hard to swallow that he has to wait another three months for project A to finish. “It’s only 3 days of work! Why do I have to wait for 3 months? Surely you can squeeze this in between?” That’s why we decided to introduce “RfC weeks”, where an RfC stands for a Request for Change. It is one week per month reserved for relatively small jobs on existing products, whatever work that turns out to be. (And if no small jobs turn up, we just continue working on project A.)

Figure 4: one week reserved for tiny projects

Is that everything that you need to think of? Hell, no! What about your own personal development? When will you have time to experiment with new technologies? When will you have time to read a book, or the complete archive of your favorite blog (NOOP.NL)? If your organization is serious about your personal development, you will be allowed some time to read, experiment, and learn. In our organization we call these our “academy days”, and they need to be scheduled separately.

Figure 5: one day of personal development per month

That was all, right? Well, maybe. Maybe not. It depends on any other responsibilities still left unattended. Are you required to coach some junior software developers? Are you expected to attend several meetings per week? Are you involved in job interviews, or fixed price estimations? Do you do consultancy work for new customers? Do you prepare technical architectures for new projects? You will have to account for those activities as well.

Figure 6: various activities of one hour per day on average

As you can see in the last picture, the actual time you have available to work on project A has shrunk to almost one third of the month. Sure, your own situation may not be as extreme as in this example, and the exact numbers of hours will vary per person, but I would advise you to do the sums yourself. And don’t do this scheduling in your head! At the start of the month, when you plan your work for project A, you have to know how much time you have available. If you’re only doing a quick mental assessment of your responsibilities, you will always end up overpromising what you can do for project A.

</ExtremeExample>

(If you’re lucky, and your organization understands the importance of resource scheduling, you will have a resource manager or project manager doing all this work for you. Still, you might want to check if she has thought of everything. In dynamic organizations (like mine), where hundreds of customers and projects are battling over the availability of human resources, keeping track of people’s multiple responsibilities can be very hard. But if you apply some discipline to your schedule, you should be able to handle the most common resource allocation problems.)

Balancing work for multiple customers is a tough problem. You will have optimal results by optimizing resource allocation in such a way that all customers are just a little bit happy. And it is true that you should minimize the amount of task-switching between projects. If you can consolidate all maintenance work in one week per month, instead of one day per week, then do it! Likewise, aftercare in 2,5 days of 8 hours would be much better than 10 days of 2 hours. I’m sure you get the picture.

But whatever you do, it doesn’t change the amount of time that remains for customer A, which could be a lot less than you thought. It’s best the customer knows that before you start, don’t you think?

Subscribe to this blog with a reader or by email!

Latest, greatest and favoritest posts:
How to Do Many Projects (Part 3):  Maintenance
How to Do Many Projects (Part 2): Matrix Management
How to Do Many Projects with Few People (Part 1)

Time Sheets: Squashed Between Jeff Sutherland and Joel Spolsky

Last week I got this message from Rebekah:

Jurgen,

I've been following your blog and really enjoy it.  I work for a small web development firm that has grown a good bit over the last few years.  We've recently transitioned from charging hourly rates to fixed-price projects.  Because we once billed by the hour, we're still recording all of our time.  We'd like to get away from this, but aren't sure how to proceed.

I'm curious how your teams handle this.  Do team members record time per task? Do they record their time at all?  If not, how do you measure profitability on a project?

Yes, we record time per project for every team member. This is indeed essential for measuring profitability per project. Of course, there are some people, like Jeff Sutherland, who think that time sheets are among the greatest evils, right in line with task-switching, big-upfront-design, and Windows Vista. However, such people usually have the luxury of working on only one project for a considerable length of time. And I envy them, despite their apparent ignorance of how other organizations need to do their business. Because, as in our case, when you're paid by different customers to work on several "projects" in a span of just a few weeks, then yes, time sheets are essential! (How else are we supposed to know whose heels to lick, and which projects to throw out?) Of course, it's also possible that Jeff is so amazingly rich that he doesn't care about the profitability of his projects.

However, I do agree that tracking time per task within one project is not needed. The customer is not interested in those details, and neither are we, since they are fixed price projects anyway. In this I disagree with Joel Spolsky's take on tracking time, as I believe tracking time on a task level can never be made a) reliable; b) profitable; or c) enjoyable.

If you don't schedule someone a certain number of tasks (with a certain number of hours) how do you know if they're overbooked?

In Scrum, a team estimates the tasks for the next sprint in the sprint planning meeting. The ScrumMaster knows for how long the team has been allocated to this project, with issue days, academy days, holidays, quality days, sick days, and baby days deducted from the week. In the rare case that there's still some actual productivity time left, the team then estimates how much work they can do, according to their (historical) average velocity (the amount of estimated work they finished in the previous sprints).

The whole point here is that the actual unit of estimation doesn't matter, as long as it's constant throughout the project. They can use ideal hours, but they can just as well use story points, oranges, toilet visits or CPU cycles. (In fact, some people suggest using Fibonacci numbers, which is even more ridiculous, as nobody can tell what those numbers are.) The actual time the team spends on tasks is irrelevant. Yes, Joel Spolsky thinks it's important, because historical data can improve the quality of new estimates. But I suspect this has more to do with memory faults among Joel's own team members. After all, when real hours differ significantly from people's estimates, our team members usually know and remember that. They talk about it every day in their stand-ups! Of course, people's memories are never precise, but neither are the estimates. I don't believe there's a need to adopt a bureaucratic process of documenting all deviations.

So yes, you must track time in order to track project profitability.

And no, you should not track time in order to improve task estimability.

And with this opinion it seems I'm squashed right between heavyweights Jeff Sutherland and Joel Spolsky. And I haven't met either of these guys, so I don't know if that's a comfortable position to be in.

Thanks for your time.

Rebekah

No problem, and thanks for your email!

(picture by michel filion)

Subscribe to this blog with a reader or by email!

Latest, greatest and favoritest posts:
How to Do Many Projects (Part 4): Resource Planning
How to Do Many Projects (Part 3): Maintenance
How to Do Many Projects (Part 2): Matrix Management
How to Do Many Projects with Few People (Part 1)

How to Do Many Projects (Part 4): Resource Planning

In three earlier blog posts I talked about multi-functional teams, matrix management and maintenance. In my maintenance article I argued that maintenance work on an application should be done by the developers who were responsible for building it. However, I also pointed out that this introduces some additional resource planning problems...

When software developers are responsible for multiple projects, you always end up with complications in resource planning. This is not just the case when you let developers perform maintenance on previous projects. Similar problems arise when they are required to do some other activities, like spending time on consultancy or estimations for projects that haven't yet been signed into contracts. Likewise, believe it or not, many developers actually need regular training, or they like to do some quality/infrastructure stuff for the organisation itself.

Therefore, maintenance work on old projects is a challenge, but it's just one of many types of work that can take people's attention away from their current projects. This requires a professional approach to resource planning...

I think there are 3 principles for resource planning:

1. For every type of work a specific number of days per month must be allocated (by a resource planner) in people's calendars;
2. Different people can be made responsible for the allocated timeslots by managing the work that is carried out in those periods;
3. Considering that task-switching is bad, the resource planner must seek to minimize the number of different activities per week, per person. (for example: allocating one week to activity A and one week to activity B is much better than swapping both activities every day)

This is how we have implemented these principles in our company:

• We maintain a 1-on-1 relationship between project managers and teams. This means that our project managers can do the resource planning for the members in their (multi-functional) team.
• The project managers are, of course, responsible for managing the projects in their teams. In these cases they act as ScrumMasters, as all our projects are using Scrum. These projects typically cover about 75% of our people's agenda's. There can be multiple projects going on in one team, but any conflicts of interest are taken care of by the project manager, as he is (by definition) responsible for all of them.
• Team members stick to their own teams. We don't continuously reassign people across teams. (And if someone tries again, I'll kill him.)
• Every month, a specific number of days are reserved for maintenance work. We call them issue days. The number of issue days needed is estimated from our maintenance contracts. Management of maintenance issues is done by service managers, not our project/resource managers. Explicitly allocating time for maintenance work in people's agendas has been a big help in improving both our service levels and the reliability of our project estimates.
• Every week a number of hours are set aside for doing estimations (for fixed price projects) and consultancy work by some of our lead developers. This pipeline of work is managed by someone who is neither a project manager nor a service manager.
• Software developers themselves are allowed to reserve a number of academy days. These are days for self-development and training. It works similar to requesting time off for vacations. As long as people request these days well in advance, this should usually not be a problem. The things our people do and learn on those academy days are monitored by their own functional managers.
• Last but not least, I am now considering the introduction of quality days. These should be days where software developers work on improving our own tools, techniques and processes, in ways that cannot be directly translated to billable hours in our projects. As a quality manager I would personally be responsible for the way those days are spent by our people.

Resource planning is not difficult. It just requires some discipline to do it right.

People should be able to trust that their resource manager has thought long and hard on how they must distribute their valuable time over multiple activities. And they should always know which other managers they must turn to for the details of the work in those allocated timeslots. And when the resource managers make sure that there's only a minor level of task-switching, then it's entirely possible to have a small number of people working on a large number of different projects and activities.

Subscribe to this blog with a reader or by email!

Latest, greatest and favoritest posts:
How to Do Many Projects (Part 3):  Maintenance
How to Do Many Projects (Part 2): Matrix Management
How to Do Many Projects with Few People (Part 1)

How to Do Many Projects (Part 3): Maintenance

In two earlier blog posts I described how we have organized the software development efforts in our company. I wrote about cross-functional teams and matrix management.

This time, I'd like to talk about software maintenance.

I have recognized two lines of thought regarding maintenance:

1. Software maintenance should be separated from new software development. This means that, when a software development team considers a project finished, it is handed over to a maintenance team.
2. There's no clear difference between software maintenance and software development. A team should perform both new development and maintenance.

Personally, I lean towards option 2. And these are my reasons:

• With agile software development, the difference between development and maintenance has blurred. In each sprint there's a bunch of stuff to do (add new features, handle some bug reports), and then release a new version that may or may not be used by the customer. Do we consider these sprints software development or software maintenance? Or maybe both?
• No software developer likes maintenance. (OK, maybe some of them do, but I don't know many.) They all want to build new applications with brand new architectures and technologies. Adding features to a legacy system is no fun at all.
• When another team takes over the maintenance part of an application, you run the risk that the software development team leaves some thorny maintainability issues to be solved by the maintenance team. After all, if you won't be responsible for maintenance yourself, why should you invest in making that part easier?
• Finally, in his book Facts and Fallacies of Software Engineering, Robert L. Glass pointed out that software maintenance is harder than new software development. (I blogged about that in "The Craft of Maintenance".) Some employees have suggested to me that we should assign our best developers to new projects, while making some juniors and interns responsible for maintenance, so that they could "learn how our applications are built". (It's no surprise that this suggestion usually comes from experienced developers with an obvious dislike for maintenance.)

So you see... these are the reasons why I am not in favor of separating software development from software maintenance. Except for the size of the work, I don't see much difference between them. And I believe it's a good thing that software developers share responsibilities in doing maintenance on their own applications (and making sure that they are maintainable at all). And given the complexity of maintenance work, it is good always to have the senior developers involved.

Of course, if you have people responsible for both development of new projects and maintenance of old projects, you run into some interesting resource planning issues...

to be continued...

Subscribe to this blog with a reader or by email!

Latest, greatest and favoritest posts:
How to Do Many Projects (Part 2): Matrix Management
How to Do Many Projects with Few People (Part 1)
How to Handle Many Simultaneous Projects

How to Do Many Projects (Part 2): Matrix Management

In How to Do Many Projects (Part 1) I explained that it is good to have multi-functional teams, where each team includes a project manager. Here is part 2, which is about the merits of matrix management...

Functional Managers
As in every other organization, in our company each employee has a (functional) manager. I prefer management to be arranged along functional lines. Therefore, a project manager has a manager who knows a lot about project management. A front-end developer has a manager who is herself fluent in CSS and HTML. And our software developers have development managers who are proficient at building code, delivering solutions and making nerdy jokes that no ordinary person understands.

I believe it is imperative that managers understand the work their employees do. There's little reason for software developers to work with a manager who cannot distinguish a bit from a byte. (I have blogged earlier about how to select a fine technical manager.) Similarly, project managers should be led by someone who understands agile principles, Scrum practices, and how to turn Notepad into a planning tool.

Important: a manager does not have to be better than the sum of his subordinates. It is only natural for his senior employees to exceed the manager's knowledge and expertise at some point, because management requires other (soft) skills, some of which the seniors might be lacking. However, the manager should be good enough to earn trust and respect, and to be able to coach and lead.

Note: For historical reasons our Development Managers are situated in the same teams as their own subordinates. This means there's a Development Manager available in each of our development teams. This works fine for now, but might be changed someday, as there is no practical need for it.

Matrix Management
It will be clear to some readers that we have organized ourselves as a matrix organization. Our project managers are primarily responsible for projects and the (short-term) goals of customers, while functional managers provide expertise and coaching. They deal with the (long-term) goals of our people.

There have been some negative reports about matrix management. It is said to significantly increase the number of meetings and communication overhead, and matrix management reportedly triggers numerous conflicts between project managers and functional managers.

But I think this is only true if you're stupid. Not if you're smart.

I strongly believe there are good and bad ways to implement matrix management. In organizations with stupid managers, where people actually desire organizing meetings and controlling people, matrix management is definately not going to help. It will simply double the amount of misery!

Matrix management does not solve the problem of having bad managers. It makes it worse.

Just think of this: Google applies matrix management too.

Google has good managers...

Good managers understand that there are times to discuss projects and there are times to discuss people, and these two don't have to take place at the same time by the same managers. In fact, separation of concerns is a good solution with any case of conflicting goals. I see no problem in a few healthy discussions between a project manager and a functional manager about some employee's priorities. (As long as they settle their differences with a cup of coffee instead of 200 pages of emails and documents.) Chances are their compromise will be far better for the employee than in those traditional cases, where project management and functional management are combined in the same person. This is usually someone who is not likely to be good at doing both.

Scaling
Matrix management can scale much better than traditional hierarchies. Google has shown that its organization can remain relatively flat. Their (few) functional managers are able to manage many more people now that they don't have to manage all their projects as well. The pool of project managers is different from the pool of functional managers. That's why I believe that matrix management is a big help in doing many simultaneous projects.

to be continued...

Subscribe to this blog with a reader or by email!

Latest, greatest and favoritest posts:
How to Do Many Projects with Few People (Part 1)
How to Handle Many Simultaneous Projects
How Not to Manage Your Country (or Project)

How to Do Many Projects with Few People (Part 1)

Given the problem (most managers call it a 'challenge') of running many dozens of projects concurrently, with just a small number of people, I've been asked a few times how we organize projects and resources in our company. Well, there's a lot to tell about this subject, and my attention span (as a manager) is rather short. So I'll spread that information over several posts.

Many of our customers have simple, small requests: requirements that take just a couple of days or weeks to fulfill. This means that the organizational complexity (some employees call it 'chaos') is vastly different from other companies, where they have teams of many employees working on just one project, often for many months at a time. But I am sure that lots of people face similar problems (or challenges if you prefer) as we do, working on numerous small projects. So let me tell you what we did...

We have many multi-functional teams, where each team is between 4 and 10 people, depending on the types of projects that they do. We firmly believe that everyone who's working on the same projects should be seated together. This vastly improves the project-level communication, and it enables employees to better understand each other's work. For example: there's no point in seating all project managers together, as they are all managing different projects. Their only communication would be about the latest soccer matches, and the new receptionist.

In the case of our software development teams, each team has a number of software developers, one front-end developer, one project manager, one team manager, and (soon) one tester. Our project managers perform the 'ScrumMaster' role, but they also concern themselves with resource planning of their team members across the different (sometimes conflicting) projects in their teams, and any interdependencies among the projects. Their primary concern is that the time they have allocated to projects is, indeed, being spent on those projects. They can often be seen (or heard) scolding people who are trying to steal time from their teams, with questions like "Can you help me with this little problem?" or "Can you call this customer? It shouldn't take more than half an hour." But, given the reduction in red faces and scents of burning hair, this seems to happen less and less often these days.

to be continued...

Subscribe to this blog with a reader or by email!

Latest, greatest and favoritest posts:
How Not to Manage Your Country (or Project)
How to Select a Fine Technical Manager
How to Create a Pre-Project Document

How to Handle Many Simultaneous Projects

Agile software development methods, like Scrum and Lean, tell you how to run your projects. But they all do that from a single-project perspective. What if your organization runs multiple projects at the same time? Do the agile practices still hold in such a case?

Our organization consists of 220 people, spread over two locations. We specialize in doing small fixed-price projects, most of them web-based. At any time we have at least fifty different projects running simultaneously, with lots of other projects in "sleep-mode" (either waiting for resources, waiting for customer input, or waiting for a Windows server to reboot). Handling fifty different projects creates a lot of communication overhead. (Noise might be a more fitting word.) There are always conflicting resources, conflicting constraints, and conflicting planning requirements.

So, the question is: What do Scrum and Lean say about such a multi-project situation?

Well, the answer is: Nothing! (But maybe they don't need to...)

Let's see... 220 people are working on fifty different projects. But is that so much different from other organizations where they have 220 people working on just one big project?

Many Small Projects = One Big Project
I could claim that working on many small projects is similar to working on one big project. In both cases there are simply different teams working on different feature sets. And in either case the teams don't know much about the details of the code being produced in the other teams. Therefore, it seems to me that running many small projects is similar to simultaneously developing many parts of just one big project.

Many Small Projects != One Big Project
However, I could also claim that working on many small projects is different from working on one big project. With many small projects you don't have just one troublesome customer to talk to. You have fifty of them! The horror! It is easy to agree on a sprint backlog with one customer. But it's much harder to have fifty customers agree on the allocation of your resources. (In fact, decorating our customers with bells, painting them red, and making them sing merry X-mas songs is easier than getting them to agree on our schedules.)

Optimize the Organization, not the Project
Lean Software Development has taught us an important lesson: don't focus on local optimization! Optimization should take place at the project level, not at the level of individual people, processes or components. But as I said, running many small projects is similar to simultaneously developing many parts of one big project. You should not try to optimize the development of the individual parts in a project. You should optimize the entire project. And in our case, with fifty small projects, the entire project = the entire organization. Therefore, I believe we should optimize the organization, and not the individual projects.

Get it? I hope you do. Because it took me five years to figure this out...

It's the same with traffic regulation on a busy road. By trying to make all cars adhere to a speed limit, the throughput can be increased significantly for everyone. But car drivers often try to optimize only for themselves. And then the system breaks down and everyone finds himself caught in a traffic jam, which could have been prevented by synchronization of the participants.

Picture by n-o-m-a-d

Synchronize All Projects
How can you perform optimization on the organizational level?

• Perform the sprint planning meetings on the same day for all projects (Mondays, in our case).
• Let all projects adapt to the same sprint length (weekly, in our case).
• Collect up-to-date project performance stats every week for the organizational resource planning.

A little (mandatory) synchronization can go a long way in speeding up all the participants. There is much less noise about resources, constraints and planning requirements across our projects when every single project is required to step in phase with the others. Sure, this might not be optimal for some of the individual projects. But we're not trying to speed up individual projects to their highest velocity. We're trying to speed up the entire organization, so we can improve velocity for all projects simultaneously.

The Organization is the Project
I believe that you can solve some resource planning challenges by treating the entire organization as one big project. When planning your resources, it shouldn't matter whether your people are working on many small projects or on many parts in one big project. This means that you can apply the agile and lean principles to the organization as a whole, and let them solve your problems at the appropriate level.

Subscribe to this blog with a reader or by email!

Latest, greatest and favoritest posts:
Fixed Price Contracts in Agile Projects
Simple vs. Complicated vs. Complex vs. Chaotic
Adaptation vs. Anticipation

Why Managing Small Projects is Harder

Some people think that managing small projects is easier than managing big projects. They are right, unless the economies of scale require you to manage a number of those small projects at the same time. In that case, managing small projects is a lot harder than managing a big project!

dedicated servers vs. shared servers
Many web sites are too small to run on their own dedicated servers. I know, I've built a lot of those sites. They usually run on shared servers (together with other web applications for different customers). As many system administrators know, management of a shared server is a lot more work than management of a dedicated server. On a shared server, the applications are fighting for the same resources (memory, drive space, database connections). And we must try to make sure that, when something goes wrong in one application, it doesn't bring down all the others too. Unfortunately, this does happen occasionally. One time it might be because of a Denial-of-Service attack against one particular site, another time it's simply because I screwed up again with one of my infamous infinite error loops. Customers often complain when problems with another site causes a failure on theirs. We then kindly suggest that they open up their purse and get themselves a dedicated server. Or, as a bus driver might say, "If you can afford yourself a taxi, sir, then why take a bus?"

dedicated teams vs. shared teams
I see the same problems with software development teams. I have worked in a number of organizations where projects where too small to form dedicated teams. These organizations usually work with shared teams. The resources in a shared team have to be shared among different projects. The customers simply don't pay enough to give them the full attention of one entire team. Management of such a shared team is a lot more work than management of a dedicated team. The projects are fighting for the same resources, and you must try to make sure that, when something goes wrong in one project, it doesn't take down the other ones. But again, this does happen every now and then. Customers complain about it, for sure. We then kindly suggest that they buy themselves a dedicated team, which they never do. They prefer complaining over paying twice the fee. Just like ordinary bus passengers.

agile methods assume a taxi, not a bus
There are many shared teams in the world, and not just in software development. Many hair dressers, car mechanics, accountants and lawyers work in shared teams. Such a team doesn't serve just one customer at a time. (Except for teams of lawyers with a customer the size of Enron.) Each team member usually serves a different customer, and resource planning can be cumbersome, because of the many cross-customer interdependencies. Unfortunately, every agile method assumes that customers have bought themselves the privilege of working with a dedicated team. It's as if they assume that people always take a taxi, and nobody takes a bus. It's a pity, because managing a bus is a lot harder than managing a taxi.

Can agile principles help a shared team?
Yes, I've seen that it is possible, but it takes a lot more effort. First of all, it takes one very strong project manager (or Scrum Master) to negotiate alotted time with many different customers (or Product Owners). Second, you have to translate all best practices for dedicated teams to the shared sitation. (Stand-up meetings are slightly different. Backlogs are treated differently. Iterations are very different. Pair-programming works in some cases, but not all. Etc.) Third, you have to educate anyone who thinks that you're "only doing simple projects". Because, when you can manage a number of small agile projects simultaneously, then you are able to manage anything.

Any bus driver can drive a taxi. But few taxi drivers can drive a bus.

This article was first published on AgileSoftwareDevelopment.com