Agile (and we didn’t even know it)

Back in 2003 I was involved in the resurrection of the building consents project. This was the third bite in the fourth year of a very prolonged and unsuccessful series of projects to replace a legacy system. The first failed as it placed a poorly coded ASP application on top of the legacy system –which would not accept multiple web users and crashed on go live day, the second failed largely due to the PM being so disinterested they did not attend their own project meetings and the technical lead going off at angles meaning that most of the code was half done. So it was my turn, using the leftover code form the second attempt. There was me, Mickey the band new Developer and Ruth, the expert from the business, whom became the ultimate champion and unsung hero of the project.

So we kicked off. The list of current defects was extensive. Virtually most of the application did not work and you could not login. We decided to focus on each functional area, get it working before moving to the next. So we started with the login screen, security, administration options and the basic consent summary landing page. Each day Mickey would code away,  while I would peer review and test (between being the BA, Trainer and PM). On a daily basis we would pop up and see Ruth in her quiet little office and spend an hour having her test the application and get feedback. We would then do a bit coding in the afternoon and so on.

After the consent summary it was onto the name and address module, building inspections, consent tracking, fees, conditions and finally notes. Each section was focused on and worked on until Ruth was happy that it was working as required. We then demonstrated and tested the code with a smaller group of key users. We then worked on creating a consent, printing and reports (which were really basic). Finally after two months of daily code, demo, test, code and repeat we were ready to begin more formal testing.

 We made some very pragmatic decisions as we went. The layout and logic of the consent tracking was not ideal, but we did not have the time to re-write it, the name and address register was unnecessarily complex (and ironically probably still is 10 years later),  the inspection business logic was too complex to code within the time frame. Each of these issues was prioritized into post-production releases – of which we had planned three before we finished.

Finally into UAT, training and release. Go live day was entertaining. As the previous aforementioned version 2 had died on go live day all the users jumped on and started searching and looking up consents, waiting for it too fall over. After about half an hour I popped up and asked if some would like to create a new consent – and actually use it. Off they went, no issues.

There are many agile-ish elements to this project. Sprints (off sorts), multi-functional closely located team, frequent demos, peer programming, retrospectives and so on.  At the time (and for many years later) the waterfall approach was standard at Council – despite efforts to introduce more agile practices. There were many common sense elements to why we succeeded - a dedicated team, engaged focused and extensive business knowledge, committed senior management whom wanted a successful outcome, a wider group of enthusiastic  users, limited but visible project governance. Also at the time using the corporate property system as the sole and automated source of property data as opposed to manual entry was new, but lead to a vast improvement in accuracy i.e. we went from having 7% of consents not matching to valid properties, to 0%.

The application is still in use, 10 years plus, parts of the original code and a lot of the original data model are still in use. We never did get around to upgrading to .NET and it’s still an ASP application. Due for decommission shortly as a new corporate wide solution is adopted.  Mickey left council two years later and two years after that Ruth retired. Over those four years myself and Ruth worked through all the backlog and made numerous and regular changes based on the feedback she received. Every year we would have a cake to celebrate the birthday of the application, this continued right until 2010 when I left, interestingly enough it was often over a mouthful of cake that some great ideas came out. This project remains the one I am most proud of as a Developer and I do miss working with Ruth and Mickey.

Standup My Friend

Recently I was asked what were some ways  to create a positive workplace culture, the organization in question had established a social club and it was not working. No one was showing up at the events and it was about to be axed.  I had a chat with my peer and told him social clubs only work when people work. Let me explain:

Organizations that are challenged with the need to develop or enhance culture will decide that one of the best ways is to organize a social club. In the ideal classless society such as New Zealand this is a seemingly great idea, grab the BBQ, butter the bread, squeeze the sauce and by virtue of wrapping a sausage around a piece of bread we are great mates. How many times at the social club BBQ do people come, eat, say hi and vanish with the sausage in a napkin back to their desk? How many times to they sit down and chat long after the sausages have slowly brunt or gone cold, the flies have landed on the bread and the salad remains untouched?

To want to socialise together you first need to work together. You come to work (noun) to work (verb). Simple. You need to complete tasks that are assigned to you. So far so good. Nobody said you needed to like your colleagues, this is assumed that it will happen. So your neighbour three desks down the row and on the same project team. What do you know about them?

Daily standups are an effective communications mechanism for projects. The team get to know what’s going on every 24 hrs. But there are also a great social mechanism. Inevitably small and occasionally candid pieces of personal information slip into conversations. Suddenly the annoying tester three desks down isn’t the jerk who seems to enjoy failing your code, but a guy with a pregnant wife who spent the weekend shopping for baby clothes. He seems more interested in his wife’s blood pressure than yours.  But that’s understandable, after all you have two small children. You were once that naive person that though antenatal classes taught you everything you needed to know about childbirth. He also seems like an okay kind of guy, so why not go and have a chat to him – offline – about his testing approach, expectations, ask for his opinion and feedback before submitting the code.

I am not suggest daily standups become a substitute social club, but they are a good start to social interaction. Communication is why humans evolve to where we are on the food chain, we can co-ordinate, retain and spread oral knowledge, entertain, empathize and so on with these skills. Otherwise we would be another struggling homo- species and cat food on the plains of Africa.

And antenatal classes, you forget everything at the first contraction.

The Mistake is Not Making a Mistake

There is a quite thought provoking section in the book PeopleWare: Productive Projects and Teams (DeMarco & Lister) called “A Quota for Errors”. In starts with:

For most thinking workers, making an occasional mistake is a natural and healthy part of their work. But there can be an almost Biblical association between error on the job and sin. This is an attitude we need to take specific pains to change.

This is quite a profound statement. How many organisations have methodologies that have become so rigid that – in an effort to drive out errors – they have killed off innovation, free thinking and creativity. But when is an allowance for an error a sign that standards are slipping and code reviews are not robust?

Good question. If you tell the team it’s okay to make errors. Can you see the number of failed code reviews reaching new highs and performance reviews becoming less pleasant. But the more I think about it there is an important principle here.

Why would you create an environment for people to make mistakes? An environment to take risks, think of new ideas and approaches. Otherwise:

Fostering an atmosphere that doesn’t allow for error simply makes people defensive. They don’t try things that may turn out badly.

Another great quote, they won’t try anything new, the risk of failure outweighs the risk of success.

 With errors, there is the good and bad. Cutting corners – no error handling, no rollback, not closing connections, basic code indentation – these are lazy errors. Mistakes someone makes when they are not being careful. These errors have cowboy written all over them.

Good errors occur when the Developers are thinking, trying something new, a different approach, a different library, code module, technology, whatever. They see a gap in the current approach or an opportunity to improve a methodology, the go for it. If they fail. They tried and failed. As opposed to did nothing, learnt nothing, gained nothing and won’t try again. If they succeed, what’s the outcome, the saving, the benefit, the payback. What’s the return on the risk now, next month, next year, next piece of software that needs building.

The average level of technology may be modestly improved by any steps you take to inhibit error. The team sociology, however, can suffer grievously.

So a somewhat late New Year’s resolution, allow the team to make errors, allow them to be human – not a component in a production line – and see the benefits.