PDD – Post-It Driven Development

In mid 2002 I was asked if I wanted to do a couple of days consulting for a client who wanted to create a small e-learning tool using Microsoft Content Management Server. I’d just finished working on two consecutive MS CMS projects, so I didn’t think a third would really hurt. The term a “couple of days” is almost legendary now; as the project actually lasted 18 months and mutated from a “small e-learning tool” to a large localised e-learning tool that had tens of thousands of users and was deployed globally. It was a tough gig, but ultimately one of the most rewarding projects I’ve ever worked on and possibly the one that has the fondest memories.

When I look back at how we worked, Ken Schwaber’s phrase “control chaos” really does spring to mind. It was a trailblazer project; the destination was known but the journey was not planned out. We had extraordinary levels of executive sponsorship and the results were utterly visible to the entire company. The most satisfying aspect was that our small “pod” of developers were actually an extension of The Business. We were in every meeting either absorbing information, rationalising, scrutinising or trying to enforce reality.

The cycle went something like this; Monday morning we would have a short catch-up / planning meeting (no longer that 30 minutes) – this is where our manager would relay what the latest thinking was from The Business, we’d talk about what we needed to deliver and how we were going to deliver it. He’d scribble down notes. If we needed to discuss something at a lower technical depth, we’d grab a meeting room and chew the fat. When we got back to our desks our manager would give us a single Post-It Note (or multiple Post-Its all stuck together to form a giant Post-It if there were a lot of requirements or a diagram) with the tasks we had to deliver that week. This was the absolute minimum written documentation and guidance we needed to do the job, and do it well. We were able to achieve this because of the communication, transparency, buy-in and the fact that we were all pretty senior and battle hardened developers. With hindsight, this was our sprint backlog.

On a daily basis our manager would come and perch on the edge of our desks for a quick chat to check that everything was ok and to check our progress. Then he’d move to the next developer and do the same. As the project progressed and we really started to knit, everyone would stop and join in the conversation – part of it would be about how the tasks for that week were going, but part of it would just be a quick chat, a bit of a joke and a bit of bonding. If people needed to talk about a specific issue that would happen afterwards on a one to one basis. With hindsight, this was our daily stand-up and break-out session.

Towards the end of the project, it was decided that a specification was required, due to the fact that the application was to be moved into a managed hosting environment and we had to follow the corporate governance that they lived by. That was the easiest and most complete specification document I have every written. All of the business and technical knowledge was either in our heads or in emails to and from other members of the team, or an intrinsic part of the build and deployment process.

Our manager was excellent and I think that was a large factor in the success of the project. A few years previously he’d been a developer and even though he wasn’t totally up to speed with all the latest techno-jargon he knew development and problem solving. You’d be struggling with a problem for hours and he’d saunter over take one look and say “Try X” or “Have you thought about Y?” And you’d curse and thank him because you knew he was right. With hindsight, he was our Scrum Master.

We had a tight team and a tight development cycle. We’d get the tasks on Monday; we’d develop until late Wednesday / early Thursday. Then we (meaning The Developers and The Business) spent all day Thursday and Friday testing and if we had to deploy a new version of the application would do that on a Saturday. With hindsight, this was our sprint.

Our Engineering Practices were pretty good. We used Continuous Integration (this was before CruiseControl ruled the waves and Draco was still King), the Microsoft SDC Build Tools to automate the build and install process. We used Windows Installer and custom actions to do the install (the application, update database, lock down security etc) so that we had a repeatable mechanism that could be given to a 3rd party for repeatable, one click, no-brainer deployments. We had a data access layer that used attributes and enumerations to enforced consistency and we had clear, concise coding standards and daily code reviews (which I’d perform during the commute home) to ensure we had next to no technical debt – we had full comment coverage and the automated build used NDoc to produce good API documentation.

For me, this project was the essence of Agile Development; we were empowered developers; we worked with The Business to deliver exactly what they wanted, when they wanted, we had tight iterations and delivered features incrementally. We worked at a sustainable pace over 18 months, we produced the minimum amount of documentation required to get the job done, we had good engineering practices and we had fun; I’ve never been on a project that had so much laughter.