“Remote” in “Teamwork”

Toronto is a big city. It’s not huge compared to New York or Hong Kong or Moscow, but it’s definitely too big to commute across. You know it by how much people talk about the traffic in this city and how emotional they get. If you ever find yourself at a dull party, just strike up conversation about public transit, traffic, road closures (I’m looking at you, King Street Pilot Project), construction, suburb vs downtown living, or people’s driving skills. I dare you to find someone who enjoys commuting in this city. There is not a shred of fun in driving or taking transit to and from work, and yet thousands of people continue to do it every day.
“But I must get to work to feed my family!”

Let’s be clear: I am aware that not everyone works in IT and that there are many jobs that have to be done by people being at a particular place at a particular time. At the same time, there are many jobs that can be done online or on the phone from home or a remote office, and yet people doing those jobs are still expected or even required to be in the office every day. In this post I want to talk a bit about my own experience working with remote team members.

Team co-location used to be all the rage in the Agile community. You couldn’t take a step without walking into a discussion of virtues of teams that work together in the same, preferably open, space every day. Mentioning that your team had remote members or that people worked from home a few days a week guaranteed some serious frowning from other Agilists. I know because I did the frowning on more than one occasion. It’s not surprising, since one of the principles behind the Agile Manifesto is daily face to face communication. This is so common sense that one wonders why this ever needed to be stated explicitly, but of course it did because for ages the norm has been anything but face to face conversation. In siloed corporate environments with layers upon layers of hierarchy, emails, memos, letters and scheduled meetings have long ago replaced simple conversations.

For a while I was certain that co-location was necessary and anything else was second best. The benefits of co-location were obvious: as a developer I could easily turn around to the PM and ask a business question or show story progress, I found out right away when QA’s ran into issues (sometimes before they even said anything – their faces were dead giveaways), and I could easily talk code to another dev. In my view working from home was ok occasionally, but really subpar, and I scoffed at any suggestions of remote team members (it sounded too much like outsourcing).

But the times… they were a-changing. One fine day I was faced with the prospect of working with remote team members located all over the world (and contractors at that). Don’t think I gave up without a fight. Oh no, I kicked and screamed all the way to the first planning meeting. Change is hard even for the most Agile of us.

People on my team were from Toronto, all over the US, from Poland and India. I had to figure out a stand up time that would work for everyone, but people were very accommodating and it all worked out alright. We all had to get used to each other’s accents, but that’s often the case at any workplace anyway. The company brought everyone together on site every few weeks – that helped a LOT to get us to trust each other and communicate better. Pretty soon it was a fine melting pot and we started getting some good work done together.

I made a startling discovery: remote contractors were human too. They lived, they breathed, they were shy or outspoken, they laughed at jokes, they talked about the weather and weekend plans, they asked questions, they made decisions, occasionally they made mistakes. Most importantly, though, they did good work and they were interested, curious and driven; they wanted to succeed and learn.

On the other hand, I also became acutely aware of the fact that some of the people in the organization, people who were co-located, who came to the office every day and had 100% face to face communication, were detached and uninterested in their work. They showed up in body, but not in mind or spirit . Working with them was brain numbing and I’m sure they felt the same way too. This was a huge lesson for me. I realized that I would much rather have remote people on my team who were motivated and excited about the work than have co-located people who didn’t care.

Once I let go of the idea that co-location was required for good team work, I was free to solve the actual problems that do arise when people need to get stuff done together across distances, time zones and cultural divides. These problems were not of some insurmountable metaphysical category. They were common problems of human interaction and communication. And while they definitely were amplified by distances and time differences, the approaches to helping a remote team solve them were similar to those for a co-located team.

For example, just like for a co-located team, good team work is impossible without trust. Building it takes time and patience. Transparency, open communication, celebrating success and pitching in to overcome hurdles together, all with a sprinkle of good humour, go a long way. Bringing our distributed team together in a physical location for a week or two once in a while was an awesome way to boost trust.

Cooperation and common understanding decay quickly if there is no ongoing free communication. It’s harder to communicate over phones, emails, messengers and teleconferences. But a remote team is also more aware that communication needs more TLC. As a Scrum Master for a remote team I used to spend a lot of time making sure that people connect, talk things over, get to a common understanding and decide how to move forward.

Just like co-located teams, remote ones must continuously improve the process through retrospectives, because just like for a co-located team, that’s the key to becoming a great team. And while it’s definitely easier to run retros for co-located teams, there are many great online collaboration tools that can be used to run remote retros. I used Google docs as a very low maintenance and low setup solution. Scrumblr (http://scrumblr.ca/) was also a fun little alternative. There is a ton of others. It’s probably better to keep the retro format simple for a new team, and start experimenting when people get more comfortable with online communication – though, once again, that’s a good rule to follow for a co-located team, too.

In recent few years co-location has ceased to be a staple in conversations about Agile. To me this is a good thing. We’ve accepted the reality that companies sometimes have to look for talent outside of their location. Technology has advanced enough to make remote collaboration much less of an issue. Team work challenges remain, but they all fall into the same buckets for both remote and co-located teams. I think that if the option of remote work can save us from the mind-numbing commute it may just be worth a try.

Improve your meetings now! Ask me how.

So you’ve taken the first step and admitted you have the meeting problem. Maybe the smells helped you or maybe you already felt in the back of your mind that there must be a better way. Now what can you do to improve your next meeting?

The best meeting is one that doesn’t happen. The next best thing is a meeting that has a goal and is well-facilitated. The worst meeting is one with no agenda or upfront information that has no facilitator and quickly deteriorates into side discussions that don’t lead to resolving the goal.

Meetings are expensive, so make sure you really need one before hitting “send” on that invite. Sometimes an ad hoc discussion, an email or online chat can be enough. 

If you’ve decided that you must have the meeting after all, then spend some time formulating the goal of the meeting. What are you trying to achieve? What are the decisions to be made? Once you can answer these questions it should be easy to figure out who to invite. People who are absolutely needed to make the decisions must be there, those who can contribute useful info to the discussion should be there, and, lastly, those you’d like to keep informed might be there (you can update them through email or a short conversation later).  

With the goal and the decisions in mind, create an agenda that lists all the items up for discussion. Then approximate how much time you’ll need for each item. Add them up and pad a little for context switching (5 min per item). If the meeting is longer than an hour then plan to have some bio breaks. 15 min every 45 min is a good rule of thumb.

Send out the invite highlighting the goal of the meeting with the agenda and any additional materials. Explicitly state who you expect to attend in order to be able to reach the goal. If you’re inviting others, be clear about what they can expect to get out of the meeting. Let people know whether they can opt out of attending.

As I said, one of the worst things is a meeting with no facilitator where side discussions proliferate and hijack the goal. So, prepare to facilitate or find a facilitator for your meeting. This person ensures that the meeting moves along, that the agenda items are discussed and that everyone has a chance to speak. Whether you do it yourself or ask someone else, make sure that everyone understands the role of the facilitator.

Like any event, a meeting has the best chance of success if you do a little prep ahead of time. Put together any visual material or printouts, think about the discussion and timing, consider any roadblocks, make sure the equipment you need (projector, teleconferencing, white board, etc) is available.

One thing people really hate about meetings is when they don’t end on time. We’ve all been there, sitting on the edge of our seat, everything gathered in our arms, ready to shoot out the door the minute the meeting ends. And it just keeps going… and going… and going. Don’t let this happen at your meetings. Always start and end on time.

---

Starting and ending on time is the golden rule for improving meetings and it can have a magical effect on your whole company’s culture because it shows respect for your own and other people’s time. Respect leads to trust and before you know it you have people who actually enjoy working together. So: start on time even if people are late. Gently reiterate some of the points already made once they arrive. Once people see that your meetings always start on time they will make an effort to be there.

Ending meetings on time is equally important. People might have other commitments and they will appreciate not having to be late for them. To do this start wrapping up about ten minutes before the end time. Review whether people feel that as a group you’ve achieved the goal of the meeting and discuss any decisions, follow up actions and Parking Lot items. If the goal hasn’t been achieved then decide on the next steps: schedule another meeting, continue via email, talk as a smaller group, involve others, etc.

---

You’ve got a clearly stated goal, an agenda, the right people in the room and you’re starting the meeting on time. I’d say you’re in a sweet spot to have an awesome meeting. Now all you need to do is make sure that it all goes according to plan. What’s the plan? Easy: stick to the agenda, quickly snip off and park irrelevant discussions, make sure everyone has a chance to speak, keep track of decisions being made, and wrap up on time. In other words: facilitate.

Facilitation is a topic in and of itself, so I won’t go into detail here. There is a ton of information online to get started. I will mention one super useful tool: the Parking Lot.

---

Use the Parking Lot to record topics that aren’t contributing to reaching the goal but might still be important to keep for later. The Parking Lot is simply a white board area or online document that’s visible to everyone. When people start discussing tangential topics, respectfully ask them to park the conversation for later. Review the Parking Lot at the end of the meeting and decide what to do about the items there.

---

Another important job of the facilitator and, frankly, every attendee is to make sure that there is a clear set of actions that represent the decision. So, make sure these are clear to everyone and take notes. After the meeting send out a follow up email with a summary of the decisions/action items and next steps.

When you walk out of the meeting breath a sigh of relief, get a cup of coffee and do a quick checkpoint with yourself: how did it go? what did you like? what could you have done better? Make a quick note of what you’ll keep doing or change next time.

Improving anything takes time and a few tries. Meetings are no exception. Start with these simple steps and tweak based on your observations; be patient and be persistent. Better meetings are out there, it’s up to you to make them happen .

Are meetings hijacking your work?

Poorly organized and run meetings have heavier negative consequences than just being boring. They waste people’s time and drain productivity and that means wasted money and opportunities for the company. Just multiply the hourly compensation of each person needlessly in the meeting by the amount of time they’re distracted or otherwise not participating, sum up and stare at the number in horror. It’s an easy mathematical exercise, yet companies often ignore it. That sucks because it may be the lowest hanging fruit of waste they can fix or at least improve on. Having better meetings benefits everyone: the company has less waste and people are happier. To quote Joey from Friends: “What’s not to like?” 

So, have meetings hijacked your work? Sometimes you just know it, but if you aren’t sure, here are a few “smells” you can use to sniff out whether or not meetings are taking over productive work time in your organization:

• People block time in their calendars to get work done. 

… so that others see they’re busy and don’t suddenly spring a meeting invite on them. Which happens all the time anyway, but at least they tried.

• You often hear individual contributors say: “I might get some work done today… or not: depends on what my day looks like.”

… because there is no predictability to their schedules, people don’t feel in control of their time and can’t plan it productively.

• People stay after hours or on weekends to get work done because their work days are too fragmented.

… individual contributors especially don’t usually consider going to meetings to be part of their work definition and feel like they haven’t accomplished much during the work day.

• Meetings of various length are randomly sprinkled all over people’s calendars.

… so people are forced to context switch a few times a day. Knowledge work requires focused thinking and thinking is like an oven – it needs to warm up before it reaches even heat and the door should be closed while the food is cooking. Open it too many times and you’ll get underbaked muffins or too raw a roast.

• People are distracted in meetings: on their laptops or phones, doodling, daydreaming.

… i.e. they’re multitasking. Humans are generally terrible at multitasking, so you can be sure they’re neither listening, nor doing well whatever they’re distracted with.

• Only two or three people out of those present do the talking.

…in a meeting of six or more people this usually means that more than half aren’t actively participating. If they’re also distracted they aren’t getting much value out of the discussion. (There is a special type of gathering where it’s ok for only one or two people to talk: it’s called a presentation)

• People are often unsure what (if anything) was decided at a meeting.

… the goal of any meeting should be to reach a decision and a set of actions on how to move work forward. It may not be the final decision, but it should be a step in that direction. If at the end of the meeting people don’t know what was decided or accomplished, their time was wasted and the goal of the meeting was not reached.

 

If any of this sounds like your organization then there’s much you can improve. I’ll share my experiences about meeting improvements in my next post. In the meantime, there are plenty of online articles, blog posts and even podcasts that give great, simple pointers. For example, check out Manager Tools podcast series on effective meetings and facilitation:

• https://www.manager-tools.com/2005/08/effective-meetings-get-out-of-jail
• https://www.manager-tools.com/2017/01/simple-facilitation-choosing-plan-part-1

 

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.

Book Notes: The New Economics by W. E. Deming

I realized with some surprise that two of the most influential books about management among those I read in the past year were written over 20 years ago – years before Agile was a formal concept, a buzz word, a knight in shining armour or the worst thing to happen to humanity depending on who you are or how you’ve experienced it. The first book was Peopleware: Productive Projects and Teams, the other – the subject of this post – W. Edwards Deming’s The New Economics for Government, Industry, Education. Yep, perhaps it was naive of me, but all these years I sort of assumed that Agile was the new kid on the block fighting age-old management concepts with groundbreaking new thinking. These two books finally enlightened me to the fact that many of the ideas at its core were around for a long long time. 

W. Edwards Deming died in 1993 at the age of 93 and The New Economics was published the next year. He made revisions to it up until his death. He refers to sources written in the 50s and some even longer before than – in the 1920s, a couple in the late 1800s. This book is a summary of lifelong thinking that Deming formulated as Systems Thinking and the Theory of Profound Knowledge.

Deming’s thought and writing were focused on manufacturing where America used to excel at the beginning of the 20th century through the wars and into the 1950s. Nowadays it is popular to blame the weakening of US manufacturing on open borders and trade agreements, but Deming describes its decline starting in 1955 – long before any such arrangements ever came into force (most trade agreements weren’t put in place until mid-1990’s, i.e. after Deming’s death: Wiki)

Simply, other countries like Japan, Mexico, Korea, etc, began making products of equal or better quality at a lower price. Deming thought that future success of US economy was in “specialized services and products” with an emphasis on innovation and quality. He placed the ultimate responsibility for both in the hands of management who are the leadership and change agents. Good management can propel innovation and creation of great products that customers love, bad management is doomed to be stuck in downward spirals unaware of how it fails the company and the employees. Continuing to act with best intentions and applying best efforts in the wrong framework of thought doesn’t lead to any improvement and sometimes successfully runs the company into the ground.

Yet there is no general understanding of this. In Deming’s time and in many cases today management continues to hold employees responsible for failures in quality and lacks a vision for the future. Those in leadership positions focus on the wrong objectives that miss the big picture, causing heavy damage to their human capital and the long-term bottom line. Deming put it in no uncertain terms:

The present style of management is the biggest producer of waste, causing huge losses whose magnitudes can not be evaluated, can not be measured. (p. 22)

Ranking people, incentive pay, punishment and reward of individuals, management by objective, emphasis on numerical goals, delegating responsibility for quality to groups or individuals and many other traditional management practices focus on maximizing performance of components and emphasize competition among people and departments. Instead, the job of leadership should be to foster cooperation and to optimize the performance of the whole system for the long-term.

Appreciating and understanding the whole system is at the heart of Systems Thinking. So what exactly is a system?

A system is a network of interdependent components that work together to try and accomplish the aim of the system. (p. 50)

The job of management is to orchestrate the interaction of these components so that they work together towards the aim. The aim Deming proposes is everyone’s gain in the long-term: shareholders, customers, employees. Working together towards the common aim means that individual departments might sometimes have to give something up or take a loss instead of always trying to maximize their own profit.

How does one acquire appreciation of a system and foster cooperation of its components? It sure sounds like a great goal, but anyone who ever worked with a group of people knows that it’s not so easily done (actually, it’s wickedly hard). Deming doesn’t claim it’s easy either, perhaps quite the opposite – and there is a hint in the name of the theory he puts forward: a Theory of Profound Knowledge. 

An individual leader must first undergo a personal transformation. As I understood it, the gist of it is to be a compassionate and sympathetic person, who acts with integrity and mentors others to act with the same values, and strives to create a safe environment for change. Such a leader can then consciously work towards building up profound knowledge which lets her see and understand the organization in a new way that allows for its transformation and puts it on a path forward. Profound knowledge consists of four interconnected parts: appreciation for a system, knowledge about variation, theory of knowledge, and psychology.

A leader should understand that a system is made up of not just individual components but their interactions (appreciation for the system). Events in this interconnected system are inevitably affected by variation which leads to outcomes that deviate from expectations. Organizational leaders who recognize this can use statics to study the processes in their system. Once they have the data and the trends, they have a shot at properly addressing unexpected outcomes that can occur because of a common or a special cause. Deming writes that organizations often make costly mistakes when they try to fix (or replicate) an unexpected outcome that was caused by a special cause as if it was caused by common cause (and vice versa). So it’s important to minimize such mistakes.

Studying a process also lets the leader understand whether it is in a stable or an unstable state. Both states have variation, but we can make predictions about the performance of a stable process. Having the data, the leader can start forming the theory of knowledge by making predictions about future outcomes and then observing and systematically revising the theory. Finally, awareness of how people interact on a personal level, how they learn, what motivates them and other aspects of psychology helps managers optimize their people’s abilities and find appropriate rewards.

I found that Deming’s explanations of the theory, especially of variation weren’t the most straightforward, but he later describes two simulations that make it a lot easier to understand. The Red Beads and The Funnel experiments in chapters 7 and 9 provide a much more visual way to understand the concepts and the implications. An even better way is to participate in a simulation at a local meetup, conference or coach camp (as I recently did at the #SystemsThinkingTO meetup in Toronto.)

The New Economics isn’t exactly what I would describe as an easy read, but it gave me lots to think about. Deming’s style of writing is disjointed and sparse and also contemplative, almost like one would expect of an Eastern philosopher. Instead of breaking down ideas into easily consumable parts, he puts up signposts of his thinking and lets the reader fill in the rest. There is a lot of knowledge packed into the book’s 220 or so pages. I think many will find it impactful and influential.

Large-scale transformation and your IKEA Billy bookcase

This summer I spent three weeks travelling through Scandinavia with my boyfriend. One of the things that surprised us most was how poorly bathrooms were designed in many of the places we stayed. The AirBnB apartment where we rented a room from a young doctor, a highly-rated hotel in Oslo, campings, a boutique hotel in Nordkapp were all plagued by the same problem: after taking a shower the whole bathroom, including the mat, the trash bin, the slippers, would be flooded. Some of these curious designs were driven by a lack of space, while others seemed to be just lack of common sense. A bathroom with the shower head right over the sink, a shower with no curtain or door, no separation of the floor between the shower and the rest of the room are just some of the examples, all of which led to the same result: a great flood any time you took a shower.

In all of Scandinavia there was one notable exception: Sweden. Wherever we stayed there the bathroom, even if small, was always designed in a way that made it possible to shower without soaking the whole world outside. I wondered why Sweden should be so different from her neighbours until we visited the IKEA museum in Älmhult. There I read about the transformation that dramatically changed the Swedes’ living conditions (including bathrooms) starting in the first half of the 20th century and eventually contributed to the success of IKEA.

Between the mid 19th and 20th centuries Sweden became industrialized and it’s rural populations moved in droves to the cities as a result. Long story short: eventually this created a housing crisis in the country where housing wasn’t particularly great to begin with. The Swedish Social Democratic government wanted to fix this social issue and provide people with good and affordable housing.

Sweden stayed out of WWII (smart move if you could swing it) and by the end of it was left with an intact infrastructure, workforce and plenty to do for the European countries, many of which lay in ruins. By and by, in the 1950’s and 1960’s the economy grew rapidly and the government had money in the coffers. It was too early for large-scale IT projects to squander, err, I mean, spend it on, so they used the money to build houses instead. One million of them. Yep, you read that right: 1,000,000 housing units over ten years in a country of eight million people. They even called it the Million Programme so there wouldn’t be any confusion over the exact number. The government gave out various subsidies and incentives so people could afford the apartments and houses built as part of the program. In the end they built it all and had a surplus of housing. Also, the general living conditions improved (bathrooms too).

All this new living space needed new furniture and Ingvar Kamprad was right there with his innovative ways of showing off good looking cabinets, chairs and coffee tables in IKEA showrooms, selling them for less than the competition and packaging them in flat boxes that the customers could take home on the roofs of their own cars. And so a large-scale transformation initiated by the government not only created better housing for hundreds of thousands, but helped one of the most successful enterprises of the 20th century thrive.

—

References:

1. IKEA Museum (http://ikeamuseum.com/en/)
2. https://en.wikipedia.org/wiki/Million_Programme
3. Ulf Ollson (1991) Planning in the Swedish Welfare State, (http://spe.library.utoronto.ca/index.php/spe/article/view/13046/9937)

 

 

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.