I’m honored and grateful to be the first interviewee in Yves Hanoulle’s “Who is…” series. Do any of my answers surprise you?
The Real Me, with Chester and Ernest at the Brewpub
I’m looking forward to learning about lots of people in this series!
My teammate Nanda Lankalapalli lives in India. We combined our experiences working as and with remote team members in an article, “Making Tele-Teams Work“. I’m extremely proud that it’s the cover article for the May/June issue of Better Software! Please share your experiences working on “tele-teams”.
If you think conferences aimed at programmers are only for them, think again. I wrote about my experiences at ACCU 2011 on TechTarget. Take a chance and try a conference that doesn’t seem tailor-made for you!
My first blog post on the new Techwell site (a site provided by the same people who bring you Stickyminds) tells the story of how my team recently tried an experiment to get the business and the Product Owner to give us requirements, mock-ups and other information about user stories before we do our sprint planning. Part of this experiment was inspired by our use of MercuryApp (itself another experiment, to improve our ability to learn from our retrospectives). Read more on my Techwell blog.
I was pleased to learn that my StarEast talk on an agile approach to defect management generated more discussion on the topic at the conference. Please read Gojko Adzic’s new post “Bug statistics are a waste of time” – it shatters a lot of illusions that organizations treasure about defect tracking and bug metrics.
I’m grateful to the Software Testing Club for asking me to report my experiences at StarEast. It was fun to do and will help me remember what I learned and what I want to try now as a result!
I’ve just been struggling with a title for this post. Some of my ideas were: “Visibility Taken to New Heights”, “Yes, There Are Teams Who Do This Just Like In the Books”, “A Real Commitment to Continual Improvement”, “Inspiration”, but none of them really capture my amazement at what I saw visiting the team at Energized Work in London. Finally it struck me that this team embodies the Whole Team approach to software development in a way that I’ve rarely seen.
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.
The latest issue of Agile Record is out, and includes some terrific articles by Gojko Adzic, Jurgen Appelo, Ellen Gottesdiener, Johanna Rothman, Linda Rising, Catherine Powell and several more – what an incredibly talented and diverse group of contributors! My “Agile Testing in Real Life” column is about practicing our software development (that includes testing) skills. I like to lead by example, so in this article I recount everything I’ve done so far this year to grow my own skills and become a better software tester.
To what are you devoting your 10,000 hours of practice?
Yesterday I had a call from a participant in my recent BayAPLN session. I completely screwed up and, when I tried to save the phone message, I deleted it, and somehow the number that my phone saved, I could not call back. So, I’d like to try to answer the question, as best I remember it, here. If you still have questions, please email me, because this is such an important topic.
Since I listened to this question in my car and could not write it down, I don’t have it exactly, but it was along the lines of: “My team has no automated testing. One of our user stories did not have all the testing completed by the end of the sprint, because there was not time to complete the manual tests. Would you please recommend tools to help us?”
I know of a lot of great testing tools, GUI drivers and frameworks. If you want to do GUI testing, you can’t go wrong with Canoo WebTest, Selenium, Watir. Robot Framework, FitNesse and other frameworks can be used for testing at the API level or combined with a driver for testing through the GUI. Those are just a few examples of what’s available. Even better, your team can write its own testing frameworks and harnesses.
But tools aren’t the point. The point is that the best people to solve your testing problems is your own development team. By “development team”, I mean programmers, testers, BAs, DBAs, sys admins, everyone involved in delivering software. If you aren’t delivering user stories in a sprint because testing isn’t finished, you need to look at that problem as a team. By bringing all your team’s different roles, experiences and viewpoints to bear on this problem, you will think of experiments to try, and you will arrive at solutions.
Give yourselves time to experiment. Engage everyone involved in delivering software in solving the issues of getting all testing activities done each sprint or iteration. This diversity of viewpoints means you will eventually succeed. YOUR TEAM can solve this problem. Give it a chance!
On March 24, I facilitated a workshop at Agilistry Studios in Pleasanton, CA, on Learning for Testers. 19 practitioners from the Bay Area got together to consider how, as testers, we can learn ways to contribute more to our teams, as well as raising the bar for our profession. I’d like to share some of the ideas generated by this engaging group!
Why We Should Learn
We started out by considering good reasons that testers should learn. Participants self-organized into groups, brainstormed ideas, and each group chose their top three ideas to share. Some of the items surprised me. One reason to learn was “to reduce stress”. I asked the group to elaborate. They pointed out that it is stressful if you aren’t sure whether you have the appropriate skills to do your job. That is so true, I have felt that stress before!
Another category of reasons that resonated with me was “to have fun” and “not to be bored and have ADD”. Finding joy in our work should be our highest priority IMO!
Rather than take up room on this page, I invite you to see the photos of the actual results on my Picasa site.
What We Should Learn
I love the Bay Area, it is truly a crucible of software creativity. It is no surprise, therefore, that the ideas of what to learn were surprising to me.
“Knowing when to stop” – wow, so true. Any good tester can find things to test forever. When have we achieved the “minimum”? What is “enough”? Given that in real life, we have time and resource limitations, this is a crucial skill.
“How to invent test ideas” – cool!
“Deciding what is most important to test” – that kind of ties in with “Knowing when to stop”, I think. Knowing how to analyze risks, learning customer and user priorities, these are necessary skills for testers.
I was glad to see “thinking skills” were a priority, such as: Communication, Integrity, How to Teach. Integrity is particularly interesting to me. It’s essential, but how do we learn it? How do we teach it? Comments, please!
Another interesting skill to learn was the “Elevator Pitch”. If you can describe what you do in under a minute, you must really understand it. This exercise produced many intriguing skills – please check out the photos of the sticky notes.
How To Learn These Things?
I think the most innovative ideas in this workshop surfaced during the “How To” brainstorming.
Consider this: “Note your assumptions. Later, compare what happens to your assumptions. When you stop, note your reasons for stopping. Mindfulness.” I don’t know about you, but I am going to try this.
Journalism class, to learn how to make elevator pitches – what a great idea! We have to go outside our profession to get skills that will help us do our best work.
Risk taking – set out to fail! This takes a lot of courage, but failure is a great way to learn, so why not?
And finally, my favorite, “Learn by doing”. Isn’t that the best way? But to learn, we need time. If we’re always focused on meeting deadlines, we won’t absorb any learning.
Make some room today for learning. Your team has the best solutions to your problems. You just need to take the time to talk about them and think of small experiments (as Linda Rising says) to address them.
My colleague and co-author Janet Gregory and I have a new article in this month’s Better Software about Learning for Testers, with some additional material on Techwell.com. We’d love to know what you think, please comment!
Agile testing practitioner and coach
