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…

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

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

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!

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?

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

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

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.

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.

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.

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.

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

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…

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

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!

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.

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

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

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

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!