• About
  • Giving Back

aclairefication

~ using my evil powers for good

Category Archives: Agile

Minimum Viable Product Manager

29 Wednesday Aug 2018

Posted by claire in Agile, Agile2018, Approaches, Context, Experiments, Metrics, Protip, Retrospective, Scrum, Soft Skills, Training, User Stories

≈ Leave a Comment

At Agile2018, I attended Richard Seroter’s Product Ownership Explained session, where I heard about bad and good product owners. Product ownership/management has many facets including

  • advocating processes and tools
  • style of leadership
  • customer interactions
  • relationship with engineers
  • approach to continuous improvement
  • product lifecycle perspective
  • sourcing backlog items
  • decomposing work
  • running through a sprint
  • meeting involvement
  • approach to roadmap
  • outbound communication

Now I’ve been working alongside many customer proxy team members (e.g. business analyst, product owner, product manager) over the years. I’ve learned how to create testable, executable, deliverable user stories in a real-world setting. I wasn’t going into this talk blind. I just haven’t always focused on the Product role.

This time, I looked at the role with the mindset of what it would take for me to check all the boxes in the “good” list. As each slide appeared, my list of TODOs lengthened. I started to feel overwhelmed by the number of things I wanted to improve…

“How you doin’, honey?” “Do I have to answer?!?”

I walked out of that talk thinking I’m not sure I want to sign up for this epic journey. The vision of the idyllic end state was more daunting than inspiring. How could I possibly succeed at this enormous task? Would I want to sign up for that? My initial reaction was no! How could I take on all the technical debt of stretching into a new role like Product? How long would the roadmap to “good” take?

Analysis

When I evaluate things off the cuff, I often consider good-bad-indifferent. Maybe knowing what “good” and “bad” look like wasn’t helping me. I knew I didn’t want to be merely “indifferent”… maybe what I really wanted to know was this:

What does a minimum viable product manager look like?

One of my big takeaways from Problem Solving Leadership (PSL) with the late, great Jerry Weinberg was limiting work in process (WIP) or “one thing at a time” (as close to single piece flow as possible) improves effectiveness. If I take that approach to a PO/PM role, I’m afraid that I would completely fail. So I will reduce the practices to as few as I possibly can without completely losing the value of the role. I want only the *critical* path skills or capabilities! Everything else can be delegated or collectively owned or done without. So what can I discard?

In this thought experiment, I’m proposing finding the least possible investment in each essential aspect of the PO/PM role that would move from bad past merely indifferent to viable (but only just!). I needed to reduce my expectations! If I allow minimum viable to rest somewhere in my default scale, then it fits between indifferent and good. That means I deliberately do *not* attempt to inject all of the good practices at once. So let’s revisit the axes of expertise and the lists of behaviors that are good and bad…

What’s the least I could do?

Decomposition

Advocating processes and tools

Good: contextual & explanatory & collaborative (fitting process to team + pragmatic tool choices + only important consistency + explains process value + feedback leading to evolving)
Minimum viable: pragmatic minimalism (choose a simple process & let practices earn their way back in as value is explained + choose an available tool + allow consistency to emerge + request feedback)
Indifferent: status quo (follow existing process/ceremony w/o questioning + let others choose tools + don’t justify)
Bad: dogmatism (one practice fits all + adhere to ceremony + prescribed toolchain + standardization + trust process + don’t justify)

Style of leadership

Minimum viable: leads by example (models behaviors for others without trying to modify their behaviors) + doesn’t worry about respect + consultative decisions + experiments/loosely decides + sometimes available to the team but not constantly + flexible + defaults to already available metrics

Customer interactions

Minimum viable: meets with customers at least once + builds casual relationship with a key customer + gets second-hand reports on Production pain + occasional customer visit + default information sources

For me, this one slides a bit too far toward indifferent… I’m not sure how little I could care about customers and still get away with being acceptable at PO/PM…

Relationship with engineers

Minimum viable: physically co-locates when convenient + T-shaped when it comes to the technical domain (i.e. aware but not trying to develop that skill as an individual contributor) + attends standup + shares business/customer/user information at least at the beginning of every epic + champion for the product & trusts everyone on the team to protect their own time

Approach to continuous improvement

Minimum viable: default timebox + takes on at most 1 action item from retrospective, just like everyone else + plans on an ad hoc/as needed basis (pull system) allowing engineers to manage the flow of work to match their productivity + prioritizes necessary work to deliver value regardless of what it’s called (bug, chore, enhancement, etc)

Product lifecycle perspective

Minimum viable: tweaks customer onboarding in a small way to improve each time + cares about whole cross-functional team (agile, DevOps, etc) + asks questions about impact of changes + allows lack of value in an existing feature to bubble up over time

Sourcing backlog items

Minimum viable: occasionally talks to customers + cares about whole cross-functional team (including Support) + backlog is open to whole team to add items that can be prioritized + intake system emerges + tactical prioritization

I do have twinges about the lack of strategy here, so I guess I’m looking at this part of minimum viable Product *Owner* (i.e. the mid-range focus that Richard points out in his 10th slide).

Decomposing work

Minimum viable: progressive elaboration (i.e. I need to know details when it’s near term work and not before) + thin vertical slices and willing to leave “viable” to the next slice in order to get a tracer bullet sooner + trusts the team to monitor the duration of their work & to self-organize to remove dependencies (including modifying story slicing)

Running through a sprint

Minimum viable: doesn’t worry about timeboxes (kanban/flow/continuous/whatever) + focus on outcome of each piece of work (explores delivered value) + releases after acceptance (maybe this is just continuous delivery instead of continuous deployment, depends on business context)

Meeting involvement

Minimum viable: collaborates with team members to plan as needed (small things more often) + participates in retrospectives + ongoing self-study of PO/PM

Approach to roadmap

Minimum viable: priorities segmented by theme + roadmap includes past delivery/recent accomplishments + adjusts communication as needed/updates for new info + flexible timeline in a living document + published roadmap accessible to all stakeholders on self-serve basis

Outbound communication

Minimum viable: allows org to self-serve info + shares priorities with manager & customers + environment for continuous self-demo/trying features + transparency

What are the minimum viable versions of the tools of a product owner?

  • Backlog – list of ideas not fleshed out until it’s time to run them
  • Sprint planning – ad hoc meetings in a pull system initiated by the need for work definition to execute
  • Roadmap – technical vision of system capabilities + compelling story of the product value proposition
  • Prototyping, wireframing – whiteboard pictures + text-based descriptions
  • Team collaboration – a big TODO list that everyone can access
  • Surveying/user testing – chat program that both team & user can access
  • Analytics – NPS score informally collected from customer conversation
  • Product visioning – I think this goes in with Roadmap for me?

So I’ll agree that the PO/PM role is critical and necessary. I would like for creative problem solvers to fill the role – and to be fulfilled by the role! In order for that to be viable, for people to grow into a Product role, there needs to be education on how to begin – and it can’t be spring-fully-formed-from-the-head-of-Zeus! Christening someone PO/PM doesn’t endow them with sudden wisdom and insight. Skill takes time to develop.

Set realistic expectations for beginners. Help teams to welcome people to grow in the role by offering both challenge and support from all the team members. As with any team need, the agile team has collective ownership to solve the problem, not relying on a single point of failure in the role specialist. Having a beginner PO/PM is an excellent time to reinforce that!

Don't worry, people. I so got this!

If I were a Product Manger, I would definitely prefer to be a full-featured representative of that specialization! However, I encourage you to revisit Richard’s presentation and do your own decomposition of the Product role. What is absolutely essential? What can you do without?

What is *your* minimum viable Product Manager?

Agile2018 links

07 Tuesday Aug 2018

Posted by claire in Agile, Agile2018, DevOps, Personas, Publications, Speaking, Training

≈ 1 Comment

Live sketch doodle for @aclairefication’s session on #DevOps – inspired by @sketchingsm. #Agile2018 pic.twitter.com/YC873O2D92

— Ankur Saini (@sainiankur) August 7, 2018

Here are some sources to dig in more after my Agile2018 session Everything You Wanted To Know About DevOps But Were Afraid To Ask:

Slides & Handouts

Abstract:
As a career software tester, I’ve heard rumors DevOps culture will put me out of a job, so I took a job testing for a DevOps team. I’m new to DevOps, but aren’t we all? What matters most is our teams’ intentional decisions to grow our DevOps practices along with our development community.
Join me as I share my experiences blending disciplines, companies, levels of experience, and differing expectations as a member of efficient and effective delivery teams. I’ll describe common cultural and interpersonal problems I experienced while transforming a cross-functional agile team dogfooding a DevOps implementation.
Whether you’re into development, operations, testing, customer support, or product ownership, you’ll leave with concrete strategies for improving your DevOps working relationships to keep the technology running smoothly. People factors strongly affect your DevOps technical outcomes, so optimizing your flow includes improving your people practices.
Don’t feel afraid to ask about DevOps anymore!

Learning Outcomes:

  • The people factors that strongly affect your DevOps technical outcomes
  • How to blend teams from different companies
  • To sort through process and role differences
  • Apply the Agile mindset in support of DevOps

 

Other DevOps sessions from Agile2018

AppSec in a DevOps World

DevOps Metrics 101

Software & Pipeline Architecture for Continuous Delivery

Principles of Self-Service Infrastructure

Evolutionary Cloud Infrastructure

The Twelve-Factor Pipeline

“Three Ways” of DevOps

Creating Chaos … Engineering

Blameless Continuous Integration

Continuous Delivery & Testing

Bonus: old presentation from Agile2017: DevOps Explained

Sources I found useful when preparing for this talk:

Books

book Accelerate

book The Phoenix Project (business parable), which calls back to Industrial Engineering business parable The Goal

book Lean Enterprise

book Continuous Delivery

book The DevOps Handbook

book The Site Reliability Workbook (free download right now!)

eBook: Katrina Clokie’s A Practical Guide to Testing in DevOps

Podcasts

DevOps Defined

 

Audio

Beyond the Phoenix Project audio series

 

Videos

7 min intro

DevOps: Who Does What?

DevOps is Dead

Deep dive into container security w/Elissa Shevinsky

All Day DevOps 2017

 

Events

DevOpsDays Atlanta

 

Blogs

BizDevOps

Chef DevOps

DevOps is Dead: Rugged Enterprise DevSecNetQAGovOps

Bridging the Gap between Dev & Ops

IT Infrastructure Agility

DevOps Silo

DevOps user stories

Westrum model + organizational culture & safety

Deployment pipeline

High Performance Practices [PDF]

Continuous Testing

DevOps Odyssey

DevOps for Execs

Notes from The DevOps Handbook + More notes + Even more notes

Small-scale DevOps

DevSecOps

DevOps 2018

What is DevOps? + a different What is DevOps?

CALMS framework + Framework & practices

DevOps conversation

 

Specifically to dig into background for the DevOps personas I created:

What kinds of variables are useful to represent in personas? Persona-based testing + Persona variables + Pragmatic personas

Gartner on DevOps persona

Presenting pipeline data for DevOps personas

User stories for DevOps

SRE vs DevOps

DevOps Revolution

Who Does What? Part 1 + Who Does What? Part 2

Agile Testing Days USA links

27 Wednesday Jun 2018

Posted by claire in Agile, Agile Testing Days USA, Approaches, Coaching, Context, Experiences, Experiments, Exploratory Testing, Podcast, Publications, Soft Skills, Speaking, Training

≈ Leave a Comment

Refactoring Test Collaboration from Claire Moss

Here are some resources we’re using in my Agile Testing Days USA workshop Refactoring Test Collaboration

Slides

Abstract

Collective ownership for testing starts with understanding testing. Rework your team dynamics to evolve past duplication and improve performance through whole team testing. Take home practical patterns for improving your team’s collaboration on testing. Because teams who own testing have more confidence in the customer value of their results.

As the Pragmatic Programmers say, “refactoring is an activity that needs to be undertaken slowly, deliberately, and carefully,” so how do we begin? In this session, we will experience the complex interactions of an agile team focused on demonstrating customer value by answering a series a questions:

  • Where do testers get their ideas?
  • How are you planning to accomplish this proposed testing, tester?
  • Why not automate all the things?
  • Who is going to do this manual testing and how does it work?
  • How do we know whether we’re testing the right things?

Build your own list of TODOs from these various practical collaboration approaches and begin deduping your team’s testing for a better first day back at the office.

Key-Learning

  • Approaches to handle objections to executing the testing work
  • Ways to mentor test helpers, including pairing
  • Investing in testing the team believes in
  • Understand how other team members have been testing the work so far
  • Advising on opportunities to inject test thinking into all of the team activities, from story writing through to unit testing, to make the system more testable

Resources

Refactoring

Collaboration + failing at collaboration

WHOSE testing skills + Exploratory testing + Elisabeth Hendrickson’s Test Heuristics Cheat Sheet [PDF] + book Explore It!

Agile Manifesto

Walking Skeletons, Butterflies, & Islands + my blog post elaborating on the conference

Big Visible Testing + my blog post elaborating on the presentation

Testing pyramid + critique of the testing pyramid/alternatives

Extreme programming lifecycle

eBook: Katrina Clokie’s A Practical Guide to Testing in DevOps + Role mapping

Westrum model + organizational culture & safety

Linda Rising’s change patterns & books on Fearless Change

Deployment pipeline

High Performance Practices [PDF] + book Accelerate

Continuous Testing

Empathy-Driven Development + empathy practices

Many interactive aspects of my workshop were inspired by Sharon Bowman’s book Training From the Back of the Room

facilitation book Collaboration Explained

metrics book Measuring and managing performance in organizations

book Testing Extreme Programming + some follow-up thoughts

Soon to come! Claire Moss on Let’s Talk About Tests, Baby podcast

deliver:Agile2018 Links

02 Wednesday May 2018

Posted by claire in Agile, Coaching, DeliverAgile2018, Design, Experiences, Experiments, Exploratory Testing, Publications, Speaking, Training

≈ Leave a Comment

Beyond Waste: Exploratory Charters in Action from Claire Moss

Here are the links we’re using in my deliver:Agile2018 workshop Beyond Waste: Exploratory Testing Charters in Action

Slides

Abstract:
Think manual testing is waste? Think again! If you’re not learning when you’re testing, you’re doing it wrong! People exploring systems can be your best defense against unknown problems and your greatest way of finding unexpected opportunities.
While automation is well adapted for repeating the same thing over and over again, human beings are great at doing things differently.
Doing is not enough! We need to think during our review and examination processes to improve outcomes. How do we design manual exploration to provide value in today’s fast-moving development culture?
Come to this workshop for hands-on experience with the full lifecycle of exploratory testing charters.

Learning Outcomes:

  • Structuring manual exploratory testing for transparency
  • Charter guidance during test execution
  • Outcomes of exploratory testing
  • Value delivery through debrief of testing session

Elisabeth Hendrickson’s Test Heuristics Cheat Sheet [PDF]

Which world do you prefer?

UI: https://xkpasswd.net/

UI: http://correcthorsebatterystaple.net

UI: http://password.optionfactory.net/

NodeJS: https://github.com/fardog/node-xkcd-password

Ruby: https://github.com/rasmus-storjohann/xkcdpass

Python: https://github.com/redacted/XKCD-password-generator

Shell: https://github.com/danielmcgraw/xkcdpass

PHP: https://github.com/cesarzavala/xkcd

Perl: https://github.com/CS-CLUB/xkcd-936

Baby Steps

19 Thursday Mar 2015

Posted by claire in Agile, Approaches, Design, Experiences, Experiments, Personas

≈ Leave a Comment

Leo: Bob, there is a ground-breaking new book, that has just come out. Now, not everything in this book, of course, applies to you, but I’m sure that you can see when you see the title, exactly how it could help.
Bob: Baby Steps?
Leo: It means setting small reasonable goals for yourself one day at a time. One tiny step at a time.

– What About Bob?

My friend is having her first babies. She shared her wonderful plans for the nursery with us and I saw an opportunity to create something special and new for the occasion.

I’ve blogged before about my crafting habits but not about my design process. Given the reference point of the nursery that inspired my mom-to-be friend, I immediately reached out to a more experienced collaborator, a friend who frequently scrapbooks with me.

We riffed on ideas until we landed on one that intrigued us, and we started to develop it more through discussion. However, given our short timeline, since we intended to have the gift ready for the baby shower, I started to create initial prototypes of the components we planned to combine for our project. Using scrap paper, I cut out the shape that had inspired us the most as a reference point. I made several variations that preserved the color palette we wanted to use, so that even those early attempts would provide better information about the final product.

I sent pictures of these prototypes to my friend so that we could evaluate them together before I moved on to the next small piece of work. She had great ideas for coordinating next steps, so I continued to design and construct independent components, evaluating each as I went.

Once I had gathered several together, I called my husband over to provide a second opinion since he is very familiar with the intended recipients of the gift. He liked what he saw and offered suggestions for additional enhancements that I loved – but I hesitated. While I was in love with my design, would our friends like it?

Having invested this much time and effort into the design, initial construction, and overall style, I was loathe to give up any part of my vision. Then, I reminded myself that while I was spending joyful hours creating this work of art, our friends would spend years in the nursery with their children. No matter what I thought of my design, I had to be ready to kill my darlings. I picked up the phone and made the call.

Our friends agreed to take a look at the in-progress photos, to confer privately, and then to get back in touch with us. To my delight, they loved what they saw! Their vision for the nursery matched our vision for the gift. I breathed a sigh of relief.

Armed with this early feedback, I felt more confident about moving on to additional design and implementation. However, an unexpected illness kept my friend from being able to collaborate, and our work fell behind schedule. Not wanting to show up empty-handed to the party, despite knowing how welcome and appreciated I would be, I put together a smaller sample of our project as well as the latest work-in-progress photos of the whole.

At the party, I revealed one of the most recent developments to the excited couple. Other guests brought lovely gifts, from necessary supplies to handmade blankets. We enjoyed the serendipity of another decor gift perfectly coordinating with our project! The nursery is coming together, one baby step at a time.

While we weren’t able to deliver everything we hoped at the time we intended, we delivered something valuable as early as possible with the knowledge that the mom’s “delivery date” milestone is a bit farther down the road – the only delivery in our project that won’t be early and often.

Guest author at AgileConnection

06 Wednesday Nov 2013

Posted by claire in Agile, AgileConnection, Experiences, Experiments, Publications

≈ Leave a Comment

Check out my recent article Eat Your Veggies over at AgileConnection.com

Claire Moss shares with us a personal story on how using agile methods helped her family with managing meals and groceries. By using techniques like a Big Visible Chart, dinnertime for Moss’s family became less of a chore. Remember, nothing ever goes according to plan, but that’s true for any healthy team.

Here’s the big visible chart that turned our dinnertime struggles around:
BigVisibleVegetables

Agile will FAIL

25 Friday Oct 2013

Posted by claire in Agile, Agile2013, CAST 2013, Experiences

≈ 1 Comment

The closing keynote at CAST 2013 was Scott Barber and Rob Sabourin describing takeaways from each of the talks of the conference, bringing together many different talks into themes or striking moments. As a speaker, I was on tenterhooks waiting to find out what Scott would say about my talk. It was not what I expected, a moment from before my talk that he described as a “kick to the head” (in a good way):
Scott's Takeaway from my Walking Skeletons talk
He pointed out that I was emphasizing empathizing with people with different experience and perspective, which was important enough to say explicitly before I began my talk. So with that in mind, I want to talk about a foreign perspective I encountered at my other software conference of the year.

At Agile2013, someone taped large sheets of sketch paper to the wall with a large writing prompt:

OLYMPUS DIGITAL CAMERA

to which many people replied in various ways during the week. Some of these responses were rebellious, resisting the seeming prophecy of failed agile. Others felt trapped by unresponsive or rigid organization behavior and hierarchy, industry regulation, or even customers. Contributors felt that companies with only a shallow understanding of agile or simply name-only “implementation” had no real difference in the way of working. Culture weighed heavily on the minds of attendees: belief, passion, desire, emotion, infighting, courage, trust, support, motivation, thinking. So people problems were at the heart of most expectations of failure.

To me, the most provocative perspectives I saw on that wall were not focusing on agile but on the demonstrated value delivered through whatever works, focusing on outcomes. Today, a friend pointed out a Mike Cottmeyer article from 2009 that discussed defining value in agile but at the enterprise level in terms of real business outcomes:

As an organization, we know that we need to deliver value as fast as possible… but we can’t figure out how to apply the small team concepts to our particular business problems. That’s why you get the classic “agile will never work here” comments. There is an inherent disconnect between the team level guidance agile methodologies talk about and the bigger concerns your senior executives are struggling with. There is a gap between value at the team level and value at the enterprise level.

Four years later, Agile2013 conference attendees are still wrestling articulating delivery of complex business objectives to business leaders. And while I also struggle with messaging how my work provides value to the enterprise, I’ve never experienced an agile transformation and so it hadn’t occurred to me to wonder whether agile could succeed. It’s always been business-as-usual, in my experience.

The full (transcribed) list from the Agile2013 wall:

  • We think we are “Agile”
  • The concept of “dedicated to one task at a time” is not supported!
  • They won’t change
    • Response: “They”? Maybe this is contributing to the problem
  • Because CEO manages with fear and intimidation
  • … Only focused on changes in development teams; not looking at whole value stream (product ideation & management)
  • No buy-in from the business
  • Duplicitous product owners (two masters)
  • because of our culture
    • Response: √
  • because my customer prefers waterfall…
  • Because the company wears “agile” as a label and yet does nothing to remove the bureaucracy and obstacles teams face daily while trying to implement agile.
    • Response: √
  • We lose trust in each other
  • … Adoption is done because of convenience not because of conviction.
  • We are different
    • Response: … Just like everyone else who has done it.
  • XP NOT DEAD!
  • Our egos are bigger & more important than the company goals
  • A re-org will set us back to the beginning, again and again. (weekly)
    • Response: √
  • Of me.
  • …Insufficient support from leadership
    • Response: Totally agree
  • Different part of the biz use different types of agile
  • Deeply hierarchy…. Project leader doesn’t want Agile.
  • my leadership team no longer believes in it 🙁
  • … it’s counterintuitive & hard to practice
  • Because agile is a state of being… NOT doing! Agile is grossly misunderstood… SADLY!
  • … because Agile is not the goal. Agile is simply a MEANS to and END
    • Response: Agree!
  • We only fund CAPITAL projects
  • Because I just think on the consequence not the cause. We should be able to teach the noble truth behind agile methods. Teach that discipline is not a fantasy. If we try hard as a team we can achieve anything. – She Liang
  • My manager has to assign work to the team
  • It does not support SECURE software (ISO27000 or code analyzers)
  • They don’t want to change. & no lean leadership.
  • Too much focus on the mechanics of the process. Not enough on the motivation/passion behind it.
    • Response: +1
  • We have not explained the ‘why’
  • Not everyone on our team understands it.
  • It won’t, because I work at Rackspace! 🙂
  • “Lack of Courage…”
  • We don’t want it badly enough
  • Because I’m writing on this wall & I think it will so it will
  • We can’t show the value
  • “What we do already works!?”
  • Crash at current (complex) business model
  • Jim
  • Strong and growing PMO traditional structure being instituted
  • We don’t think by ourselves. We need to think everyday, every time, everywhere!
    • Response: Agreed.
  • Our culture won’t *change*
    • Response: √

Q: Maybe someone can clarify that business model remark for me? I wasn’t quite sure what that said…

Big Visible Testing Full Length

19 Monday Aug 2013

Posted by claire in Agile, Agile2013, Approaches, Context, Experiences, Experiments, Personas, Publications, Speaking, Training, User Experience

≈ 2 Comments

Here are the slides from my full length Big Visible Testing talk, presented at Agile2013 in Nashville, TN on August 6, 2013.

Big Visible Testing (Full Length) from Claire Moss

My experience report paper will be published by the Agile Alliance under the conferences archive as part of the proceedings of the Agile2013 conference. You can also download the PDF here: ClaireMoss-BigVisibleTesting-Agile2013

During the year and a half of experimentation that included the big visible charts that are included in this slide deck, I read over the following resources, only some of which would easily fit into the IEEE format. This is the full bibliography of my research, as far as I have been able to track down my sources. (At the time, I wasn’t expecting to cite them for anyone else, so I probably didn’t bookmark everything I read.) I hope the following links will prove helpful to you in developing your own big visible charts. Let me know how it goes! And please share any sources that you find helpful. I’m always looking for new inspiration.

REFERENCES

My first dev team was an XP dev team that dogfooded our own digital signage product to display success/failure for the thousands of unit tests in the suite (i.e. single flag for whole suite red/green).
Other eXtreme Programming big visible charts

Extreme Feedback Devices summary – I loved this team’s “feel-around” approach to feedback!

  • code smell
  • auditory
  • scrolling marquee
  • code flow
  • lights

Alistair Cockburn coined information radiator
Alistair Cockburn’s burn charts (burn up vs burn down)
Information radiator flash card
More information radiator stuff

Lisa Crispin’s whole team approach includes Big Visible Charts
Energized Work site map backlog
More from Lisa Crispin’s tour of Energized Work

Heatmaps (from code analysis)

Paul Holland’s Exploratory Testing charter Kanban board
Lanette Creamer and Matt Barcomb gave a presentation that included ET charter management in big visible charts; podcast preview of their session

Visualizing above the product team
Including faces of people/profiles in the big visible charts
I can’t remember whether I’d see this one at the time or not… it might have been something I discovered after my time on the team mentioned in my presentation: Visual management for agile teams

New inspiration

Although the above resources were all I knew at the time I began my experiments, as I prepared my IEEE paper for the Agile2013 conference proceedings, I was tracking down my sources and came across these other relevant pages & posts that have given me some great ideas of things to try next!

Gojko Adzic’s visualizing quality

Michael Bolton’s mind-maps

I like this greyhound chasing the rabbit decoy visualization Alistair made
Alistair’s projects (radiating)
Alistair’s collaboration cards

Lego representation of bugs

Other cool extreme feedback devices:

  • bat signal (as a Batman nerd, I heartily approve!)
  • bear lamp
  • traffic light

Clothesline wallboard contest entry – as an avid crafter, I adore this one!
Wallboard contest results

After some discussion in my session about suggesting solutions for distributed teams, I was looking for some digital implementations of big visible charts, but I don’t know how these would work out for you.

Atlassian on information radiators for extreme feedback (with broken image links – sad!)
Atlassian on information radiators
Greenhopper (Jira plugin) wallboard
More on Jira Wallboard

What I Did For My Summer Vacation – Part 2

14 Wednesday Aug 2013

Posted by claire in Agile, Experiences, Experiments, Retrospective, Soft Skills, Testing Humor, Weekend Testing

≈ Leave a Comment

For Science!

For Science!

Our geek gals weekend was quite a memorable one! We had an email thread going around discussing all of our excitement that culminated in:

Road Trip Retrospective

Liked

  • Beginning new friendships and rekindling old ones
  • WaHo, or Waffle House for you non-Southerners, is a road trip staple
  • Seeing the sights: art gallery, street musician, architecture walk, shopping
  • Active pursuits: plantation tour, petting zoo, bodysurfing
  • Keeping it mellow: drip castles, collecting shells, yoga, sunbathing
  • Team-building through cooking indoors & grilling out
  • Kitsch juxtaposed with refinement: deep fried peanuts and formal high tea
  • Bizarre medical poster discovery
  • Conversation: discussions of literature, science, and life
  • Creative outlets: lanyards, scrapbooking, board games, magnetic nail polish

Learned

  • Having pricing/rental agreements in writing is essential – but at least one of us was overcharged and our deposit wasn’t fully refunded
  • Foodie friends should always pick the restaurant
  • Crafting doesn’t come as naturally to everyone – but collaborative art is more fun!
  • Twilight is hilarious when read aloud with expression and voice acting
  • About 1 in 10 photographs come out the way I’d expect
  • Vintage gold lamé will cover you in glitter
  • I can disassemble a grill to light it when the starter is broken – but I didn’t expect a fireball when I opened the lid!

Lacked

  • Roadside attractions
  • Strange food venues
  • Pest control (huge roaches landing in my hair? unacceptable!)
  • Respect from the rental agent who told me I was a b*tch on the phone (keepin’ it classy!)
  • Support from the rental agent to operate the hot tub that we were forbidden to adjust when it was tepid

Longed For

  • Working internet connection (seriously, who cuts a bunch of geek girls off?)
  • Privacy: long term renter walked his dog through our space each day
  • Functional bathrooms: inconsistent water pressure, toilets constantly running or clogged and leaking, shower door jammed, scalding hot water hurt a couple of us, and what’s with the toilet installed in the linen closet?!?
  • Stable floors: I fell through the deck once and nearly fell through another part of the deck a second time, squishy kitchen floor
  • Sturdy roofs: bedroom ceiling collapsed
  • Nighttime lighting out on the uneven decks
  • Ovens/grills that heated evenly and to the designated temperature
  • Cleaning crew: moldy air conditioning unit, dust, dirt, bug parts, expired cleaning supplies
  • Maintenance crew to shore up the framing and carpentry

So how did our product turn out? Our execution wasn’t flawless, but we have very fond memories of creativity, conversation, and survival. Nothing like a few disasters to remind us how fortunate we are.

What I Did For My Summer Vacation – Part 1

31 Wednesday Jul 2013

Posted by claire in Acceptance Criteria, Agile, Approaches, Context, Experiences, Experiments, Retrospective, Soft Skills, Testing Humor, User Stories

≈ Leave a Comment

With the First Day of School quickly approaching, it’s time for:

What I Did For My Summer Vacation – Part 1

Exploring Requirements

I get really excited about hanging out with people, especially friends, especially a combination of new and old friends. So it was with great happiness that I set about organizing a geek gal weekend.

Our first conversations centered around budget (fixed), deadline (fixed), and features (flex). We started talking over the various activities that different destinations could provide to entertain us. Then, I paused the conversation to bring the focus back to value: when we looked back on this weekend, how did we want to remember it? how would we feel about the way we spent that time together? would features even feature in these stories we would tell? Instead of features, we realized that functions (what the product was going to accomplish) and attributes (characteristics desired by the clients) mattered more. (Why yes I was reading Weinberg this morning. How could you tell?)

Vintage gold lamé (see that gaw-jus totally 80s animal-print metallic finish? oh yeah.)

Vintage gold lamé (see that gaw-jus totally 80s animal-print metallic finish? oh yeah.)

We wanted to relish the simplicity of being together, whether wearing goofy vintage clothes (gold lamé for the win!), cooking our own meals together, telling silly stories, or engaging in feminine activities with a geek spin (magnetic nail polish was not as simple as expected) that would be low-key and more about togetherness than busyness. We wanted to craft something lasting (collaborative artwork – packing the craft supplies was a must not a want!) and reinforce durable friendships that appreciated our differences.

With this clear focus in mind, suddenly the locale was much less important than inclusivity to maximize togetherness.

Planned For Sand

So we made an informal backlog of tasks to tackle researching options (beach vs mountains), reviewing results, and prioritizing options (beach!) before presenting our findings to the group for dot voting. (Typical agilists, I’m tellin’ ya.) Fortunately, we found a viable approach and went forward with making arrangements to execute this solution (road trip!), adjusting as we went to accommodate discovered needs.

How did it all turn out? Stay tuned for scintillating tales of laughter and danger in What I Did On My Summer Vacation – Part 2!

← Older posts

♣ Subscribe

  • Entries (RSS)
  • Comments (RSS)

♣ Archives

  • November 2024
  • October 2019
  • September 2019
  • August 2019
  • March 2019
  • February 2019
  • November 2018
  • August 2018
  • June 2018
  • May 2018
  • March 2017
  • August 2016
  • May 2016
  • March 2015
  • February 2015
  • February 2014
  • January 2014
  • November 2013
  • October 2013
  • September 2013
  • August 2013
  • July 2013
  • 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
  • Agile Testing Days USA
  • Agile2013
  • Agile2018
  • AgileConnection
  • Approaches
  • Automation
  • Better Software
  • CAST 2011
  • CAST 2012
  • CAST 2013
  • CAST2016
  • Certification
  • Change Agent
  • Coaching
  • Context
  • DeliverAgile2018
  • Design
  • Developer Experience
  • DevNexus2019
  • DevOps
    • Reliability
  • Events
  • Experiences
  • Experiments
  • Exploratory Testing
  • Hackathon
  • ISST
  • ISTQB
  • Lean Coffee
  • Metrics
  • Mob Programming
  • Personas
  • Podcast
  • Protip
  • Publications
  • Retrospective
  • Scrum
  • Skype Test Chat
  • Social media
  • Soft Skills
  • Software Testing Club Atlanta
  • Speaking
  • SpringOne2019
  • STAREast 2011
  • STAREast 2012
  • STARWest 2011
  • STARWest 2013
  • Tea-time With Testers
  • Techwell
  • Test Retreat
  • TestCoachCamp 2012
  • Tester Merit Badges
  • Testing Circus
  • Testing Games
  • Testing Humor
  • Training
  • TWiST
  • Uncategorized
  • Unconference
  • User Experience
  • User Stories
  • Visualization
  • Volunteering
  • Weekend Testing

♣ Meta

  • Log in

Proudly powered by WordPress Theme: Chateau by Ignacio Ricci.