Vince and Lisa choose their cookies

We’ve been doing sprint retrospectives every two weeks for eight years, so it’s always good to get out of our rut and try something new! We each chose a cookie, and took turns reading the “fortune” inside, which was a thought-provoking question. The first question was “What could the ScrumMaster do to be more effective?” This discussion led to an idea for a new Big Visible Chart – a wall on which the SM would show the stories she and the Product Owner are preparing for upcoming sprints. We also decided to try going over requirements for each user story with not only the product owner, but the primary stakeholder for each story, which the SM will ident

Lori looks excited about her fortune

ify.

All of the “fortune” questions provoked good discussions, and ones we wouldn’t have had otherwise (we had already done our standard retrospective before digging into the fortune cookies.) For example, “How would you improve our sprint review?” Ours could certainly use improvement, but we never talk about it. I think our next sprint review will be better!

One of the questions puzzled us, “Were our Artifacts helpful for this sprint? Could we improve them? How?” We weren’t sure what “Artifacts” referred to. But the question led us into thinking of a better way to note requirements changed after coding begins, and ensure the developers are informed of all changes.

A cookie for our remote team member

The fortune cookie concept posed a challenge for Nanda, our teammate in India. We had to open his cookie and read it for him. While we were fighting over who should get to eat his cookie, the cookie got dropped and shattered on the carpet. Having fun as well as thinking of experiments to improve made the retrospective fortune cookies a big success!

Whoops!

(Thanks to my teammate Mike Thomas for taking some of these action photos with our team camera).

I’ve just updated this post with links to photos of the Big Visible Charts in the Energized Work Lab, accompanied by explanations from Simon Baker. Check ‘em out, they will give you ideas for your own team to use.

What a Team!

I’ve always maintained that I work for the coolest team on the planet, and most of what I try to help others learn are things I learned from and with my own awesome teammates. I don’t want to be disloyal, but the team at Energized Work raises the bar for cool. Simon Baker (@energizr on Twitter) invited me to visit while I was in London earlier this month (and he gave me permission to write this post about it). I love to visit development teams wherever I go, and learn what other practitioners do to improve software quality, so I was happy I could make the time. Mohinder Kohsla had breakfast with me that morning, and was kind enough to guide me to the Energized Work lab, as he already knew some of the folks there.

Big Visible Charts

What blew me away right off the bat at Energized Work was the creative ways they use whiteboards. One whiteboard had personas, complete with photos and bios, and assumptions. That’s not too unusual, but it’s still nice to see someone actively using personas in real life.

What intrigued me most was the way they represent their backlog for their current project as a site map on a big whiteboard. They start drawing site map for the web application they’re working on on a big whiteboard, with placeholders for each screen, and arrows showing how the navigation flows. Since this is on the whiteboard, it’s easy for them to evolve the map as the project proceeds. They overlay cards with user goals so they can identify which journeys deliver value. Screen prints of completed pages are stuck to the board over the original placeholder, along with the cost to develop it.

The team starts with minimum functionality delivered to achieve a goal, working in fast, tiny iterations. As Simon explained to me, the customer can decide based on that functionality and what it cost whether to invest more in that user goal, for example, to “enrich the feature with more functionality”. The site map / backlog is part of the team’s mechanism which allows the customer to decide “just in time” whether to “go deep or broad” every week in response to user testing.

The Energized Work team has experimented with different ways to do story/task boards as well. Instead of a traditional Scrum task board or Kanban board, they represent each story with a big square on the whiteboard. In the middle of the square is a story card has some high level acceptance tests written on the back. Surrounding it is plenty of space to draw mock-ups, prototypes, write questions, write down test cases, whatever they need to discuss or do. A team member only has to look at the board to see story requirements.

Instead of moving cards from column to column, eg. from “Work in Progress” to “Verify”, they represent the vertical slicing of the story with different colored dots, representing feedback from different activities including customer review, UX reviews, and manual exploratory testing. Some cards may cycle through coding, testing, reviews, and back to coding several times before they’re done. Gordon Conroy, the tester, keeps an eye on the “big picture” as new functionality is created slice by slice. He was so knowledgeable about all aspects of the project, it’s clear he works constantly together with the rest of the development team. If companies with separate test teams could see this in action, they’d get why testing can’t be a separate phase or done by a separate team!

My own team uses a fairly standard task board with rows for stories and columns for status, and we write high-level requirements and questions on a separate whiteboard. We also work in these fast, tiny iterations with multiple slices of each story, and I am wondering if we can borrow some of these ideas to better represent that visually. We put more details about slices, test cases and specifications on the team wiki, but developers don’t always look at the wiki. Of course we also do specification by example with executable tests, but whiteboard drawings and notes would make a good, quick-to-access supplement during development. I’ve told my team everything I’m writing here, and we’re ruminating on how we might experiment to improve visibility, while keeping our remote teammate involved.

Another Big Visible Chart in the Energized Work lab lists usability heuristics. Clearly, no aspect of software quality is neglected here, and there were so many visual reminders to keep the team on track. Just about every problem my team has experienced, we solved by making it more visible, and seeing how well another team accomplishes this is affirming.

Driving Development with Tests

The Energized Work team are clearly expert practitioners of TDD and specification by example. They showed me the continuous builds in Jenkins for a couple of different projects, it looked a lot like what my own team does. I’ve personally met few teams that have as sophisticated a build job set-up as ours. I found it interesting that they’ve used different test frameworks and tools on different projects, they are clearly committed to finding what works best for each situation, and experimenting with new approaches. Some of the tools they use are new to me, such as Spock for unit testing Groovy and Java, using a BDD-style syntax.

All database changes and data migrations are automated, kept under source code control and managed with Liquibase. This is one area where my own team could improve, so it was helpful to see this in action.

Gordon Conroy showed me some clever solutions they’ve come up with to test having many concurrent users testing realistic situations, and how they can monitor these scenarios as the automated tests run.

Customer Collaboration

They explained how they work with their current customer. He comes in several days a week to collaborate with all team members, including developers and testers, and answer questions. The customer’s goal is to have a website to show potential investors, so a lot of effort goes into the look and feel and showcasing the functionality. The customer gets continual feedback from tests and from the backlog site map, and in turn is able to review the work completed so far and give feedback to the development team on what changes are still needed. I wish I could have met the customer because I’m betting he is truly delighted (as we want all of our customers to be!)

Continual Improvement

Most of all, I admire the Energized Work team’s obvious commitment to always finding better ways to work, even though they are already functioning at such a high level. They had just experimented with using causal loop diagrams for their retrospectives, to help them identify behaviors and invisible work. They told me that they aren’t just trying to improve the process within the system, but better understand the system itself. As a result, they’re able to make real improvements in effectiveness, not only efficiency. Here’s another example of output from a retrospective.

It was exciting to meet a team of people who are passionate about software quality, love what they do, and clearly have a lot of fun. They obviously have time to learn, innovate and experiment, which is reflected in some incredibly creative solutions to some tricky testing problems.

I’ve been telling my own teammates the ideas I brought away from my visit, and we’ll see what experiments we can think of trying. Some of our best ideas were “stolen” from other teams, and I expect in another six months I’ll be able to tell you what has resulted from my inspiring visit to Energized Work.

Everyone Focused on Quality

Janet Gregory and I, and our teams, have been practicing the Whole Team approach to delivering high-quality software for years, and working hard to explain this concept to others. It was affirming to see a team commit to a high standard of quality and then work relentlessly to keep raising the bar.

I highly recommend that you and your team visit other teams, in your own area or when you are traveling. Every team can teach you something, even if it’s “what not to do”. Visiting a team who has found good ways to produce great software shows you what’s possible in real life, and leave you enthused about trying something new to do better work.

It’s easy to forget that failure is good – if you can fail fast enough. That’s one reason agile works so well – short iterations and work transparency let us fail fast, and everyone knows when we fail. But failure shouldn’t only be seen as negative. We learn a lot more when we fail.

I recently read a great post titled “Are you building a learning suppression system by Daryl Kulak from his upcoming book. Here’s an excerpt.

What happens in organizations is that people get punished for committing sins of commission but they do not get punished for sins of omission. This shapes the mind of a person into saying “No, we better not try that,” attempting to avoid the nasty results of commission errors while ignoring the problems of omission errors, which don’t seem to cause as much havoc.

We don’t want to suppress innovation. Mistakes should be tolerated, not punished. We want a learning organization so our teams can always adapt to change, and thrive.

More on Learning from Linda Rising

Linda gave an enlightening talk Wednesday at ADP about retrospectives, and she talked a lot about having time for thinking and learning. These are my notes on her talk, so I hope I haven’t misinterpreted anything she said. You can find more material direct from her on her site.

When confronted with practices such as pair programming or retrospectives, some managers have this reaction: “We don’t have time for thinking”.

But we aren’t trying to stop, analyze the root cause of all of our problems, and fix them all. We need to do little experiments to see if they solve some problem we’re having. If the solution works, we don’t even have to know why, we can just use it. Linda compared this to tuning a musical instrument – we can make tiny changes, and these give us lots of value.

Linda quoted Tom DeMarco’s book, Slack. You can’t learn or change if you have no slack. Linda cited research showing that not being able to express feelings and thoughts in the normal course of business weighs us down, slows us down. It sounded a lot like technical debt to me! We fret about things that aren’t going well, and if we don’t get a chance to experiment with ways to improve them, we become less and less productive, more and more unhappy.

Going back to that idea that we must tolerate failure, it’s important that we don’t criticize or blame our teammates. Every team member should feel safe to raise issues and propose ideas. Linda cited Norm Kerth’s prime directive for retrospectives: We must believe that everyone did the best job he or she could, given what was known at the time. Everyone used their skills and abilities, the available resources, to their best advantage, given the situation at hand. When we start from there, we can avoid pointing fingers, and simply try to learn: what’s going well? What’s not going so well? How can we improve? What still puzzles us?

Linda advises us to watch for stereotypes: “These people are just no good at…” She was talking in the context of retrospectives, but this is good advice for everyday work. We even stereotype ourselves. We have to believe, instead, that we can get better. Then we will.

Focus on experiments. Identify the next experiment, and ask the three questions about it at the next retrospective. Share knowledge. Look for patterns.

Time to Learn

As Linda noted, everyone says they want to learn, but few take the time to do so. Take some time to learn something new today. See what you can do to promote a learning culture within your organization. Show your manager the Google 20% rule, and the value that Google has derived from that! Lots of companies, big and small, have something similar: Wiki Wednesdays, Engineering Sprints, one hour per day devoted to professional growth. People on agile teams love learning, and it makes us happy. When we’re happy, and when we are always learning and experimenting, we can do our best work. To me, that’s what agile is all about.

My own dressage trainer tells me all the time, “It takes a million repetitions to change a bad habit.” That’s only a slight exaggeration in my case. I remind myself (and she reminds me) about 50 times a ride to correct each bad habit, for example, to put my hands closer together and keep them centered over the horse’s withers. Some of my bad habits are 50 years old, so they’re hard to fix, but I’m slowly getting better.

Discipline is a critical component of delivering high-quality software, too. We need to thoughtfully plan to use the right practices for us. We need to remind ourselves every day, via big visible charts, information radiators, retrospectives, any means that works to learn new good habits and reinforce the things we do well.

During a recent estimating meeting, our product owner (who normally knows better) asked, “About 6 weeks ago you estimated this XYZ story at 5 points. Is there any cheap, hacky way to do it for one point?” One of the developers responded, “Possibly, but we are not going to do a cheap, hacky solution”. It’s tempting to cut corners to meet a business need, but hacking in a quick fix that increases our technical debt down the road isn’t the way to do it.

Another example where discipline and good habits came into play occurred in this morning’s Scrum. A couple of the customers brought up a significant piece functionality that they had accidentally omitted from a story we’re already working on. It was tempting to say “OK, we’ll add that in too.” But it was too big a change to put into the story at this late date. We discussed possible workarounds, and one of the customers came up with one that would do the job. They will write a new story, and if we can, we’ll pull it in this sprint. If not, they’ll get it two weeks later.

Sometimes we do make compromises about quality, and implement a solution that is less than ideal. There are always business trade-offs to consider. But we don’t make these lightly. And even after more than five years of agile development, we spend time on a serious retrospective every iteration, and work hard to keep improving the way we work and the quality of our code. Some of our bad habits have been hard to fix, but we keep working at it. Our business continues to grow, which to me is the best feedback about our disciplined approach to keeping up good habits and eliminating bad habits.