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.

Over the last week I have been thinking about the benefits of storing data online. This includes things like email, calendar, news readers, bookmarks, and online backups.

I use Google’s Gmail client. I have not opened a desktop email app in about a year. I originally made the switch because I was using several different computers and traveling a lot. Using Gmail allowed me to send and received email wherever I was on whatever computer I was using. The downside to this convenience is that I do not have a local backup of all my emails. A problem that is easily fixed for email, but not so easily done for things like calendars and news readers.

In addition to Gmail, I use — 37signals’ Backpack and Highrise, Google reader, and Google Calendar. The data in the apps is not as easily replicated without entering it twice.

The last area I have been thinking about is online backups. I have looked at two companies; Mozy.com (I am trying their free account now) and ElephantDrive.com. Both have very attractive plans at reasonable rates. The upside is that they provide offsite backup which is good to have. The downside is that if I ever loose my data locally, I may have to download 50 Gigs of data one file at a time. It almost makes more sense to buy a terabyte drive, fill it up, and store it in a bank vault.

The question I would like to pose is what do people think, do you use online applications or do you put all your data on your computer? In this age of online computing, does it makes sense to have all your data online, or is there still a place for desktop email clients and news readers?

I have decided this year to set myself three New Year’s projects/story cards. Instead of creating some vague resolutions that are devoid of acceptance criteria or measurable goals, I am creating story cards and projects that have tangible and visible results.

1. Blog a minimum of once a week.
2. Resurrect my TeamDocs open source project and bring it to a 1.0 release
3. Create and release my first Ruby on Rails project

I am also going to manage these three goals as one would manage projects. I am not sure if I am going to use Basecamp or some other software. For TeamDocs, I will probably use the space on Google Code. This means I will be updating the website and checking in new code in the very near future.

As for the third project, more information on that will come. I am not sure if I am going to make it open source or try to release a hosted web application.

I took a look back at 2007 and realized that I had not really accomplished anything. In a nutshell, 2007 was mostly a brain-dead year for me. I made the mistake of relying on all my learning coming from work. Although I have learned lots of things little of it was technical. Instead, most of it was people or soft-skills. This was a mistake on my part; no one should ever rely on their work as their sole source for learning.

According to Joel Spolsky:

management is just an annoying, mundane chore someone has to do so that the smart people can get their work done. Think of an academic department at a university, where being the chairperson of the department is actually something of a burden that nobody really wants to do; they’d much rather be doing research. That’s the Silicon Valley style of management. Managers exist to get furniture out of the way so the real talent can do brilliant work.

It’s an interesting way saying that managers should exist to facilitate and not decide (technical issues).

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.

For the last day and a half I have been wandering around in the dark trying to solve bugs with the project that I am working on. The project lost its guide; we lost the last original developer (his wife had a baby, congrats Igor). The result is that we no longer have anyone who understands the design, the implementation and the domain.

It is amazing how this changes things. Where before we could show him a bug and within minutes he could guide us to the answer, we now fumble around trying to understand the code and what it should and should not be doing.

I think the biggest thing this has shown is the huge holes in our understanding, of my understanding, of what the application actually does. The mood of our stand-ups have changed as well. Now there is uncertainty and doubt when it comes to fixing bugs. The confidence we had last week is gone.

A few weeks ago, while at the Chicago office, I was a part of discussion in which someone brought up the idea that Story Cards should not be closed until they have passed their acceptance criteria in a production environment. Mix this in with something Fred George posted the other day about dealing with bugs.

if a bug blocks a story, then the clock is running on that story until it is fixed and moves forward. Developers on a Lean-oriented team will attack bugs rather then work on development of new stories. The net results is few bugs live for more than a day.

These two things together ensure that a project has very few bugs. It ensures that conversations that need to take place due to bugs are done with the client and the developers who implemented the story card.

There is an implication in closing bugs in production though and that is that you need to have a production environment in which to close them. Far to many projects leave the production environment till last. The software is finished and everyone is waiting around for it to be deployed to production. Since production is the first fully integrated environment in which the software is used, there are a tonne of bugs found and the official release is delayed. But the bugs are harder, and more expensive to fix, because the developers who implemented those features are now long gone.

Granted, why should a company buy hardware and software licenses now for an application that is not scheduled to be released for several years. But compared to the amount being paid to develop the application, the cost of the hardware and software licenses really is trivial; it represents a very small percent of the total cost of the project. The problem is that it can be the most visible cost.

Closing a story card in production also means that the story card has been thoroughly tested in that environment. This should mean that real users and have actually used the application, for real, before they close cards. This means that the business rules are correct and the developers can move on to other areas of the application. This means no bugs.

And no bugs is a very cool idea.