Learn from success, too

In my previous post I described how I used the concepts of Agile development without knowing it while working on a small project at the Ministry of Health years ago. The story continued thanks to the manager of the department who saw the potential of the initial product and offered me a contract to extend it. The idea was to turn the database I created into a searchable repository of all the research proposals that came through the department. It would then be integrated into the Ministry of Health web site.

 

My first product was successful and I learned a lot about coding and databases, but I didn’t learn very much about the process. I was still quite certain that I did it all wrong and fully intended to do it “right” this time around. To start, I wrote a proposal and negotiated the contract. This fit very well into my understanding of how things should be done on “real” software projects. Doing things “right” also included putting together a plan for the project with estimates, milestones, deliverables, scope and an up-front design. Only once I had that plan in place and approved would I start writing code. I’d do the final testing when that was done and then install and integrate everything in one shot. Right out of the gate, process was ahead of individual and interactions.

 

For my system to eventually integrate with the Ministry of Health website I needed to get my design approved by the architect in charge of that effort. I spent days documenting and drawing UML diagrams before going to do a presentation to another department in a different building. I talked to the architect, he approved it and sent me on my way. Another one bites the dust: I was spending more time on documentation than I was on making working software.

 

Time passed. I spent a ton of time on coming up with more design and making upfront plans. Finally I started writing code. Had I learned anything from my proto-lean approach in the previous phase I would’ve figured out how to stand up a light version of the whole environment in which I could experiment and iterate quickly. Instead, my plan was to create and perfect the parts separately and then magically put them together. Weeks passed and I still had nothing to demo to anyone, let alone a customer. Evidently, customer collaboration was out the window, too.

 

In the meantime the context of the project changed in an important way: the manager of the department went on extended leave and her replacement wasn’t really supportive of what I was doing. He worked in the same department and previously was one of my happy customers, but now he was stalling any time I needed anything from him and wouldn’t give me any support. I didn’t have enough experience to recognize that I no longer had a sponsor and didn’t do anything to garner his support. I thought that if only I stuck to my plan I would be able to work through it without his help. Following a plan instead of responding to change… Hm…

 

In the absence of working software and without any customer or sponsor support my project withered and waned. The team (me) was getting disillusioned and unfocused. I was writing code, but didn’t really enjoy what I was doing since I was getting no confirmation one way or another. Somehow I managed to complete the first milestone and get paid for it, but the next phase of my contract stalled somewhere in the bureaucracy. The new manager had no interest in pushing it through so nothing happened. He told me to work from home for the time being. I did. I never heard from him again. Somewhere in the cupboards of the Ministry of Health there is still a coffee mug of mine that I never picked up. The project joined the ranks of many software projects that never see the light of day or the touch of a customer.

 …

Projects rarely fail because of one major reason. Mine was no exception – it died a death by a thousand cuts, lots of them self-inflicted. This many years later it is difficult to say what my then-self learned from the experience, but I suspect nothing constructive. Today, though, I can extract many interesting lessons. For example  – isn’t it interesting that I dumped the agile-like approach that helped make the first project successful for one that was a more acceptable industry practice as soon as I possibly could? The reason I did that was because I didn’t have language to express what I was doing. I didn’t know Agile or Waterfall, wasn’t aware of the upsides or downsides of either. I didn’t know anything about development processes or how things could be done differently and didn’t have any mechanism to reflect not only on what I was doing, but also on the how.

 

Twelve years down the road I see this as the main lesson of that experience: if you stumble upon something that works, but don’t consciously recognize the elements of success and find a way to mentally frame them, the learning is lost and you have to start from scratch the next time. This is why frameworks and patterns are useful – they nail context into place and give a starting point for our journeys that makes sense to us and others. It’s a nice bonus when the framework we choose has a built in mechanism for reflection that allows us to evaluate what works and what doesn’t. Agile Development is a pretty neat example of a framework that does all that and more.