Top three lessons that improved our process
Looking back at my projects for the last two years, we’ve had a tremendous improvement in the way we’re working. There are many things that we have done to make it better, and I’m be hard pressed to pick just three things I’ve learned. After much consideration, my favorites are: Partial production; Whole team; Requirements = Tests.
- Partial production: Using real production data for production in various scenarios has been extremely helpful. We’re doing pilot production (running a few customers on a new system), parallel production (running all customers through the new system, but throwing away the output), copy production (running a second copy in lock-step with production, and comparing the results) and replay of canned production data (running up to four months of production data over a test system). This has given us confidence that not only does the system fulfill the requirements; but it behaves as it should and can withstand the real load of the system.
- Whole team: Previously, people working with testing and deployment were outside the project that they served. Previously, a different team developed the web solution and the “engine”. Previously, technical decisions were made by people with no skin in the game. The team should be responsible from everything from requirements to production, from UI to database. Granted, we need help from others and respect what will cause extra work for others. But the team is in the driving seat.
- The requirements are the tests, the tests are the requirements: A good test in the system, even a unit test can be looked upon as a small requirement. For example “given that we have an order; when we add a pair of pants ($20 per pair) to the order; and we add a pair of socks ($2 per pair) to the order; then the order total should be $22” is a fine unit test. A requirement to “make sure that unauthorized users cannot change data in the system” can be expressed as a test. When you think about the requirements as tests, they become much sharper. When you think about the tests as requirements, they become much more expressive. (Tests don’t need to be automated to be useful, but it helps)
What things have helped you the most lately in your projects?
Comments:
jhannes - Aug 25, 2008
I don’t know any way to succeed with a single software project with 100 people. If you know a way, I would love to learn it. :-)
If you don’t know a good way to do it, I’d personally downsize the project to 10 people. I don’t know if you have any better chance of succeeding, but at least you’ll fail cheaper.
(Technically, “Whole team” is not the same as “small team”, but in my experience, “small team” is important too.)
[André Rakvåg] - Aug 25, 2008
Interesting post, I think this is very good advice. I have seen the serious problems that can be caused by not following the “Whole team”-principle. But can that principle be followed on projects of size, e.g. more than 100 people? Do you have any thoughts on how one can organize such projects and follow this principle?
Johannes Brodwall - Aug 25, 2008
I don’t know any way to succeed with a single software project with 100 people. If you know a way, I would love to learn it. :-)
If you don’t know a good way to do it, I’d personally downsize the project to 10 people. I don’t know if you have any better chance of succeeding, but at least you’ll fail cheaper.
(Technically, “Whole team” is not the same as “small team”, but in my experience, “small team” is important too.)