Why I love to scrum 2

Continuing from my last blog about misplaced agile efforts, I should write, for the record, that I had always enjoyed agile and scrumming process for my other jobs.

Agile development and scrumming practices are useful only when they are not constrained by formalised theories.

I used to work with a cross-location, cross-department project team which had broad support from the departments that were directly involved in making the company profitable. It is great to work for a team supported by a user-base who have the financial authority and direct motivation to make the company profitable. They don't care about information management theories or violation of theories people had learnt from MBA or MISc degrees. They just want to make sure you are helping them make money for the company. I like working for such clients. They don't have the luxury for adhering to information management theories and most of all, they have the authority and discipline to over-ride those who do.

We scrummed by email, Solaris talk and telephone and sometimes video-conf. We only got those who had the problems and solutions involved. We were careful not to waste anybody's time. We made regular enhancements and releases. We had two weeks of beta for every release in which advanced users would test the new releases. We had an effective release roll-back procedure. It was a rather large multi-national and so we had to manage with different sites having different releases. There was a corporate project manager who did his job effectively. We had fluid project milestones and a queue of feature requests and a feature priority system. The feature prioritisation process coincided with what we would today call the scrum of scrums.

Now and then, some of my Information Department colleagues would berate my team as moving targets illegitimately existing on the absence of formal procedures and that our team simply survived only because we had the profits generating people behind us.

Hello? Only because we had the money generating people behind us? Why would the money generating people be behind us, in the first place?

Ok, since we were a large multinational, we tend to have more than one solution. A competing team decided to steal me away from my first team and the relocaton benefits were wonderful. I succumbed to the offer. It was another great team.

We scrummed as often as we needed resolutions. It was more like extreme engineering.

Once, a team member noticed a persistent spike in the development Sybase server that lasted for more than ten minutes. Two members of the team traced the source to a piece of code with cross-product query. A quick scrum was called and a raise of hands was made to find out who else was writing cross-products. Immediately, we had a microproject of excising all cross-product queries from our our application. We traced all the code to one single culprit who was a contractor. I just don't understand, none of the other team members did, why would he persist in writing cross-product queries after the team had decided to ban it. Doesn't he understand what 2.5 normalisation means? We were not in the business of sticking to normalisation perfection but to ensure our application ran as fast as possible. OK, we decided not to renew his contract because he kept citing importance of normalisation theory over performance.

We had a colleague, who was not in the team, who had decided that we lacked formal discipline and decided to help us rectify that shortcoming. He wrote a Delphi application that would help us track our activities to the time spent on each module of the application to help us justify if a module was worth the effort. All we had to do was, keep his application up all the time and key in whenever we started or stopped our work on each respective module. He shared it with the division head who thought it was a great idea. It was a riot because most of us (unlike he) were multi-taskers. The project manager managed to persuade our division head that it was a bad idea, fortunately. Our colleague was extremely disappointed because we had caused his efforts to be wasted. We were using AIX workstations and he thought all we needed was the simple case of running the PC emulation window to keep his application alive. OK, he thinks we have the CPU power to spare for a PC emulation window. I had only used the PC emulation window at the end of the day to play computer pong.

I just don't understand why now and then, there are colleagues who work jealously against an agile development team.

My next pleasant experience with agile development was in Colorado as a 1099 contractor. My client and I formed an extreme programming team. It was like playing ping-pong with him, sitting in the same cubicle. He was a software product manager with no one reporting to him, except a couple of contractors like me. Moreover, the view of the Rockies were great. Once, he drove me to South Park and declared that I was in an historic town. At that time, I had not realised that South Park, Colorado was the raison d'etre for the South Park cartoon. Until he told me. I mean, how could evangelical Colorado be the origins of such an irreverent cartoon show?

Then, I decided to return to the east coast, to the dismay of my Colorado client where I worked for a privately held company. It was a wonderful development environment. My management measured me by the level of happiness of my clients. They reminded me that I was there to provide statistical solutions and warned that it was a fluid environment. Finally an IS department that understands what profitable means. I am sure, being a small company makes profit-consciousness a top priority for the IS director. What a pleasant surprise. I had great reviews. When I had to live in a neighbouring state for personal reasons, they sought to retain me to accommodate my need of having to drive 6o miles to work until I found another job.