Connect

Phone: 317-709-2419
Calendar: michaeldkelly
Email: mike@michaeldkelly.com
Twitter: michael_d_kelly
LinkedIn Profile: michaeldkelly

Adproval
Saturday
Mar082014

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.

Thursday
Mar062014

The MVP Reading List

I regularly get asked for book references. From employees new to DeveloperTown, to founders who walk in the door and aren’t sure where to start, to people who look at what we do and how we work and ask how we figured all that stuff out. Some of it we figured out, much of it other people figured out and wrote down. We were smart enough to read it, apply it, and adapt it to the way we work. You can too.

Here is my take on the books that best capture how we think about product development. At DeveloperTown we’re big on iterative development (or as Ries puts it – small batches), customer development, validated learning, clean and simple design, and clean and simple business documents. The following books have been very influential in how we build our products:

The Lean Startup, Ries
The Four Steps to the Epiphany, Blank
The Entrepreneur’s Guide to Customer Development, Cooper and Vlaskovits
Business Model Generation, Osterwalder and Pigneur
Rework, 37 Signals

Because we often aren’t just building products, but are also helping founders build companies (and sometimes building them ourselves), I also recommend the following to help navigate venture capital, starting to understand what it’s going to be like working with investors once you get their money, and building and running a business:

The Art of the Start, Kawasaki
Venture Deals, Feld and Mendelson
Unfunded, Carter 
Traction, Wickman
Founders at Work, Livingston

When it comes to the specifics of building our software, we use our own flavor of agile development – but in it’s early days it was strongly influenced by Scrum. We develop primarily using Rails and an army of controlled but ever-changing frameworks to go with it, we do everything in the cloud, and we test constantly (much of it automated, some of it manual, a bit of it with users). For those who want to know more about our development methodology and where it comes from, I recommend:

Lean Software Development, Poppendieck and Poppendieck
Agile Software Development with Scrum, Schwaber and Beedle
User Stories Applied, Cohn

That list doesn’t really touch on some of the development and testing principles, but that’s just because I’m not really aware of any good books out there that capture those concisely. I could recommend a bunch of books from The Pragmatic Bookshelf, and each of them would have a piece of it. But my experience is that much of that knowledge is captured in blog posts, on forums, and in the rich debate that happens between team members when they go to solve a problem. We post about some of those debates occasionally.

Finally, if you’re responsible for getting software out the door, there is another list you might be interested in. It’s the list on getting things done, managing the process, and shipping great software – some of the best works on project management I’ve read (and I’ve read a lot on the topic):

Ship It!, Richardson and Gwaltney
Making Things Happen, Berkun
Manage It!, Rothman
Release It!, Nygard

Some project managers may look at that list and say Release It! doesn’t belong there. They are wrong – it does. On small/agile projects, if the person leading the project isn’t constantly thinking of those things, then it’s very likely that no one is. For us, project management is the art of alternating between the strategic and the tactical, balancing tradeoffs, and communicating progress. To do that, you need to be knowledgeable (not expert – just knowledgeable) about all aspects of the product.

(I originally wrote this post on the developertown.com blog in 2012. We've upgrade the website - killing the old blog - so I decided to repost here.) 

Monday
Nov042013

Three alternative uses for test management software

If a quality assurance team has implemented a sophisticated test management system, then its members have no doubt experienced some of the significant benefits this technology can provide, including syncing on-site and offshore teams, creating and storing automated test scripts and sharing testing resources across the entire company. Once these features have been digested and fully implemented, QA leaders might wonder how they can further take advantage of their test management software to wring the most value out of this high-performance utility. With a little creativity, QA management can discover innovative uses for this technology, optimizing the performance of software testers and developers.

Get more value out of test management platforms

Of the many ways that quality assurance professionals can leverage their test management software in new and exciting fashions, three stand out as the most surprising:

  1. Cultivate testing innovation - Sometimes testers and managers can hew so closely to accepted QA dogma that they run the risk of production stagnation. Teams and technology change, and what once worked effectively in the QA environment may no longer offer the same benefits. The addition of new software testers presents an opportunity for managers to reconsider how to best utilize their personnel and resources. Quality assurance experts Rikard Edgren and Qamcom Karlstad noted in a report the pair authored for The Testing Eye that infusing standard processes with some creativity can pull testers out of disruptive production ruts.

    By experimenting with new testing techniques, QA management may come across a new approach that makes the best use of current personnel. For instance, pair testing - where two testers collaborate on a single process, with one running scripts while the other documents the results - may prove to be an effective method for those staff members. QA teams will need to have access to a flexible and comprehensive management system that can quickly and conveniently create, store and share test scripts and reports in order to try out new approaches to testing.

  2. Leverage mind mapping - There is no single best way to attack a particular piece of software. Typically, a balanced diet of disparate testing methods and tools offers the most effective way to thoroughly check for errors or performance issues. Because the approach is not set in stone, some testers find it is beneficial to come up with new testing methods as they mentally develop. Encouraging these processes and sharing successful methods and techniques with other team members can be extremely challenging without an overarching management platform.

    Many testers have found that creating mind maps to generate graphical representations of their mental testing concepts can help them structure abstract or unfocused ideas, as well as better communicate these thoughts to team members for further use. A high-quality test management system can accommodate the creation of the necessary materials as well as facilitate the dissemination of successful methods across the team.

  3. Optimize test sprints - QA veterans - particularly those who have served on agile projects - are by now extremely familiar with test sprints, when specific software features are examined in a short window of time. Software engineering researchers Shlomo Mark, David Ben-Yishai and Guy Shilon explained on Testuff that QA can get the most value out of these processes by approaching the code in different ways and seeing what methods prove to be the most effective at identifying flaws and errors. Because these production windows are often extremely hectic, keeping track of which tactics worked and which fell flat can be very difficult. However, QA management can record the success rate of different approaches and scripts within a test management system, giving team members a roadmap for optimal test sprints moving forward.

The above post is a guest post provided by Zephyr.

Friday
Oct042013

STARWEST 2013 Slides Posted

Just posted the slides for both of my STARWEST talks from earlier this week:

All feedback welcome! 

 

Sunday
Sep302012

Writing Better Charters

My webinar for Tips for Writing Better Charters for Exploratory Testing Sessions just posted to YouTube: 

 

I really enjoyed putting these slides together. I also received a bunch of questions I still need to follow up on. If you have any feedback, it's much appreciated.