fuzzylizard

I have been thinking about Two-Pizza Teams and some of the potential pitfalls companies might fall into implementing this idea. And I think I have found one based on the last project I was on.

The last client I worked with had a factory style, compartmentalized view of software. They spent months working on the design and when they thought they had it right, they sliced it up into small components and farmed them out to the lowest bidder. When it came time to integrate those pieces back together, they were stunned when they didn’t fit and the application refused to run. Six teams then spent months fixing everything up to release a very fragile, but working, product.

Part of the problem was that they tried to implement and solve too much too quickly (well, in combination with the whole lowest bidder thing). The final application basically implemented the same thing four times. Instead of solving the problem for one product line and implementing a working, stable solution then moving on to the next product line, they did all four at once.

Moving this idea forward to two-pizza teams, I have a fear that companies could do the same thing. One trick to making small teams work is how you divide the problem. Each team, and thus each problem, needs to be completely atomic. Therefore, no two teams are implementing the same ideas.

If you have an application that does basically the same thing across multiple product lines, have a single team do the initial vertical implementation (i.e., end to end across all integration points). Once the initial implementation is completed and working, other teams can then build upon it sequentially, implementing the remaining product lines upon a proven solution. This will also provide business value back to the company earlier rather then later and give the user’s something to test.

I think the best way of dealing with this is to be constantly breaking up teams and not letting any team work on more then one problem together. As soon as a team has solved their problem, that team is disbanded and the team members move on to new groups. This way, you maximize knowledge sharing and allow everyone to learn about what that team did.

The idea of Two-Pizza Teams has been around for a few years, but I just saw it a couple of days ago. I think it is the best term I have seen describing the optimal software development team size. The idea is that your team should contain no more people than can be fed by two pizzas. To give this a figure, a team of 5 - 10 people is perfect.

The idea behind this is that you shave off small problems and give them to small teams to solve. The team is completely autonomy and owns both the problem and the solution. This allows the team to innovate and create the best possible solution. In addition, since the team is so small, communication is fast and everyone stays on the same page throughout the project.

I think there are a few other advantages to having small teams which are:

• There is nowhere for anyone to hide. It is easy to recognize the dead wood and build small, efficient teams of highly skilled people
• There is no space for specialization. Everyone on the team has to become proficient in every area within their discipline and beyond. A specialization represents a possible bottleneck, so everyone has to learn how to do all the different jobs. For example, you wouldn’t want a dedicated DBA so all the devs needs learn how to work with the database. The result is poly-skilled workers who are able to move from team to team and from technology to technology and have richer tool sets with which to solve problems.

The best anecdote I have heard comes from IBM. Apparently, there were two teams at IBM both of which were trying to develop the same software. One was large and the other small. The software was non-trivial, something like an operating system. Software that you would expect a large to team to have to handle. In the end, the large team was over budget, over time and did not meet all the requirements while the small team met everyone of their milestones and their version contained all the features. (I believe this is properly documented in The Mythical Man-Month)

In reading about this idea, I came across several blogs that basically said there are some problems that must be solved by large teams. I think the above example proves this wrong.

One last thought about this is that teams should always have an odd number of people on them. This way, there is always someone to break the tie.

Other links:

• 37Signals - 3 people for version 1
• 37Signals - If you’re working in a big group, you’re fighting human nature
• FastCompany - Inside the Mind of Jeff Bezos
• Paul Graham - You Weren’t Meant to Have a Boss

The last project I was on, I attempted to be very disciplined and do test-driven development all the time. This didn’t also work out. Far too often I found myself writing code for which I hadn’t written tests first for. I would have to stop myself and write a test first. Similar to driving, the tests acted as speed bumps preventing me from going to fast.

Most of the time, writing tests was fine. They forced me to think about what I was doing. Instead of creating single, long methods that did more then one thing, the tests forced me to create small, single purpose methods. This resulted in cleaner code that was easier to test and easier to work with. And it also resulted in a much clearer understanding of the solution that I creating.

However, there were times when I knew exactly what I wanted to code and how to code it. This is where the speed bumps came in. Instead of just forging ahead and programming, I had to stop and create tests. And I must admit, far to often, I coded my solution first and created tests after. And far too often, I had to recode what I had done because it wasn’t testable. So the speed bumps, although frustrating at times, in the end proved to be the better way to code.

When you inherit code, how do you know when to spend time refactoring a particular class versus simply throwing that class out and rewriting it? How bad does a class, method, package, section of code have to be to warrant rewriting it?

On my current project, we have a few classes that are 1000s of lines of code in length with maybe one or two methods. These classes are very procedural and generally only have one unit test. (On the up side, they have about 80% code coverage) The powers that be have decided to scrap the current code and rewrite it. Under these circumstances, definitely agree with, and helped push, this decision. But this is a fairly extreme example.

Is this decision only faced in these extreme examples, or are there other legitimate reasons for rewriting code? In my experience, rewriting the code, if done properly (e.g., with refactoring and using TDD), would be faster and result in better results then refactoring.

I was just reading an interesting article by Joel Spolsky titled “How Hard Could It Be?: Five Easy Ways to Fail”, and this quote at the end caught my eye.

In the technology world, it’s better to view a big project as a marathon, and not a sprint.

The Object Mentor website has an excellent article on testing and the primary role acceptance tests. The part that I found the most interesting resonates with something I have been thinking about lately; when should acceptance tests be written.

Acceptance tests should be written at the start of each iteration. QA and Business analysts should take the stories chosen during the planning meeting, and turn them into automated acceptance tests written in FitNesse, or Selenium or some other appropriate automation tool.

The first few acceptance tests should arrive within a day of the planning meeting. More should arrive each day thereafter. They should all be complete by the midpoint of the iteration. If they aren’t, then some developers should change hats and help the business people finish writing the acceptance tests.

If the creation of an application is driven from its interface (those designs and wireframes that Usability people create), then both the developers and the QA people are working from the same page. It should be easy to create a series of Selenium tests that ensure the application is following the interface.

If a problem is found, then it is the interface that needs to change and the code and Selenium tests respond to that change. This helps ensure the client is getting what they envisioned.

I am not a fan of Big Design Up Front, but I think when it comes to applications that will be used by people, no matter who those people are, then it is the interface, or GUI, used by those people that needs to drive the development.

The thing I find cool about creating acceptance tests immediately is that it provides an independent check on what the developers are doing. It also provides a clear path for the developers to follow in creating the application. If you can clearly see what the inputs and outputs are, it is easier to code against them. It also shows you when you are done. If all the tests pass, then that story is complete; time to move on to the next one.

It is amazing the difference having the entire development team in the same room can make on a project. For the majority of the last project I was on, the team was spread across two or three cities and multiple rooms. It is tough to feel like you are part of a team when you never see everyone and the best method of communication is IM.

During the few weeks leading up to go-live, the entire team was in the same room. The change in morale was incredible. The BAs were just a question away and the client was in the other room. This meant that issues could be dealt with quickly and everyone understood each problem.

This is my first time really working under these conditions with the entire team in the same room. And although the room was small, I definitely see the advantage. Maybe XP has something here.