A Recent Experiment on Reporting

I’ve been working with one client, well, not just one, but this post is about one. I helped them out a year or so ago launch a new website, although it was the entire team, and I was just a very small part of it. But, for the purpose of this post, I’m going to take full credit for everything.

It went pretty well. We delivered what they were asking for, but it took a lot longer than we expected it to. There was overtime. There were additional sprints. There were sections we threw out and then rebuilt because we didn’t like them as we learnt more. But in spite all of this, it really did go okay. The client was mostly happy, and the end product was far better than had been originally envisioned (and wireframed by a design agency).

In spite of the road bumps along the way, the client came back and asked us to do another site for them. So, step one was to look at the wireframes they’d spent about six months creating and getting sign-off on. No problem… We’d built a site for this client less than a year ago, had familiarity with their domain, and building it with the same technologies. So, we estimated the time it would take us to build what had been designed. We came up with a number, and took that to the client.

I was lucky. I wasn’t in the room when that number was presented. I was told it wasn’t a fun conversation to be a part of.

Basically, the number we’d come up with wasn’t in what they thought it would cost, or how long it would take. But we knew, because of our experience on the first project, that we were in about the right range, for what they were asking.

Round two: We had a look at their scope and tried to figure where we could reduce some of the scope or complexity. We found a few places, and reduced the length and cost of the project by about 20%. Maybe 30%. Still, we’d be delivering a pretty functional site, with pretty much everything asked for, but just streamlining some of the designs and workflows.

This time, I was asked to come along and present this to the client, so I could help them understand the amount of work required. The meeting went a lot like this one: https://www.youtube.com/watch?v=BKorP55Aqvg – especially the part when they point out they’re only asking for seven red lines, it’s not like they’re asking for 20 red lines… Sigh. Our estimate was still over double what the client was expecting.

I asked for the client’s budget and timeline. Why keep guessing, if they’ll just tell me. And they did. So, off I went, not really sure if I’d be invited back. Ever.

But I was invited back. And this time, I was prepared. I’d taken their budget, and we’d figured out what we could do for that amount of money and time. We’d figured out a way, at least our best guess, to deliver a fully functional site for the amount of money they had. And we closed the sale.

You might be thinking that’s the end of this story. And you’d almost be right. Except that now that we’d sold the project, we had to deliver it. And I was under a huge amount of pressure to be able to show if the project was on track or not. After all, we’d shortened the delivery time by more than half from our original guess.

The problem with this is that we didn’t have a fully created backlog, no way of really knowing the total scope. In order to sell the project, we’d eliminated any up front work, opting to just start development. What a novel idea…! And, about three days into this project, the client came to me and told me that there’s a new section they’d like to include. A very complex section. Never scoped before, never discussed before. But this was absolutely needed, no matter what, for the site to launch. My response? Of course we can do it; other features might need to be deferred to a second phase, but of course we could do it. One other thing I did – I asked if we could restructure three of the six sections we’ve already got in scope, streamlining them to not only deliver a better user experience, but also afford us more time to work on this new, must-have, feature. There was agreement on this, and off we went.

I spent the first sprint trying to get a handle on all of this, and at the end, reported it “red”. After all, I had no way of proving one way or the other if we’d get everything done. And as our first sprint, we didn’t get nearly as much done as we would have hoped.

By the end of the second sprint, I was still reporting this project in red. I still couldn’t prove, with hard data, if we were on track or not. But if anyone had a conversation with me, or asked what was going on, I would have told them that we’d already figured out two of the most complex parts of what we needed to do. We had a backlog now that would take us to the end of the fourth sprint.

During the third sprint, the backlog that we’d been working on changed again. Yes, we’d learnt some stuff along the way that would impact future work, and would impact what we could deliver. In a good way. We figured out how to deliver a couple of things slightly differently that would reduce the development effort. And, new features were identified.

For the fourth, and fifth sprints, I was still reporting the project in “red”. I was being berated for my inability to move this project out of red, and not know what the future would hold. My customer, by the way, wasn’t ever fazed by this – they took in stride. They knew what work was being done. They could see huge velocity improvements, and could see that their site was coming together. They were creating and publishing content along the way, and providing feedback on a weekly – often a daily – basis. They were totally engaged with the development team and were all working towards the same goal with a shared vision. This entire time, I was told on a regular basis that I’m wasn’t meeting expectations.

By the time we arrived at the end of sprint six, through lots and lots of conversations, and an amazing dev team who had been improving every single sprint, and identifying new ways to deliver better code even faster, the client was thrilled with the progress and at a point they were able to think about actually going live and replacing their current site. I started reporting the project health as “green”.

We completed the work in eight sprints. The decision to go live was now totally within the control of the business team, when they determined the timing would be right for them. This was faster than our final guess – we’d actually sold a fixed price project with nine sprints. But, we completed the work in eight. In fact, we completed way more work than had been originally scoped for those nine sprints.

Some might think I got lucky. Perhaps. But I know how much work I did managing expectations, saying no without actually saying no, refocusing asks on ways we could deliver something that would solve their problem… And, making sure that the team felt safe to identify things that were getting in their way, and helping to get those things out of their way… And creating a safe environment for the team to try things that they thought might help them go faster, without worrying about someone speaking to them about doing something, or implementing a tool, or writing a script, that wasn’t part of any story, but just something that would allow them to deliver better quality code, faster.

Yeah, it was an interesting experience and experiment for me. I’m pretty proud of the team I got to work with; pretty proud of the product; pretty proud all round.

Home Renovation & Agile Software Development

First of all, let me say that I’ve had it up to here with comparisons between building great software and building a house, or any physical building. They’re different industries, and building something a house is not the same as building custom software. Without dwelling (unintended pun) on this, it’s not the point of this post. Maybe I’ll write that post some time. But for now, let’s move on. There is an element where there is indeed a parallel. It’s not found in just custom software and construction, but in any venture where there’s a desire to build or create something new. It’s found in marketing, in advertising, in sales, in finance. And that’s that they all required interpersonal skills, communication, and coordination. But it’s more than just active listening, and this is what caught my interest and inspired this bit of writing.

About a year and a half ago, I started interviewing General Contractors to complete a renovation of my unfinished basement. My wife & I decided there would be a lot of benefits in having my mother-in-law come live with us; benefits for her, as well as for us.

I don’t know a heck of a lot about construction or renovations, but as a true generalist, I know a bit about everything. Including construction. And, I like to learn and know what’s going on. But I also have a full time job working at a job I quite enjoy. And while I like what I do, I tend to work a lot of hours – nothing excessive, but I do like to get into whatever project it is that I happen to be working on. So, I wanted to find a General Contract who would manage the entire basement renovation for me. Call me up when they had a question, talk to me about my needs & requirements, and come to me with creative options and ideas for decisions on what the end product will look like.

I contacted and interviewed nine potential general contractors. After narrowing my choices down, and having some fun with a weighted factor scoring model, narrowed it down to two, and from there, with some additional conversations and reference checking, selected one.

Quality was my one non-negotiable. Cost was on the table, as was the schedule. But I wanted to do this once, and do it right. My contractor started off really well, with getting things done, and getting them done right. As you can imagine, somewhere along the way, things started to not go so well. The schedule really started to slip, but I’d accounted for that. But it began to slip even more, and more… Eventually, he stopped working on my job all together and I was forced to terminate him, with the job far from complete.

I was in quite a bind.  We’re at the point now where my mother-in-law’s house had sold, we had a fixed closing date where she was moving in, ready or not.

Here I was, in the exact situation I was trying to avoid – managing the project and coordinating things myself.

But this isn’t about my woes. Or at least it wasn’t meant to be. If you’ve made it this far, I’m hoping you’ll keep reading, as so far all I’ve done is set the stage for what happened next. As you can likely guess, I ended up managing this project, getting involved in all of the daily details, coordinating various trades (well, first finding the trades, and then coordinating them), and even making trips to my local home improvement stores to buy things that my original General Contractor was to supply. Things like a toilet, shower door, bathroom floor tiles, doors, and kitchen cabinets.

I turned my kitchen wall into a Kanban board with two colours of post-it notes (one for things I needed to do: find a plumber; and one for things someone else needed to do: install the toilet). I prioritized the tasks so that those items that needed to get done in order to allow my mother-in-law to move in would be done (finishing the flooring in her bedroom is a higher priority than installing the phone line). With limited time to get her moved in, things needed to be prioritized though – there was no way everything was going to get done in the time before her house closing.

Now I did a pretty good job, if I do say so myself, in finding the people I needed to move this job forward. I found a new General Contractor, but limited his scope of work to drywall, doors, trim, and painting. I found a plumber, and limited his scope of work to the bathroom and laundry room. I managed to keep my original electrician. I found a flooring company to finish the stairs. And, without any real knowledge of how to renovate anything, I managed to coordinate all of these different people. I didn’t do anything special, I just communicated. And communicated. And communicated. And when one trade would ask a question, I would connect people, bringing them together to solve the problems themselves.

My plumber asked when he could have power for his reciprocating saw to cut a drain pipe that was too long. I had no idea – I knew my electrician was going to be done in four days from now, but I had no idea when he was going to do the bathroom. I brought them together, and something interesting happened… My electrician explained that he’d be getting to the bathroom at the end – not so good for my plumber – but once the electrician realized someone else needed power in that room, he change his plan, and the bathroom had power the next day. It actually required extra work – the bathroom power was being fed from a line that – you know, never mind the details of where the power was coming from: it’s not important.

The point is that the interaction and communication of others working on the same project helped things get done faster, and in an organic way. Sure, I was filling the role of Project Manager, but there was no management, just coordination, and communication. It’s interesting to reflect on what I did to make everything happen, and I’m pretty pleased and proud of the final result. This is what I do at work on a daily basis. And I like to think I’m pretty good at my job. I bring people together, facilitate conversations and understanding, and allow the experts to work together. They know their crafts far better than I could ever hope to. All I can do is enable and empower them to do their best, and then help move things out of their way that are preventing them doing what they do. There are many times when I look at the work that’s going on, and wish I could contribute directly. But then I reflect on my ability to set the stage for the experts, and enable them to flourish. That’s a pretty good job.

Gathering Requirements for Agile Development

The company I work for is a Professional Services company. We develop great software for companies. Just so we’re clear, what follows is entirely my own perspective, and my own thoughts. No reflection of the company I work for, nor for the company I happened to be working for at the time. As long as you understand that, keep reading. If you don’t, try reading it again.

We were asked to develop a new application to streamline an existing paper-based workflow. There are huge benefits for doing this, saving time, expediting responses, improving the data integrity… Great. The company, as with so many that I have the opportunity to work for, like to gather and build all their requirements up front. You see, Agile is something the development team does to deliver faster, once the requirements are all collected in a BRD, spec, or whatever it’s being called. But this time, we had an opportunity to develop this product along side the end users and business stakeholders. There was no requirement document, and we were still being allowed to develop.

As a development team with four really great developers with some domain knowledge & experience, we estimated the length of time we what we thought it might take. At this point, we knew the high level objective. We also knew the date that we wanted to get it in the hands of a pilot group. We were pretty sure we could deliver it faster than this target date, and said so. But, we were careful not to over promise, especially since no one knew exactly what we’d need to build. But we had a good idea.

Now, this organization uses Scrum. And by Scrum, I mean that they have planning sessions, daily stand-ups, and iterations. But basically, they take their requirements document and break it into user stories (which really are just broken down requirements). Then, they develop for a number of three-week-sprints, and deliver the requirements as laid-out in the documentation. Wanting to fit in, we tried to follow their process, but quickly realized that without a spec document, their business stakeholders were forced to become more involved with the development. We were writing user stories on the fly, refining them during our one-week sprints, and then delivering them a week later, getting feedback, and building upon what we’d developed. It became obvious that we weren’t following much of the scrum process, but were working in Kanban. It was great. The business stakeholders were getting working software on a regular basis, the development team was working bloody hard, but at a sustainable pace, and feeling really proud as they saw their ideas and suggestions being rolled into this application.

About six weeks into development, we’d been asked to build something a certain way. Which we did. A couple of the developers asked me if I liked what they’d built. I didn’t. I didn’t think it addressed the end-user’s needs, and neither did the developers. But, it’s what we were asked for. Because we were so tightly coupled with the business stakeholders, we showed it to them right away. Once they saw it, they too realized it wasn’t what they wanted. It was what they’d asked for, but upon seeing it, realized it wasn’t right. So they asked us to tweak it. We did. Still not quite right. Tweak a bit more. Hm. Something’s not working quite right. So, rather than continue developing and demoing, we got the Business Analyst and UX Designer to sit with the developers working on this feature and work it out together. I’ll say that again: they worked it out together. It was fantastic. Together, they’d worked out exactly how it should function, behave, and look. Over the course of two days, they’d gone through six iterations of how it could work before landing on the one that actually did work.

At eight weeks, we had a fully functioning product, ready to ship to pilot. We were off with our original estimate as to how long we thought it would take. We’d estimated seven weeks. That’s right. Without doing huge amounts of estimation, breaking the functionality into themes, epics, stories, without a specification document or BRD, we’d estimated and delivered the application with a variance of five days.

Along the way, we’d learnt a whole pile of things, like what wouldn’t work, and what didn’t work, and we’d already made those changes. I guess I glossed over that – certainly worth mentioning… How did we learn what did & didn’t work? We got end user feedback. That’s right. We actually talked to our end users. Us. The UX designer, the developers, and the agile coach actually got to talk to end users. And we did it in five days more than we estimated.

It was a lot of work. Talking to, and working with people, takes a lot more effort than building something off a piece of paper. It means you don’t always know exactly what’s coming next. Or, in the case of the really undefined feature, working with multiple stakeholders to get it as right as possible. Someone told me that we got luckily in delivering it so close to our estimate, since we didn’t do a formal estimation with defined requirements, assumptions and constraints. I disagree. We had some domain knowledge, and an overall view of what we were going to need to do. The team’s estimate wasn’t a guess. It was an estimate. It just happened to be derived without a lot of up front work. And the entire team worked really hard to manage the scope while ensuring the quality of the code was never jeopardized. Adapting to changing requirements and feedback allowed a great application to be delivered. One that continues to have very minimal negative feedback.

I’ve read somewhere that working software is valued over comprehensive documentation. Score one for working software.