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).

The first open space session I attended was on Systems Thinking, facilitated by Ken Furlong. I didn’t understand a lot of this, and there were some skeery formulas, but some folks tweeted some links to me to learn more about it.

Net-Maps

Net mapping is my biggest takeaway from ACCUS so far. Eva Schiffer, whose background is in things like working with GMOs in Ghana and not IT, created net mapping to identify different people or organizations that influence a project. You identify the players: people, departments, groups. You draw connections with color-coding between them, for example, hierarchies, funding, conflicts, adversaries, being in it together. People can do the maps together.

Stacks of checker-like objects piled on each influencer denote the amount of influence. This is a great visual. If you’re doing this with a group, rather than denote “positive” and “negative” influences, you could choose two more neutral goals, such as “stability” and “change”, so that people feel safe. Eva noted that the “average view” of who influences what doesn’t do anything for you, you have to let each person explain their viewpoint.

I’m such a fan of mind mapping, and this seems to take it to another level. I am eager to try this.

One of the participants, who is from the education profession (not IT), suggested it would work well for kids, for things like exploring peer pressure. It was so interesting to get perspectives from people outside of IT, both leading and participating in ACCUS sessions.

More than Agile

George Dinwiddie facilitated this session on what agile coaches need to know besides agile. Many skills we talked about were what Isabel Evans calls “thinking skills”, other people call them “soft skills”: facilitation, creating space for the development team, PR, team dynamics, teaching people outside the team to support the team rather than trying to “drive”. We talked about ways to help teams learn to self-0rganize: providing gentle direction, helping form the team, helping them take on achievable challenges. One tweetable quote from this session was “Trust goes in, pride goes out”.

I was lucky that our team had Mike Cohn for our manager/coach for the first year of our agile transition. First he helped us decide on our commitment to quality. We committed to delivering the best quality software that we possibly could. Mike helped us make this commitment mean something. He exhorted us every day to write code that we’d be proud to take home and show our moms. He told us over and over, “I don’t care how much you get done, or whether you meet some deadline. I only care that you produce the best quality that you can.” It took a long time for the team to trust this message, but once we did, we invested a lot of time to learning valuable practices such as test-driven development and specification by example. This investment paid off in the ensuing years, as we built up a good base of re-usable code and test code. We have always kept our technical debt at a manageable level, and as a result we have a good steady velocity.

QWAN: Providing basic agile knowledge online, for free

Olaf Lewitz explained the idea of a free interactive course to teach agile basics, called QWAN (Quality Without a Name). This effort was partly inspired by the Kahn Academy. We brainstormed the what, how and why of this community effort, and came up with both ideas and questions. Check out the photo.

Mike Sutton moving cards on talk task board

We did a lot of fun exercises, and had lots of opportunities to do the “failure bow” (similar to “How Fascinating” in Language Hunters) we learned from Tobias in the warm-up this morning. We encountered so many things that happen on software projects. For example, when we had to draw a picture by committee, each person had a different viewpoint on the picture and a different idea of what we were drawing.

Ball Flow Game

Next, I joined the Ball Flow Game facilitated by Olaf Lewitz and Gerry Kirk. This turned into a hilarious example of “too many cooks in the kitchen”, in my opinion. Just try to get a bunch of agile coaches together and get something done! We started out really well, producing the inventory of “magic balls” efficiently, in just over one minute.

Then, naturally, since we had done pretty well, we changed everything at once and came up with a totally new way to “deliver” the magic balls. My personal estimate of five minutes was not too far off the real result. It was a good opportunity to reinforce the fact that it is better to do small experiments and only change one thing at a time than to do a drastic reorganization.

Attempted Game Development

Paul Boos, one of the ACCUS organizers, was kind enough to let me take a slot in the agenda to get help in trying to develop a game that would teach tester-developer collaboration. My goal was a quick game that would teach testers that it’s not a bad thing to test early and often, and teach programmers that it’s valuable to have testers involved throughout development. I can’t afford Legos and I don’t like to check my bag when I travel, so I wanted to do something with a construction kit that uses plastic straws (similar to drinking straws) and connectors.

Some participants created works of art!

A wonderful group of people came to help. They started throwing out ideas, and it first, it seemed there was no way I could create the kind of game I wanted with the straw kit. While they brainstormed, participants built some awesome straw constructions, proving that using our hands does help us learn and think!

It turned out that you can build a lot of two-dimensional shapes with the straws: squares, rectangles, circles, arches, hexagons, lips. The group proposed that the first part of the game would be for each team to build all the shapes. These could be “tested”. In the second phase, each team would put the 2D shapes together into 3D shapes, and try to build the biggest structure that could hold its own weight when picked up. This also would encourage incremental testing.

An additional idea was to throw in “hidden requirements”. For example, when the facilitator comes around to verify the 2D shapes, she could say, “That is indeed a square, but I forgot to tell you, all the straws in the square must be blue.” This would simulate a real-life project.

This isn’t the quick game I envisioned, but it has potential, and I think it’s worth trying out. Thanks to everyone who helped me, I’d never have thought of this on my own! Collaboration rules!

I’m looking forward to Agile Coach Camp and more learning, insights, and friends.

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.

I’m currently reading some draft chapters of Jurgen Appelo‘s upcoming book. His work is affirming my belief that successful software projects are the result of getting good people and letting them do their best work. There are so many aspects to this – reading Jurgen’s work, I am starting to understand that people are the most complex component of any project! Everything hinges on our ability to innovate, to be creative. So, we must be a community of thinkers.

One item in this list urges us to embrace newcomers. I was welcomed into the agile community 9+ years ago. I work hard to pay that nurturing forward, so that others may experience gaining knowledge that in turn drives their creativity. And besides all that – why not always be nice to each other? I feel another blog post coming on.

A Community of Thinkers

I am a member of a community of thinkers.

I believe that communities exist as homes for professionals to learn, teach, and reflect on their work.

I challenge each community in the software industry to:

• reflect and honor the practitioners who make its existence possible;
• provide an excellent experience for its members;
• support the excellent experience its members provide for their clients and colleagues in all aspects of their professional interactions;
• exemplify, as a body, the professional and humane behavior of its members;
• engage and collaborate within and across communities through respectful exploration of diverse and divergent insights;
• embrace newcomers to the community openly and to celebrate ongoing journeys; and
• thrive on the sustained health of the community and its members through continual reflection and improvement.

I believe that leaders in each community have a responsibility to exhibit these behaviors, and that people who exhibit these behaviors will become leaders.

I am a member of a community of thinkers. If I should happen to be a catalyst more than others, I consider that a tribute to those who have inspired me.

”A Community of Thinkers” by Liz Keogh, Jean Tabaka and Eric Willeke is licensed under a Creative Commons Attribution-Share Alike 3.0 License. Please attribute to the distributor of your copy or derivative.