• About

aclairefication

~ using my evil powers for good

Category Archives: Retrospective

Last Family Lunch

14 Friday Dec 2012

Posted by claire in Experiences, Experiments, Retrospective

≈ Leave a Comment

It’s been a nostalgic week for me as I’m finishing up my time at Daxko today. (Case in point, I’m wearing this year’s bight purple Kickoff shirt as I type this.)

I’ll miss finding you on Twitter, displacing the printer, walks to Taco Mac, counting down my check-ins, dueling LifeSize remotes, commit message mentions, dangerous Centurion helmets, Plank A Day Nation pix, 2 drink tickets, the gangsta Ashoka Scrum-board avatar, mysterious moustaches, Monster-fueled afternoon shenanigans, Keep Calm and…, Portal references,  being kind of a disaster, Hackathons, a closet full of branded T-shirts, sticky notes everywhere, launch party, singing on the patio until we shut down the restaurant, winning The Go Game, the quote of the day, attempting Cajun accents, the Women of SWE, surprise attacks by Angry Birds, Family Lunch indecision, punchy road-trip conversations, Whirlyball, batting long eyelashes, last-minute costuming, musical parodies, calling dibs on the napping couch after family lunch – we love free food! – and most of all the people. (Special shout out to my Atlanta crew! I’ll follow you to whatever end.)

I expect to see some ridiculousness coming out of next month’s talent show, so make it count, people!

So Long and Thanks for ALL THE THINGS!

“Now, bring me that horizon.”

Seize the Initiative

15 Thursday Nov 2012

Posted by claire in Agile, Context, Experiences, Experiments, Retrospective, Soft Skills

≈ 1 Comment

Antistress Autoreverse

So last year I joined the YMCA. My employer works in this space and they supplement our memberships … on the condition that we attend with a minimal frequency. Nothing to understand your customers quite like becoming their customer! However, working out isn’t really my thing. The “race to nowhere” has no appeal for me. But I went anyway, determined to learn something. Despite my stubbornness on that point, the inertia of years of study was hard to overcome. I needed backup.

Joining the coach approach program was explicitly about wanting to make improvements. The Y coaches promote “adopting healthy habits and changing the way [the participants] live their daily lives.” I knew I wanted to make a change, but I also knew that I didn’t want it badly enough to go it alone quite yet. Having never had a personal coach, I wasn’t quite sure what to expect. What I encountered resonated with my recent experience learning about the role of ScrumMaster.

In particular the sprint activity of retrospective is “an opportunity to learn how to improve.” Defining success in this particular context was the first step. My ScrumMaster watched the process and guided it, making it okay to talk about uncomfortable topics, but it was up to me to do the work. The first big step was being able to establish a safe environment to talk with a more experienced and professional person about a potentially sensitive topic.

In the case of my workout routine, this was my minimal compliance rather than wholehearted adoption of lifestyle change. My Coach Approach coach helped me to develop a vision for the future that would be better than the past. We focused on setting goals while recognizing that the plan had to fit into my work/life balance with the loose structure of frequent check-ins rather than plugging my height, weight, and weight loss goal into a one-size-fits-all spreadsheet.

I was surprised to find that discussion about my health could be fun when my counselor was so friendly and supportive. I would have expected an intervention to be really uncomfortable. Retros can be that way sometimes. But they can also be a welcome change of pace. Roughly every 2 weeks – after we catch up on socializing and the excitement we’ve had since our last chat – my coach and I looked at the artifacts of my progress, paying attention to the time line of events going on in the background and how that influenced the results. Keeping this cadence allowed us to build a healthy relationship that encouraged risk-taking and speaking from the heart. So when my coach suggested adding a weights routine to my cardio, I felt fine with scoffing openly and she felt fine with reminding me of my goals, not allowing my emotions to derail the discussion but remaining fully present and focused.

As our meetings progressed, she offered appreciation of the progress I made, while encouraging me to try new approaches that could yield better results. Even when I felt like I was backsliding, she found a way to put more emphasis on understanding what I had accomplished and focused on encouraging me to keep going. We talked about what parts of the routine were working well, what lessons I learned (like when I hated the treadmill but loved the AMT – hey, participation in individual exercises is optional!), what I could do differently next time, and what might need more scrutiny. We tried to analyze the problems and propose solutions to the boredom, considering a variety of alternatives. It was honest but not accusatory. (Hey, eveybody gets bored with the routine.)

So I’ll admit she’s done me some good. I agree with another participant who said, “My personality is better, my production has gone up, my mental clarity has improved, and my energy level has increased dramatically.” Granted, I just have a lot of energy in general, so I wasn’t likely to sit back and passively take it in – well, as passive as you can be while sweating profusely. I started to recognize my excuses as just excuses, feeling more empowered to modify the situation, learning to manage that impulse to excuse myself from the hard work of changing. Accepting that I actually knew something about working out and lifting weights and could be responsible for designing more of the workout and analyzing my progress on the path to wellness? Yeah, last week was weird.

One ScrumMaster wrote, “At the end of a successful project, everybody says, ‘Gee, I wish we could do it again.’ Using this definition, was the project a success?” Well, I can’t say that I’ve enjoyed every moment of it, but figuring out that I could test software and sweat profusely at the same time? Priceless! But seriously folks, having my coach express sincere and significant appreciation for the care and work I put into making progress sent the message that she cared about and me personally, not just reducing the failure rate of some anonymous gym member. And that’s where the magic happens.

(Special thanks to my dev James who pointed out that coach approach is workout retro!)
Image source

Yo dawg, I herd you like ET

19 Monday Mar 2012

Posted by claire in Context, Experiences, Experiments, Hackathon, Retrospective, Testing Humor

≈ 1 Comment

I wrote out my Lab Days experience recently but didn’t get to bring you down the rabbit hole with me to experience the recursive testing goodness.

My project for Lab Days was an enhanced logging tool, but the logging is the heart of the matter, with users putting it through its paces much more stringently then the analysis functionality.

Since I usually do exploratory testing of applications at the day job and the time pressure of Lab Days left little room for formal test cases anyway, I decided to try out a new exploratory testing session logger: Rapid Reporter.

I didn’t have a lot of time to devote to learning Rapid Reporter, so I didn’t bother reading any documentation or preparing myself for how it worked, essentially exploratory testing my exploratory testing tool while exploratory testing my application under test.

It turns out this kind of recursive testing experience was just what I needed to liven things up a bit, all in the spirit of trying something new! I discovered that rapidly learning about a session logger while testing/learning a session logger, pulling log entries from an original session log, and reporting bugs via a session/chat room (HipChat) made for some perilous context-switching. More than once during the day, I had to stop what I was doing just to get my bearings.

I clearly enjoyed the experimentation because I decided to repeat the experience, though with a little less context-switching, when we upgraded our usual ET tool: Bonfire. The funniest thing about using Bonfire after working on my Lab Days project was that I realized there were tags available for log entries but the tagging indicators weren’t the same as our choice for our usability testing tool. I kept trying to use the tagging that I’d been testing all week and had to retrain myself, improving their documentation as a result of my questioning.

Still, seeing how another logging tool uses tags gave me some functionality to consider for our usability logger: how would users want to interact with tagged log entries? Clearly time to circle back with my UX designer to discuss some enhancements!

Image generated here

The status is not quo

09 Friday Mar 2012

Posted by claire in Context, Experiences, Experiments, Hackathon, Retrospective, Tester Merit Badges

≈ 3 Comments

Dr. Horrible http://drhorrible.com/

We tend to run “FedEx” with a fairly open format where you can do whatever you want as long as you can somehow relate it to our products.
- Atlassian

Last week, my company gave us an exciting opportunity: 5 days of work on a project related to our business.

Apparently, they’ve done something like this before, long before my time, so you’d have to ask some of the more tenured folks at Daxko about it.

I worked with the same folks who volunteered with me at the WebVisions Hackathon earlier this year and we kept in mind what my colleague Will said about that experience: “The short time box and no feature constraints necessitated a laser-sharp focus on one thing.”

So we noodled over several viable candidates and finally settled on building a better mousetrap – or, in this case, UsabLog.

A clarification on terminology from my UX colleague:
“Logging” in this context doesn’t mean “system logging of events.” It means human capture of what the user said, what the user did in the app (e.g., where user clicked), and any additional comments to provide context. The point of logging is to provide us with a record of what went down so we have an accurate recollection for later analysis.

I had the good fortune to be a user of the original UsabLog application over the course of many usability sessions as a session logger, so I was rather familiar with its strengths and weaknesses. I was able to contribute some bug reports and feature suggestions for consideration during our lunchtime planning discussions, but my Scrum team’s UX designer was our team’s sponsor. She compiled an experiment plan that identified our purpose and detailed the problems we considered in the pre-existing Usablog and the opportunities we had to satisfy those needs.

Our usability sessions up to this point involved an interview led by the facilitator (i.e. UX designer) and logged by another team member (e.g. me) via the free, open source, web application Usablog, which then exported logs to CSV for use in a program such as Excel and which we in turn manually fed into a mindmap program such as FreeMind. While this process did work for us, the export and manual copy-paste was rather tedious and laborious, or as she put it “it would directly contribute to user research process efficiencies.” We knew there could be a better way.

Goals of the experiment:

  • Rapidly capture rich user feedback during research interviews and usability tests through logging of user events and comments
  • Organize logs from multiple sessions into one study for ease of access and visibility
  • Use log entries to synthesize findings
  • Quickly jump to a spot in the session’s video by clicking on the associated log entry

In particular, we wanted these features:

  • Multi-session logging.
  • Log entries are timestamped when the logger starts typing for video synchronization.
  • Custom tags.
  • Multi-logger logging.
  • One tool for logging and post-session analysis.

We established a definition of done and recognized our dependencies since any impediments would have serious impact on our progress during the limited time of the competition.

I would love to tell you that we were entirely successful in meeting our goals and implementing all of our features, and then going on to take first prize in the competition. Alas, this was not to be. We only accomplished some of our goals and features and awesome projects from other teams placed above us.

However, the experiment was a roaring success in many ways:

  • I had first-hand experience with paired UX design under the tutelage of my UX designer colleague. She suggested that I man the helm and she steered me back on course when I went astray. I won’t claim that my first UI mockups were beauties, but the process and conversation certainly were.
  • I made my first commit to a Github open-source repository and thereby qualify for the Open Source Nerd Merit Badge (which happens to feature the Github mascot Octocat) which I had been hankering to do ever since I discovered its existence. Also, this was the first time I fixed a bug in the source code, so even though my changes were minor it was thrilling.
  • Exploratory testing based on Github commit notifications in the HipChat chat room we used for the team. Rather than pursuing session-based test management, I tried a looser structure based around the latest and greatest changes instead of setting charters and time-boxing exploration around the stated goal.
  • Real-time bug reporting of issues found during exploratory testing via HipChat messages and screenshot attachments was new and interesting. This is the lowest overhead asynchronous bug management approach I’ve tried and it was effective. Granted, we didn’t come out with a backlog of known issues written down somewhere, but we rectified the most critical problems before they had a chance to fester.
  • We didn’t let a little thing like heading home for the day stop us from collaborating remotely when we got back to business after hours. Being able to work at odd hours put some of my insomnia to good use. I also learned a bit about .NET and model/view/controller architecture, which turned out to be good preparation for the following – and last – day.
  • When one of our programmer teammates fell ill, I paired with our remaining developer to push on toward the goal. Although I think I spent more time asking questions to help think through the implementation than actually contributing code, it was a fruitful day, wrapping up an important feature a mere 30 minutes before the Big Reveal.
  • I used the resulting product to real-time log the presentations during the Big Reveal. Oh so meta, but also hopefully illustrative of the capabilities of the application for future use. If nothing else, it gave our sick friend a way to catch up on the excitement as he recovered over the weekend.
  • We accomplished only some of our goals and features but they were the most essential. Our product is usable as-is, though with some known bugs that do not inhibit happy-path use.
  • Why do they call it FedEx days? Because you have to ship! Our resulting application is ready for use – or enhancement if you’re feeling ambitious!
  • And last, but certainly not least, victory lunch! Nothing so sweet as celebrating effective teamwork.

Image source

This could be real good

03 Friday Feb 2012

Posted by claire in Agile, Experiments, Retrospective, Scrum

≈ Leave a Comment

It's Groundhog Day!

Something is different.
- Good or bad? (Rita)
Anything different is good…
but this could be real good. (Phil)
– Groundhog Day

I’m a relatively young ScrumMaster, so I adopted a retrospective pattern that a colleague suggested to me at the beginning of my tenure. We have been using that same approach for sprint retros for 6 months and it gets the job done. Still, I found myself bored with doing the same old thing for our release retro this month and was concerned about not getting the desired benefit from the process. So I grabbed a promising technique from the Agile Retrospective Resource Wiki called the Four L’s, which Mary Gorman and Ellen Gottesdiener of EGB Consulting developed as a variation of the World Café since they “wanted some variety in eliciting feedback, collectively sharing that feedback and exploring action possibilities.”

The wiki suggests using the Four L’s for “iteration and project retrospectives as well as for retrospection of training and conference events” with a duration of 30 minutes to 2 hours. My 6-member cross-functional team used this technique to reflect on a release and limited our time to an hour, though that wasn’t a hard cutoff. In the context of our release retrospective and the hospitable space of our team meeting room, we gathered our diverse perspectives to explore questions that mattered about how our release went. I titled each of 4 large sticky notes Liked, Learned, Lacked, and Longed For, hanging them side-by-side on a single wall, which was a variation of the suggestion to move around the room. We set a timer of 15 minutes to generate initial feedback for all 4 categories simultaneously and began scribbling madly on uniformly yellow stickies with our Sharpies. Our team ran dry of serious contributions before the time was up, but I think time-boxing activities tends to drive us to get ideas out more quickly.

We read each sticky note’s single idea aloud and then clustered the notes around themes when there was overlap, listening together for patterns and insights. Then, we discussed the whole category among ourselves, hearing out each person’s comments with understanding and humor (we don’t take ourselves too seriously) since we encourage everyone’s contribution to the conversation. We were happy with our technical skills and technologies, but more importantly we have jelled as a team, or made it through the Norming phase of Tuckman’s model. Characteristically, my team identified our successes but did not dwell on them as much as our areas for improvement. We decided we might use the gathered data to satisfy the lacked or longed for items. We posted the following collective discoveries prominently in our team room:

  • Iteration
  • Continuous Planning
  • Continuous Research
  • Communication
  • Feedback (outside the walls)

These needs resonate with some of the Agile Manifesto principles:

  • Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.
  • Business people and developers must work together daily throughout the project.
  • The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
  • Continuous attention to technical excellence and good design enhances agility.
  • At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

In our efforts to optimize our agility, we are learning from our team’s past and planning for the future so that our results could be real good.

♣ Subscribe

  • Entries (RSS)
  • Comments (RSS)

♣ Archives

  • May 2013
  • April 2013
  • February 2013
  • December 2012
  • November 2012
  • October 2012
  • August 2012
  • July 2012
  • April 2012
  • March 2012
  • February 2012
  • January 2012
  • November 2011
  • October 2011
  • September 2011
  • August 2011
  • July 2011
  • June 2011
  • May 2011

♣ Categories

  • #testchat
  • Acceptance Criteria
  • Agile
  • Agile2013
  • Approaches
  • Automation
  • CAST2011
  • CAST2012
  • CAST2013
  • Certification
  • Context
  • Experiences
  • Experiments
  • Exploratory Testing
  • Hackathon
  • ISTQB
  • Metrics
  • Podcast
  • Publications
  • Retrospective
  • Scrum
  • Social media
  • Soft Skills
  • Speaking
  • STAREAST2011
  • STAREAST2012
  • STARWest2011
  • Tea-time With Testers
  • Techwell
  • TestCoachCamp2012
  • Tester Merit Badges
  • Testing Circus
  • Testing Humor
  • Training
  • TWiST
  • User Stories
  • Volunteering
  • Weekend Testing

♣ Meta

  • Log in

Proudly powered by WordPress Theme: Chateau by Ignacio Ricci.