Monthly Archives: June 2015

Shift Left: Testing Earlier in Development

Posted on by
Reply

One candidate for best experience report at XP 2015 was “High Level Test Driven Development – Shift Left” by Kristian Bjerek-Gustuen, Emil Wiik Larsen, Tor Stålhane, and Torgeir Dingsøyr. Their report describes testing strategies and tactics used on a large-scale IT development project in Norway. These authors called it “shifting left” because they wanted to move testing to as early as possible in development.

Their project was complex along several dimensions.

Coordinated work among independent teams: Several vendors were simultaneously developing and delivering systems that communicated with each other via service interfaces. Vendors did detailed design and development including unit, integration and sprint system testing of their deliverables. This work had to be integrated by the company. They performed acceptance testing after every sprint, system integration testing which ran in parallel with the vendors’ sprint system tests, as well user acceptance testing.

Significant coding and testing effort: Over 100,000 hours of testing and development went into the release.

Time pressure and project criticality: The delivery date was fixed. The system was an extension of an existing system for processing payments. It had to be delivered on time and with high quality.

The duration of the project they described was roughly 40 weeks, if I read the report correctly: 12 3-week sprints followed by 6 weeks of system testing. Faced with a time crunch, an existing group of 3 maintenance scrum teams were scaled up to 11 teams over four months. The customer who was receiving the software system didn’t have fulltime resources to dedicate to the scrum teams who were comprised of these roles: scrum master, developer, functional architect, technical architect, and QA/tester. My guess is that the customer was called upon as needed to provide clarifications, offer feedback at sprint demos, and to do all necessary testing and integration testing.

To ensure that each team had efficient and sufficient testing and quality assurance, a dedicated QA person/tester was assigned to each team. This reminds me of Stephanie Savoia’s experience report at Marchex where they embedded testers into their dev teams.

In the case of this Shift left report, the dedicated QA person (I prefer the term quality advocate) seemed very busy and vital: they ensured the quality of design documentation; decided whether the implementation was testable; prepared test data; worked with devs and the Scrum master to ensure high quality code. They also made sure test activities were performed as early as possible and that the customer provided necessary clarifications to the dev team.

Bridge, go-between, quality advocate, tester extraordinaire!

During sprint demos, in addition to demonstrating new functionality, teams also provided information on how testing was performed and any issues they had encountered in testing the implemented functionality.

There is more in the report about how they managed testing and dependencies between teams, identified and tracked high-risk modules changes and defects to aid test and development planning, and introduced exploratory testing using interdisciplinary teams. But I digress.

Back to those busy QA advocates. Not surprisingly, the experience reporters mentioned in passing that the dedicated QA advocate became one of the most central resources for the teams.

It seems that they were deeply appreciated by the whole team. That’s important. Where they ever overwhelmed by their responsibilities? Were they overworked?

Any experience report never answers all questions I have. I still find them thought provoking. Even though I’d love to sit down and talk with experience reporters and ask them more questions.

One pattern Joe Yoder and I have written about in our Shifting From QA to AQ pattern collection is called Pair With A Quality Advocate. If you purposefully pair up devs or other folks with a QA advocate, their expertise can “rub off” on less skilled/experienced testers and developers. Steadily (and sometimes stealthily), a quality mindset gets infused into the entire team. You still need quality advocates, but everyone takes on more responsibility for quality. And that’s a good thing.

Future Commitment

Posted on by
Reply

In early April, I spent a fun weekend at Pace University with Allen Wirfs-Brock and Mary Lynn Manns speaking with students of Pace University’s Doctor of Professional Studies in Computing program.

Mary Lynn

Mary Lynn Manns

It was a good opportunity to reconnect with Mary Lynn and to hear about new patterns in her latest book, More Fearless Change: Strategies for Making Your Ideas Happen.

Mary Lynn and Linda Rising have been working on these patterns for over a dozen years. They aren’t finished (curating long-lived patterns is an ongoing task). They continue to collect and write patterns for those who want to initiate, inspire, and sustain change in organizations they are part of or in their personal or professional life.

There isn’t one magic thing to do to institute change. Mary Lynn and Linda advise,

“You are working with humans, often in complex organizations, so results are rarely straightforward and the emergent behavior might be totally unexpected. Therefore, upfront detailed planning is rarely effective. Instead, take one small step toward your goal and see what happens. You will inevitably encounter missteps and failures along the way….uneven progress can be discouraging but may also teach you about the idea, about the organization, and, most of all, about yourself.”

Significant change often includes performing an ongoing series of experiments.

One new pattern (or strategy) in their book is Future Commitment. This one has hooked me many times.

Instead of asking a busy person for immediate help, ask them do something you need later and then wait for them to commit. Don’t worry about trying to get them to agree right away. Be patient. Keep in touch. Provide them regular information that encourages them to become more interested in your change initiative. Don’t be a pest.

Once they agree to help, solidify their commitment by recording the date and sending it in writing (along with gentle reminders so they are kept aware of their commitment). Reminders can be annoying. So include an update of what is happening and how their contribution will fit as part of a reminder. Have an alternate lined up in case that busy person can’t commit. There’s more to this strategy and the psychology behind how people commit (along with 14 other new strategies) in their book.

Like Mary Lynn and Linda, I don’t view change patterns as evil or manipulative. They are simply tools, that once aware of, you can use to engage people and get them to help you make changes.

And so here’s a future commitment if you have an urge to write about your agile experiences: We need experience reports for Agile 2016. Submit a proposal to the Agile Experience Report program. Do it soon. Within the next 30 days.

You don’t have to start writing now, but if you send in a proposal to me, it will grab my attention. Even better, if you are attending Agile 2015, we can also talk over your proposal. We ask that you write up a proposal so you get in the practice of collecting and communicating your thoughts in written form.

You could wait and submit your experience report idea via the Agile conference submission system in November. If you do, your chance of it being selected is limited. The format of the submission system makes it difficult to include details or have an ongoing conversation to sharpen your ideas. This year we had maybe 100 submissions from which we selected 20.

If you wait to submit your proposal via the conference system, it will have to really stand out from the crowd to grab our attention.

Instead, if you submit your proposal to the Agile Experience Program, it will be carefully read as soon as we receive it. If selected, we will work with you throughout the coming year. You don’t have to start writing immediately. You will get help from a shepherd as you write. As soon as you finish, your work will be published on the Agile Alliance website. You will be also invited to present your report at a future Agile conference.

I’m ready to help you write about your experience if you are ready to make a future commitment to writing. It all starts with your proposal.

Mob Programming: The Unruly Experience

Posted on by
Reply

This year 11 experience reports were presented at XP 2015. As co-chair of Experience Reports, along with Ken Power, one of my last tasks was to select a best experience paper. That was hard. We had several good experiences to choose from (I’ll report on more of them in future blog posts).

Ken Power and I independently read and reviewed each paper. At the conference we compared notes and agreed on 3 papers we would consider for this award. We also reviewed the authors’ presentations before making our final determination.

The best experience paper was awarded to Alexander Wilson for his report, Mob Programming – What Works, What Doesn’t. One thing that made this paper stand out, was its balanced view. Alex is clear about things you need to watch out for when and if you try mobbing—don’t be lulled into groupthink and be aware of overly dominant personalities.

Alex Wilson telling us about Mob Programming

Alex Wilson telling us about Mob Programming at XP 2015


He also gave us a close look into his company’s mob programming experience.

Mob programming is where a team of programmers swarm on a problem. They work together instead of pairing or individually writing code. One person is at the keyboard, the rest of the team helps navigate. They pay attention and guide the person at the keyboard. Team members take turns at the keyboard. When mobbing, there are more eyes on the code and more minds focused on the problem you are trying to solve.

Folks at Unruly were inspired to try mobbing after Woody Zuill talk at JavaOne in late 2014. Woody also spoke about Mob Programming at Agile 2014. You can read Woody’s experience report here.

Developers at Unruly were seasoned XPers accustomed to pair programming and test-driven development. They are responsible for the entire lifecycle of their product, from research to operational support. They are in constant touch with problems and ongoing sustainability of code they write.

They decided to form a mob to work on performance enhancements to their existing product. This involved refactoring and reworking critical code. If they made mistakes, it could result in lost data and have serious financial impacts. Mobbing for them wasn’t just a casual experiment.

After mobbing one day per week for a couple of months they found, in general, that they were pretty happy with their results. After 5 months they concluded that they don’t prefer mob programming for all user stories. They do find mobbing beneficial for complex work (where there is the potential for errors) over complicated work (where the solution is known, but is merely time consuming). They also find that tasks that are dull or repetitive were likely to cause their mob to dissolve. They only mob one day a week, unlike Woody’s team who mobs every day.

Unruly settled on a rhythm of periodic mobbing that worked for them. That’s what I like about Alex’s report. He tells us: here is what worked, here is where we tripped up, here is how we adapted our practices, and here is what we’re doing now.

Teams in learning organizations perform ongoing experiments. While they settle on a core set of practices, they also try to build upon them. They keep innovating, improving, and reflecting. And how they work continues to evolve.

What does karaoke have to do with being agile?

Posted on by
Reply

Last week I attended XP 2015 in Helsinki, Finland. This is my second time there…I hope to go next year, too. It is a unique blend of researchers and students along with people working in big and small companies doing all kinds and flavors of agile development from all over the world. 37 countries were represented. We had 11 experience reports (Ken Power and I were track co-chairs of experience reports. More about them in another post).

Lots of learning. We had fun, too.

One of the highlights of the conference banquet was Presentation Karaoke. 6 brave souls gave 3 minute impromptu speeches. Every 30 seconds a new, unknown slide appeared.

Llewellyn Falco’s PowerPoint karaoke at XP 2015


Here’s video of parts of a presentation by Llewellyn Falco.

Avraham Poupko won the competition by popular vote. Pardon the shaky camera…I was laughing and not holding my cell phone very steady ….

So what’s connection between PowerPoint karaoke and agile development? Each speaker ostensibly spoke on a conference theme. Mostly, they had fun. High performing agile teams, like these speakers, know how to roll with the punches. Sure there’s a theme, a plan, a backlog of work items. But sometimes requirements change and you need to adapt on the spot. Rather than throw up your hands or panic, you need to make things work. It is impossible to go with the flow if you are in a panic. Like improv, agility demands that you accept change. Unanticipated things happen. You accept them and you adjust.

Some speakers made connections between slides. Avraham spotted what he thought were mangoes on the head of someone on one slide and incorporated them throughout his talk. Giovanni summarized all the key points at the end (it is a wonder he remembered them…but again, he wasn’t in a panic). Llewellyn was master at dramatic pauses before finding something to say. Their presentations were great.

Next time you are faced with unexpected change, take some cues from these improvisers: pause, gather yourself, take stock of the situation and then figure out what you need to do. Don’t panic. You’ll get through it. And maybe with a more relaxed attitude you’ll even have some fun.