From One Expert to Another: Simon Baker

Simon Baker is cofounder of Energized Work, an energetic software development lab in London, and recipient of the Agile Alliance’s Gordon Pask Award. In this interview, author, speaker, and agile tester Lisa Crispin speaks with Simon about the approaches and tools his lab uses.

Lisa Crispin: Your team makes such effective use of big visible charts. Is this something you’ve done from day one? How do you keep thinking of new ones to try?

Simon Baker: Visibility has always been a big thing for me. Teams need to see what's important so they can make informed choices and use time effectively. Basic questions must be easy to answer: How are we doing? What's going on? What could we do next? How is this going to delight the customer?

Over the years, we’ve evolved through countless information radiators. Our boards have always been an integral part of our approach, and their design has become a continuous experiment to visualize the work and give us insight into possible ways to improve how we are working. Experiments like this customize our environment to work better for us and our customers.

I think it's pretty easy for us to come up with new ways to visualize information precisely because we have such a visual workspace and we’re so plugged into our working environment. The lab is like our nerve center. It shows all kinds of data for everything that’s going on. It keeps us focused on the big picture and reminds us why we’re doing things. It also helps us get to the bottom of things when they don't go as expected. Because we’re collocated and our work is powered by conversations, it’s easy for us as part of our everyday routine to feel when information radiators aren’t working. Occasionally though, we change things around just because we're bored and want to try something disruptive to see what comes of it.

Lisa Crispin: When I visited your lab, I enjoyed talking to Gordon Conroy. He’s a tester, but he’s obviously as much a part of the development team as any programmer. How did you integrate testers so seamlessly into the development team? Simon Baker: What places testers at the heart of everything we do is vertical slicing. The developers write the automated system, functional tests, and unit tests as part of their outside-in test-driven approach. They do the non-functional testing, too. The testers pull vertical story slices from developers, where each slice typically targets one or more specific acceptance criteria. For each slice, the story card is tagged with colored dots to indicate whether it’s had some exploratory testing done on it or there’s been feedback from the customer, designer, or users. The dots provide a visible record of how many times a story has had a tester across it and the amount of feedback received and from where.

In a way, a tester is one half of a double act with the customer. The tester transforms the customer’s ideas into actionable data and acceptance criteria and is usually the first to challenge priorities. The tester also keeps developers honest and ensures the product is usable. While I expect everyone to design with usability foremost in their minds, testers are the users’ champions. Within the flow of slices, they undertake regular heuristics evaluations and cognitive walkthroughs when they think it’s right to do so.

Our testers are active in every part of the lifecycle. They concentrate on finding things that don't make sense, as well as things that don't work. And, they have a different, wider view of the product that makes them the glue connecting people to the reasons the product is being created.

Lisa Crispin: The customer for the product you were working on when I visited was obviously highly engaged in the day-to-day operations. Was this just good fortune, or do you have some techniques to get your customers to participate fully?

Simon Baker: We work best when the customer sits in the driver’s seat, so we ask them to spend three days a week working with us in the lab. We make clear what they’re getting into and what we expect from them. To us, it’s a sign of commitment to their product’s success. Involving the customer in everything helps them gain confidence in our approach and assures them that we understand and focus on their business drivers. Kickoff is a one-day workshop to set out a product charter, and we re-charter every quarter so that customers can invest budget incrementally tied to those periods. The customer pitches his product idea to the crew like an entrepreneur would to investors. We create a shared vision, identify users and what they value, list business goals, constraints, and assumptions to be tested, and design operational and financial measurements with quantified expectations. Then, we start delivering.

By concentrating on personas and user goals and doing planning on demand, we avoid backlogs and keep the customer close so we can write stories when we need them. Stories are built in vertical slices to get emerging functionality in front of the customer as often as possible, so they can provide immediate feedback and sketch new ideas. Sometimes, the tester joins up with the customer for some café testing to get feedback on basic usability from people in coffee shops. We run weekly showcases, which are great PR opportunities. They need to be meaningful for the customer, so they’re rehearsed to deliver an entertaining narrative with the demonstrated stories.

In a way, we adopt the customer’s product as our own. We challenge assumptions, provide options, and try to improve it in ways the customer hasn’t envisaged. We encourage the customer to launch a minimum viable product at the earliest opportunity and we track the charter measurements to see how it performs in the market. We learn how the product needs to evolve, and, as we continue iterating, the customer can assess emerging benefits against on-going costs. Customers love being able to recalibrate to respond to users while staying in financial control. Our approach is a closer co-operation than they’re used to, but they quickly see the benefits.

Lisa Crispin: There is such a good vibe in your lab. You seem to have “optimized for happiness.” Everyone seems to enjoy the work, and they’re willing to try new things. What would you tell other teams who’d like to achieve this level of enjoyment and willingness to experiment?

Simon Baker: It’s difficult to say without understanding the circumstances people are in. I can only share what has worked for us and hope some of it is useful.

Gus [Power] and I try to give the crew a place where they can be themselves that has space for them to grow. Ultimately, it’s down to the individual to use that space. Leading by example encourages people to try things. I’m constantly experimenting. It’s important to make mistakes publicly and show vulnerability. When others see it’s safe to fail, they eventually start experimenting, too. The learning needs to be visible, and it helps to demonstrate improvements are sometimes being made. There’s a relaxed atmosphere at Energized Work and, because we‘re always larking about, it doesn’t feel like work. We have our ups and downs, but it’s easy to enjoy work when humor is used to share ideas and insights and you can put energy into the things you believe in. We ask people to do what they think is right, to direct their own work, and take initiative when they see opportunities to improve. As Peter Senge says, “A shared vision isn’t an idea; it’s a force in people’s hearts.” If we aren't intrinsically motivated by what we do, then it’s a waste of time. We all share the same values and work to a common purpose—to delight our customers. Because of this, we trust people to just get on with it.

Lisa Crispin: I learned some new book titles I wasn’t familiar with while visiting your team. Do your employees just naturally read a lot, or is there something you do to encourage that?

Simon Baker: It varies considerably. People have different interests. Some love to read books; others prefer blogs. I have tried to encourage people to read by sharing what I have learned from books. I think reading sparks interest in people and gives oxygen to ideas. I introduced a book club at the start of the year. It‘s been wonderful to see people eager to try out things they’ve just read about and develop their ideas to such an extent that they have featured in a few of our monthly Tech Talks.

The book club is great. It meets once a week for an hour, and a small group has become the driving force behind its success. People are free to get involved when they want. I’ve been working at client sites a lot recently, and I feared the club might wane, but Gordon grabbed the reins, kept people informed about reading milestones, and facilitated the sessions.

We’re now on our ninth book. To help sustain the pace, someone had the idea to space out the books by reading other types of publications or watching conference videos in between. Last week we read a paper by Chris Argyris called “Teaching Smart People How to Learn.” The club chose this as a warm up for the book we’re starting this week, Difficult Conversations by Douglas Stone. Personally, I’m looking forward to Managing to Learn by John Shook because I’m keen to improve my use of Toyota’s A3 technique. Lisa Crispin: Yesterday, you tweeted about a great learning session your team had. Please tell us about it. Is this something you do often? How do you “justify” the time for it?

Simon Baker: Unfortunately, I can’t talk about that tweet. It relates to something we learned while testing a business idea with users.

We put a lot of effort into trying to get better at what we do. Moreover, we try to improve at improving. This has highlighted the need to re-learn how we learn. In the past, we've fallen into the trap of “value fetishism,” where we’ve been so proficient at delivering value at speed that we’ve forgotten to take the time to step back, take a breath, and learn from what we were experiencing. We always did weekly retrospectives, but I think many actions taken in the name of continuous improvement just made us more efficient—we fine-tuned techniques. These days, we’re getting better at questioning our goals and asking ourselves why we are doing this. We learned that some techniques, like estimation, weren’t adding value. That was two years ago. We also learned that we are part of the problems we face. I guess we're a little older and wiser nowadays and seek a deeper understanding of what’s going on.

Part of that is a realization that people need time and space to work on themselves—to develop their abilities and instincts. We used to do pair programming all day, but now I actively encourage people to break away and take some time alone to experiment, practice, and learn. I also want them to take a day each week to work on whatever they want. This will present some operational challenges, but I feel it’s important they have space to pursue ideas.

Time for learning is paramount because, to produce something that’s actually useful, that delights users, and that makes their lives better, you need creativity, innovation, and appropriate use of technology. Creating software isn’t data entry. It’s a thinking discipline and a collaborative art, and I think the results Energized Work has delivered speak to the value of that perspective.