16 ThoughtWorks developers, 8 pairs, 5 months. We are re-implementing a large, well-known* e-commerce site with lots of complex legacy systems integration. The timeframe from start to finish is 5 months. In the beginning I had no idea if that was realistic. After a month I thought it was a tad optimistic. Now, with one month to go I am convinced that we are going to make the deadline!
Here are some of the things that I think are making this project successful:
1. Shared vision and values among developers. Projects suffer when developers have to do battle over values, tools, or techniques with clients, project managers or other developers. Our development team is 100% ThoughtWorkers, and though we do have heated arguments (frequently these are simply violent agreements), we agree upon and enjoy many of the following values and techniques: pair programming, simplicity, embracing change and test driven development.
2. Strong support and responsiveness by the client for integration tasks. Interacting with legacy systems at large companies can be challenging. Often times such systems have been on life support for so long that nobody really understands how they work. In cases like that it is critical to make sure you have full access to the system, code, and available experts. We have been fortunate to have direct access to the code and experts, and it has been key to our success.
3. Love of Simplicity. Throughout the project most battles and arguments fought amongst ourselves and with other stakeholders have been about simplicity and figuring out how to do the simplest thing that can possibly work. While we may have lost a few 'architectural battles' along the way. I think that in general our daily focus on simplicity has kept velocity (and spirits) high.
Here are some things that have hurt us:
1. Managers who equate working long hours with hard work. With as much agile and XP experience as we have at ThoughtWorks I can't believe that this still comes up. Honestly, forcing long hours over a long period of time and restricting vacation doesn't make the project go faster. Poppycock!
2. Processes that inhibit code improvement. This is another thing that I wish I didn't have to mention. Creating a 'workflow' around bug fixes so that developers aren't notified when bugs are found is horrendously wasteful. If you've read any books on lean techniques you have to realize that creating and storing inventories is very bad mojo. Creating and storing inventories of bugs? Poppycock!
3. Java. You know, web frameworks for Java have come a long way, but there is one big problem: they still use Java. Big IT needs to get out of the 90's! Rails is a much better framework than anything the Java community has produced. It is mature and has a thriving developer ecosystem. Heck, it even runs on the JVM. For more opinions on this, check out the first question of this interview of Neal Ford and Paul Gross.
*I know it would be more interesting if I could talk about who our client is... but the deepest, darkest sort of nondisclosure magic has bound my lips and my pen so that I cannot use certain names.
1 comment:
Josh,
I worked on a TW project as IM back in the day. It was a great project but near the end there was concern about the deadline. Weekend work was encouraged in the hopes of speeding things up. I kept count, and on regular days we signed off 45 story points during this overtime period. On overtime days .... 4 story points got signed off.
There were certainly extenuating circumstances, but it is hard to ignore a discrepency that big. Overtime at the deadline( or anytime) is not the answer to getting more work done.
Post a Comment