A Meeting vignette

On Tuesday at 9:07 you sit down at your desk, open your email and are greeted with a popup: a reminder for a 10:00 meeting that you’ve accepted days ago without ever looking at it. You’re not sure why you’ve been invited, but you have, so you’ve got to go, right? You grudgingly think that you won’t be able to get any coding done until the afternoon now.

You go through the emails, then open your IDE and code a little, but don’t have time to run, test, clean up or refactor before you have to leave at 9:45 to make it to the other building by the meeting start time. The elevator is slow, but you get to the boardroom at 9:57 … only to find three people out of the twelve invited chatting about last night’s hockey game and their weekend plans. The woman who called the meeting is late. Someone says that figures: she’s got another meeting on Tuesdays until 10:00. By 10:05 the rest of the invitees stroll in, cups of coffee in hand. Conversations get more animated, some open their laptops and start typing busily.

At 10:06 Cheryl – the meeting organizer – storms into the room, laptop and notebook under her armpit, eyes the crowd and blurts out: “Where’s Jason? We can’t start without him!” Someone points out that Jason is still at his desk because he said he’d like to get some work done and to ping him when everyone is there. Cheryl mutters under her breath, drops her stuff at the only empty spot left at the table and storms out shouting over her shoulder: “Can someone start the online meeting? Peter is dialling in from home.” A few people shrug and look at the intercom system questioningly: they don’t know the conference number or how to use it for that matter. Tanya says: “I think the number is on the invite, can someone check?” She reaches over and waits while Eugene find the number and reads it out to her as she dials. She says: “Peter, are you there?” Silence. She shrugs: “Maybe he hasn’t dialed in yet.”

Of course, you don’t really care about any of this because you brought your laptop and have finally connected to WiFi and the network, and are now trying to figure out why the code you wrote twenty minutes ago isn’t doing what you expected. Just when you think you’ve found the problem, there are loud voices outside the door: Cheryl walks in followed by a man with a steaming cup of coffee in hand – must be Jason. After more shuffling because there aren’t enough chairs, everyone finally settles in, Jason plugs in his laptop and turns on the projector. Cheryl says: “Peter, are you on the line?” Silence. “What number did you guys dial?” Tanya looks sideways at Eugene and says: “The one on the invite.” “The updated invite?”… A few more minutes are spent finding the newest invite and redialing, where to Cheryl’s frantic: “Peter! Peter are you there??!” a voice distractedly replies: “Yea…” It’s 10:12.

Cheryl introduces the topic: “We’re here to discuss our overall approach to designing the backend for this project. Jason, can you take us through the details please.” Jason pops up a presentation and starts reading through it. After a couple of slides, a staticky voice breaks through – it’s Peter and he’s got a short comment.

By 10:50 you’ve tuned out. For the past twenty minutes Peter has been explaining his concerns about integration with third-party services that you know nothing about and that no one bothers to explain. Cheryl is asking him questions, Jason looks visibly annoyed, a couple more people are unsuccessfully trying to get a word in. Good thing you brought your laptop. No one tells you anything, three other people are also on their laptops. Tanya is on her phone. A guy next to you is doodling in his notebook. A woman across the table looks like she’s about to nod off.

The meeting is scheduled until noon, but runs over. At 12:18 you walk out of the room unsure what’s been discussed or decided, but at least you think you’ve manage to solve the problem with your code. Back in your own office at 12:30 you realize that you’re starving, so you grab lunch and coffee until 1:30 or so. On the way back you’re thinking about the code and starting to feel like you might actually be able to accomplish something today.

At your desk, you open your laptop: finally, you can get some work done!  … and then you see another meeting invite. 2:30 to 4, Services Architecture Review. You sigh, oh well, at least you’ve got another failing test to fix so there will be something to do while Andreas and May go on like they always do in these meetings.

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.

Agile before it was cool

In the 100th episode of This Agile Life the hosts talk about their first experiences encountering Agile development and how they first used its concepts without knowing it. Musing about the start of my career in IT, I realized that I too first used concepts of Agile and Lean software development years before I even heard those terms. Usually, when people ask me how I learned about Agile, I say that it was at my current job about 5 years ago. Well, I’ve been lying all this time. The first time I applied Agile concepts to software development was a full 12 years ago at my first job out of university.

I graduated in 2004 when the job market wasn’t at its liveliest. I thought very little of my own skills (a topic for a different post) and basically had no idea of how to go about finding a job in IT. After a month or so of futile searches I got a job through an employment agency as a temp office assistant at a small department at the Ministry of Health. I had to answer phones, make photocopies, file and do other routine office things.

Bureaucracies are renowned for being inefficient, slow and lazy. At this department, though, there was always plenty to do and the six people working there rushed around to finish their commitments by deadlines. They were responsible for distributing funding for research projects in the province and a large part of their work was reviewing proposals from various organizations. I would start this process when I unpacked a document and put it in a thick folder to which I attached a piece of paper that listed stages with checkboxes to be ticked as the document travelled through the office. Sometimes a folder got lost, I’d look for it and eventually discover it buried on someone’s desk, the person blissfully unaware they even had it or filed away without anyone knowing.

This system wasn’t a complete disaster and it wasn’t like anyone’s life depended on it, but it definitely could be better. Since my duties as an office assistance took only about half of the time I actually spent there, I decided to program a system to track these documents.

Customer collaboration over contract negotiation

The manager of the department I reported to was up for it if I could keep doing my actual job. She agreed to provide input and to let the department use the software if it made them more efficient. The others were willing to try whatever I built, but they were cautious. After all, I was an office assistant – not a big time, expensive consultant.

For the first time in my career I set about figuring out how to solve a real life problem for real customers. My project had some interesting features:

• No budget other than the time I was willing to put into it
• No upfront requirements or scope
• No deadlines or release pressures
• Real customers a few steps away
• Cross functional team (me)

I thought I was doing it all wrong. I imagined that I should be spending a long time collecting requirements, getting approvals, designing the architecture, writing code, testing, etc. Instead, I had to quickly build software my customers would want to use.

Individuals and interactions over processes and tools

I had a lot to figure out but the only way I saw to succeed was to start small. I refined my overall understanding of the problem by talking to my co-workers and decided to mimic the paper based process through a desktop UI that would store the data in a centralized database. I sketched out the lifecycle that documents went through and a simple UI. Since there was no one to approve this plan, I approved it myself and moved on to the next step: implementation.

Here I ran into an issue: I had plenty of theoretical knowledge about writing code, databases and UI design, but little idea about how it all fit together. I needed expert help. Luckily, my dad is a programmer and has always been very supportive of me. He enjoys coding and is a great mentor. So I recruited him to be a sounding board for my ideas and he helped me work out the technical details.

Working software over comprehensive documentation

I spent a couple of weeks coding in between answering phones and at night. Soon, I had a working prototype. The backend ran on an Access database and the front end was a VB form. I demoed it to my clients and they thought it was the coolest thing ever. They gave me feedback and asked me to change a few things. Overall, they couldn’t wait to use the software I wrote! I was even more excited than they were!

After a couple more weeks of refining, testing and fixing bugs, I was ready to deploy. Now came the really hard part – I had to figure out how to install this stuff in a government organization. After a bit of haggling with IT, I put the app on people’s machines and got the database up and running. In a matter of weeks I achieved the stage many software projects never live to see – I was in production!

Responding to change over following a plan

Of course, more bugs surfaced once people were using my app on a daily basis and more features they wanted to add or change. I ended up deploying another two or three versions, but none were disruptive or lost information. The crucially important thing was that customers liked using my product and saw the benefits. It solved a real problem for them, was easy to use and was reliable. And they got it in a matter of weeks for very little cost.

I didn’t know about Agile or Lean software development and yet that is exactly what I was doing. I used common sense to get the best out of limited resources available to me with a lot of motivation and got great results.

Despite all this the next project I worked on at the Ministry of Health was a total failure. Why wasn’t I able to extend my successful execution to the next stage of my career? I will write about that in my next post.