A project case study

Last summer at DeveloperTown, we chartered a project to have Spencer (one of our interns) along with Chris (acting as product owner and tester) build a new product for an existing client of ours. The work was a bit speculative, but low risk since Chris and I really felt like we knew what the client wanted and needed. Chris and Spencer used a fairly standard vanilla scrum process – leveraging Pivotal Tracker and some other basic tools – to deliver the foundations of the product. Every two weeks or so they would get together to discuss stories, progress so far, and feature tradeoffs. In about three months, they had all the high-level features implemented.

After a very productive summer, Spencer went back to school to finish out his degree. We decided it was time to show the product to our client to get some feedback. At the same time we also decided we should show it to some other potential clients as well. Partly because any feedback is good feedback, but also because we took some risk taking the time to build it out, and two paying clients are better than one. At this point – like any good helicopter project sponsor – I decided to re-engage with the team to get a feel for where we were.

Initial spike completed, let’s make it look good

I was thrilled with how well Spencer and Chris had executed the vision for what Chris and I had discussed as the opportunity. The product worked (minus a couple of trivial bugs waiting to be fixed), and virtually all of the core features were present. It was fantastic. However, it wasn’t “perfect.” From a sales perspective, it needed some sexiness. It worked, but it wasn’t awesome to look at. (You know – out of the box Rails and bootstrap... what I consider the new “vanilla” web.)

We decided to kickoff a short sprint to give the product a minor facelift, closeout any remaining bugs, and setup the production environment. Enter David, Steve, and Lisa...

When I say, “kick off a sprint”, you likely suspect that I mean we did something formal. Sadly, we didn’t. I simply asked my partners if I could invest a bit more in getting the final product ready – they said yes – and I pulled three people into the project based on availability. Each of them then proceeded to amaze me with how they approached their work. 

Imagine for a second I come up to you on a Monday morning.

Mike: “Hi Steve! Guess what? I need your help on ProductX. In seven days we’re going to be demoing the product to a couple of possible customers, and I was wondering if you could help make the product more ‘sexy.’” 

Steve: “Um. What? What exactly do you want me to do?”

Mike: “Well, you know… Make it beautiful. Add ajaxy goodness. Do the thing you do. Make it cool. Oh yea, and the primary platform for one of the customers is iPad, so you should make sure it’s responsive too. You good?”

Steve gives me a blank stare. I’m not an idiot; I know that I’m giving him nothing to work with. He should be imagining knives stabbing my stupid pointy-haired head.

Steve: “Okay. I’ll go talk to Chris and figure it out.”

I walk away and go to Lisa.

Mike: “Hi Lisa! Guess what? I need your help pulling together a logo for ProductX. It’s a product that helps people do foo. I’m guessing Steve will need it soon, and I don’t have that much money to spend on it, so you likely only have a couple of hours. Can you help?”

Lisa:  “Um. What? What do you want it to look like?”

Mike: “Well, you know… a logo. Make it beautiful. Something better than the placeholder text we have there now. Make it foo-y. And really, I can only afford to give you a couple of hours. You good?”

Lisa gives me a blank stare. Again, I know that she’s secretly envisioning Digby (our resident Golden Retriever) pulling me violently out of her house by my leg.  Lucky for me, he’s a creampuff.

Lisa: “Okay. I’ll talk with Steve.”

In my head, I think… “Steve has no idea…” But I trust they will figure it out. I walk away.

At this point, I leave the building. I have to go downtown to meet with another client. While I’m driving downtown, I read an email from David. (Don’t judge me, I could have lied and said Siri read me the email. But I didn’t. I was honest.) David heard he was on this project for a week, he had already met with Chris to discuss some of the stories in Pivotal Tracker, but he wanted to setup some time to get some additional background. I call him while driving. 

David: “Hey Mike. Thanks for calling. Chris gave me the high-level overview, but I’m still not 100% sure what problem this product is solving. Can you talk me through it?”

Mike: “Sure. Let’s start at the beginning. There are really three separate users for this software… [15 minute dissertation on the problem space]… and at that point, they login to view the weekly report. Make sense?” 

David: “Wow, very helpful. That makes a couple of the feature make a ton more sense.”

At that point, David peppers me with about five questions that sound a lot like, “But what about X?” “How will they handle Y?” or “Have you thought about Z?” To which, I have my canned answer ready… “David, that’s a great point. We’re really focused on minimum viable product. All of that will come later.” David is happy, and we get off the phone.

That night Lisa emails me an entire page of logos, perhaps 12 to 15 of them. They are good, but I don’t love any of them. I give her some feedback. Steve gives her some feedback as well.

The next day, I don’t talk to anyone about the project. I’m buried in other work. At the end of the day I get another email from Lisa with another round of logos. Lisa has some solid options in this set. None of them are the end game, but certainly good enough for minimum viable product. I tell her which one I want, and she passes it along to Steve. (I later learn that Steve would have picked the same one. That made me feel good.) 

For the rest of the week, I ignore the entire team. I see some regular emails from Chris with status updates. I largely ignore those too due to time constraints. In those emails, I see Chris prioritizing issues, outlining risks, asking questions. I’m scanning the emails, but if there’s not a clear “I need a ruling here!” call out, I archive the email and move on. I know Chris is following up with the team, accepting stories in Pivotal, and giving feedback. 

The next week, I travel to Chicago for my first demo. I’ve literally only glanced at the finished product once when Steve gave me a very quick demo (like 15 seconds) from his desk. I’m going in completely cold. I show the client and I get an actual “Wow.” It was awesome. A few days later, Chris shows the product to our existing client, and he gets “Love how much more user friendly the new software is. Many thanks for getting this improvement to happen. We want to cut over to it in the next two weeks.”

What happened?

We broke a ton of rules in those two weeks:

• We didn’t hold a planning/kickoff meeting.
• We didn’t do daily scrums (that I know of).
• We didn’t have stories for Lisa or Steve. And I’m fairly sure not all of David’s work was done via stories (but I believe most of it was). 
• We had a helicopter project sponsor.

We broke our own rules, but in the process we met the deadlines and we were still able to get accolades from potential clients. What happened?

Since those two weeks, I’ve been thinking about this a lot. I’m a big process guy. I don’t mean I love process for process sake. I simply mean that I believe process matters. I believe the way teams choose to work is a reflection of what they value, their specific context, and the million lessons learned that emerge over time. I view that as process. I’m captivated by why some practices work so well for some teams, but not for others.

So what happened? We did everything wrong, right? Here’s what I think happened.

1. I completely and totally trusted the team. I knew Lisa would deliver a logo in the handful of hours I gave her. I knew Steve would crush the UI challenges and deliver something awesome. I knew Chris would manage the risks and communicate with the team. And I trusted that David would make the right technical decisions behind the scenes – even though he was completely new to the code-base. Because of that trust, I simply made sure everyone knew what was needed, knew what the timeline was, and then I stayed out of the way. (The “stayed out of the way” part of that last sentence is likely a little self-congratulatory. In all honesty, even if I had wanted to stick my nose back in the project, I wouldn’t have had the time. For those of you who don’t believe in revisionist history, that sentence right there is what it looks like.)
   
2. Chris provided daily communication and prioritization. Chris sent emails. Chris updated Pivotal. Chris answered the numerous questions that I’m sure Steve and David had. He was the model of what you would hope a product owner would be: available and engaged, knowledgeable, deeply cared about the outcome of the project, and active in providing feedback through Pivotal comments, testing, and emails. I was able to put things in motion and walk away, because he was there to manage the fallout of my “help.”
3. The team cared about the outcome. I have to admit; I was kinda floored when David asked to meet with me to get more context on the overall product and market we were going after. In my experience, it is a rare thing for a developer to “zoom out” like that – especially with a tight deadline – to ask big picture questions. The only reason he did that, is because he cared. He could have just read a story in Pivotal, and then done his best to pound out the minimum lines of code to meet the needs of that story. But he didn’t. He wanted to make sure he really understood what we were doing.

Similarly, Steve could have phoned in some of the UI changes and just leveraged the contemporary design metaphor of the day. He didn’t. Some of the touches he added reflect deep thinking about how the user would actually interact with the software. It wasn’t just better looking – it was truly easier to use in some areas. He called me at one point to tell me that there was still a javascript bug that he couldn’t solve when rendered on an iPad. He wanted to make sure I knew about it so I wouldn’t hit it in the demo. He knew he would fix it within a day or so when he could get back to it, but he was looking out for me and protecting my interaction with the potential client. Again, I’ve worked with many developers in my past who would simply not say a word, and hope I didn’t hit it in the demo – if they even cared about the demo.

 Agile teams often claim that their process reflects the values of trust, frequent communication, and human caring. However, my experience tells me that those are precious and rare things. What the team was able to accomplish – from Spencer’s early foundational development work to Lisa’s logo, in the time and budget they did it – is amazing. At the points where our internal agile process helped, we used it. When it didn’t, we didn’t. And it worked because the process wasn’t what made us successful. It was trust, frequent communication, and human caring.

Imagine that some jack-ass (me) walks into your office and simply says, “Make it beautiful” and walks away. I can hear business analysts and testers around the world crying out in pain at the idea. It’s not documented well enough. It’s not testable. Bah. Steve and Lisa know what beautiful is. David knows what technology is production-ready and what technical debt we can live with. Chris knows what the client needs, and what’s fluff. At this scale, they don’t need specifications. They care, they ask, and they know their craft.

I wouldn’t run a project that way for six months. And if you remember, we didn’t. Chris and Spencer spent the first few months working in our run-of-the-mill Scrum process. They delivered a ton of value. But it’s refreshing to know that when the team needs to self organize and run at a different pace, it can.