Advice for a brand-spanking new Product Owner

I’ve started a mentee collection.  Not a manatee collection:
My mentees are better looking
I’m mentoring three new Product Owners, collecting them into my posse as I encounter new Product Owners who have no peers/colleagues from whom to learn the ropes.
The rant below was inspired by a real-life plea for help from a newly-minted Product Owner at my company.  Knowing how anxious and overwhelmed I was when I realized what I’d gotten myself into, these are the kinds of “start small, start here, build on your successes” advice I’d give my past self (can we use Skynet’s back-in-time portal yet?):
What could go wrong?
What could go wrong?
  • I’m inclined (especially with new teams, new process, new roles) to start small – get a rhythm, build a few quick wins, get small pieces shipped in short timeframes, even if it’s not technically a “potentially shippable product”
    • The important thing is to start seeing chunks of more valuable engineering work delivered earlier
    • For example, I’m currently getting the team to work on a “research spike” to determine if they can figure out how to add “test our site using IE11” to the test coverage – plus we’re doing the second story (broken up from a larger story) to deliver an Export capability to our project planner (just started with flat file, unformatted CSV as an export deliverable for now – it’s good value to users, and we’ll refine and “gold plate” it later)
    • I’ve also had them working on some of the more ‘valuable’ tech debt over the last few months – cleaning out old database tables, removing dependencies on legacy code and data structures, etc. – all written as “stories” (probably doesn’t fit the dogmatic definition), small bits of work each, that ideally could’ve been done all at once, but are easier to schedule, are establishing a rhythm, and have given them hope that I’m committed to systems hygiene as part of our negotiation between “user value” and “systems integrity”
  • Encourage the team to adopt SCRUM (or whatever flavour of Agile-ish behaviour they’re aiming at) in stages – don’t try to swallow it all at once
    • As a fresh PO, I’d stand up and tell them I don’t expect them to get everything right the first time, and especially not when they’re playing with all these new “process toys”
    • e.g.. Try the “sprint planning” and “retrospective discussion”, and drop everything else, for the first sprint – see how it goes, spend the time discussing “things to do more of and things to do less of” at the end, and ask them whether they’re ready to add “daily stand-ups” or “story point estimation” or “story breakdown” to their process
    • Personally I don’t want process to get in the way of the engineering – I want it to be a net break-even, and if you try to do all the process all at once, there’s no way that they’ll get any effective engineering done that first sprint or two – just too much flailing and failing on friggin terminology, not enough on learning to succeed at the job with incremental improvements along the way)
  • As quickly as possible, focus your efforts on the WHAT and the WHY of every piece of engineering work that the team sets out to do.
    • Any of us that come from engineering will still trip over the HOW too many times to count before we get really good at this, but it’s worth the effort to learn.
    • The most satisfying feeling as a PO is setting the team a challenge you yourself have no idea how they’ll deliver, and watching them struggle, flail and invent something they never knew they could do.
    • Over time, they’ll recognize your trust and confidence in them – in giving them the leeway and slack to take on challenging problems and kick the shit out of them]
    • It’s taken me years to let go of this, and I’m still meddling more than I should, but it’s satisfying to imagine how it’d feel for my ‘product CEO’ to have faith that I’ll do an amazing job figuring out how to make it happen
  • The big focus for you – for as long as you inhabit this crucial role – is to spend as much time in the heads of your users (and unfortunately, stakeholders who aren’t end users) to understand what will be the most valuable thing to deliver to them as soon as possible
  • The trick is “most valuable part of functionality”, not the ideal solution
  • e.g. The users want to be able to import the set of security requirements into their ‘work tracking system’ (Jira, RTC, Rally, Trello, etc).
    • It would be awesome to have it pre-filtered to just what they need, pre-annotated to fit exactly the field structure of each of their tools, and able to be exported back into our system
    • However, the most important first incremental delivery of value before we work out all those problems is “structured list of the names of the tasks, their current status and a link to more info on how to deliver them” – a far cry from the ideal solution, and probably ten steps between here and there
    • I’ll carve out this first step as a story, where the WHY is “I need to track this shit in my native work tracker”, and the WHAT is “the details that are critical to me tracing back to what I need to know to be successful”
    • The rest of that work I’ll represent as notes in a parent Epic, or one or more Stories that may or may not be fleshed out enough for the dev team to tackle (depending on how soon I/we think we might get around to delivering that residual incremental value)
In a future post I’ll introduce the fever-dream “system” I use to calculate priority for each story and Epic, but seriously you’ve got plenty to chew on just getting out of the starter’s gate. We can setup a 1:1 call for whenever in the future you want to review results/commiserate over failures/discuss additional experiments that you’re ready to try.
It’s an adventure – a Very Real experience in both asserting control and letting go of absolute control over the direction of the product. It’s a blast.  If you’re a new Product Owner, welcome to the tribe.

This week in after-work design & tech events in PDX Agile PDX, PDX QS

Maker Faire Portland was this weekend, and quite a collection of weird and fun technologies were available to break, create and buy. I saw a couple of friends there – and a lot of pirates, robots, fire, 3D printers and well, the usual weirdos that hang out at these things. Hope you had a chance to catch up with the bleeding edge of DIY.

Genevieve Bell gave us a quick update on where Intel Labs’ research and thinking currently is – intriguing insights as always. IDF 2013 replay available here.

Ever wondered whether mess engenders creativity? Researchers from University of Minnesota have some interesting experiments to share.

Only 20 tickets left for the October CHIFOO event…

Oh hell – and Rose City Comicon is on this weekend, and I’ll be out of town. That is a BUMMER – you won’t even get the chance to see me in my Superman kilt. OK, here’s a sneak peek.

This Week in my kind of PDX fun
· Wed Sept 18th: Agile PDX “Ward Cunningham On Getting Current in the New Web World” (Calagator)

· Thurs Sept 19th: PDX Quantified Self “Show and Tell” (Meetup)

On the Radar
· Tues Sept 24th: Portland UX Happy Hour “Combo meal with PDX Web & Design” (Calagator)

· Tues Sept 24th: Internet of Things Meetup PDX “The $1K Hardware Contest and Oregon’s Plans for a Hardware Incubator” (Meetup)

· Sept 27-28th: BSides PDX Annual Security Hackers Gathering (EventBrite)

· Wed Oct 2nd: CHIFOO “Finding and Measuring the Awesome in Education” (Eventbrite)

· Sat Oct 5th: PDX Code Retreat – Fall 2013 (EventBrite)

· Oct 7-12th: Design Week Portland – just ignore the horrible gimmicky page design, I’m sure there’ll be some talented designers featured there

· Jan 11th 2014: Portland Code Camp 2014 (EventBrite)

· March 2014: CHIFOO talk “Show, Don’t Tell: Storytelling Experience Design in Modern Comic Books

Mike Lonergan, Certified Usability Analyst & Certified Scrum Product Owner

Making software better for users since 2006

Interaction Designer and Scrum Product Owner

“You have to trust in something: your gut, destiny, life, karma, whatever. This approach has never let me down, and it has made all the difference in my life.” Steve Jobs

MyPicasaPictures Part 4: Smart Client Software Factory — a deeper look

Having determined that of all the Patterns and Practices guidance, the SCSF is likely the one with the most to offer my project, I decided to see what following the Getting Started steps would get me.

And just my luck, I can’t even get past the first steps — to create a Hello Word application, I need to be able to select from the “Guidance Packages Project” in Visual Studio, but it appears they didn’t even get installed.  I’ve run the SCSF (May 2007) installer twice and selected everything, but still it doesn’t add any entries to the New Project dialog.

What’s a little disturbing is that when I started to peruse the discussions to see if anyone else had run into this, the detailed steps that people had to go through to troubleshoot problems with this guidance were shocking (see this thread, for example).

I really didn’t expect this “factory” to be this complex — I was hoping for a library of code and simple steps to piece different bits together.  What I seem to have gotten instead is another “learning opportunity”, much like the MCML rabbit hole — some limited set of benefits that’s masked by a steep up-front learning curve, and that only benefits your use of that proprietary set of tools.

Does anyone ever just try to create a set of code snippets or object libraries?  Why does everything require learning a whole new development paradigm, and some new hierarchy of newly-overloaded terminology that doesn’t relate to any of the stuff upon which it purports to build?


Dependency Checker: decoupled from install?

Wow, so I decided to go right back to the beginning, and see if there were any hidden steps I missed the first couple of times.  It turns out that, without making too much of a big deal of it, the SCSF team has written a separate downloadable tool that checks for all the required and “optional” (?) dependencies [who ever heard of an optional dependency?  That’s a new one on me].  After all this time, I’ve come to expect that the installer for the program I’m after would check those dependencies as a first step, and would tell me to go get the pieces I’m missing if it detects that it won’t be able to work if it installs.

No, for whatever reason these guys seem to have decided that they want their end users to “educate” themselves on what it really means to use their guidance, so they seem to have intentionally left at least one land mine in place for most newbies to trip over.  I dunno, but if most .NET applications can test for the presence of the required .NET Framework (and halt the install if it’s missing), how much harder could it possibly be to add this dependency checker code as a pre-install step and direct users to the pieces they’re missing?

This reminds me of the days when you downloaded Eudora or Mosaic to “access the Internet”, and then later learned that you needed to download Trumpet Winsock or some other TCP/IP stack before they’d work.

YAFR (Yet Another Freakin Runtime): Guidance Automation Extensions

Well, so it looks like I’m missing something called the “Guidance Automation Extensions“, which sound reminiscent of the Office PIAs — yet another set of libraries that are necessary before the specialized development software will ever work.  Why does everyone seem to want to carve off a set of “foundation libraries”, rather than just include them in their software package itself?  Why do these scenarios inevitably require the end user to become an expert in the internals of the application, rather than just make it as easy as possible to get up and running in one step?

Maybe it’s the Micro-skeptic in me, seeing how often people at Microsoft fooled themselves into thinking that *their* little piece of the platform was the *most* important thing around, and why *shouldn’t* our users spend some time learning how our stuff is supposed to be used?  It’s just such ridiculous arrogance, and in a lot of ways, I suspect it stems from the hiring process itself — hire these geeks straight out of college (with no previous real-world experience or humility i.e. ever failed at anything in their lives), tell them they’re the absolute best of the best, and then set them loose on a project.  Of *course* they’re going to believe that whatever comes from their mind is the product of god.

Now, after installing the so-called “GAX”, re-running the SCSF installer enables me to select the “Automated Guidance” selection (which had been greyed out before –  which in other installers simply means that you’ve already installed those bits, and don’t need to worry about them again).

Why CAB in the first place?

However, this is just the beginning of the confusion – for a tool that’s supposed to make it easy to build a well-patterned application, the discussions and blogs around SCSF make it clear that this is no library – this is yet another “only once you’re expert with it should you use it” tool.

Bil Simser says, “The point is that SCSF made me more efficient in how I could leverage CAB, just like ReSharper makes me a more efficient developer when I do refactorings.”  However, what he pointedly fails to say is that SCSF makes him more efficient as a developer.  The debate assumes that you have already determined you must use CAB, and once you’ve fallen down that crevasse, what’s the best way to crawl back out?

I guess I need to take this one step further back, and understand the value of CAB to my current application development needs.  Until that time, I’m going to be very skeptical of having to learn the internal logic and complexity of yet another proprietary tool, and be very resistant to investing the time needed to learn enough to make it useful.

A little earlier in his blog, Bil Simser has this to say:

I’ll be the first to admit that CAB is complex. EntLib is large. There is a lot there. As Chris said this morning in what I think was an excellent response to the entire discussion, CAB for example is not just about building maintainable WinForm apps. I like CAB as it gives me a bunch of things and they all work together in a fairly harmonious way. EventBroker is a nice way to message between views and keeping the views separate; CommandHandlers allow me to hook up UI elements indirectly to code to execute them; the ActionCatalog let’s me security trim my commands (and in turn my UI); and the implementation of the MVP pattern using views lets me write presenter tests and keep my UI thin. This all makes me feel good. Did it take me a while to get here? Absolutely. I’ve spent the better part of a year learning CAB, EntLib, ObjectBuilder, WorkItems, and all that jargon but it’s no different than learning a dozen different 3rd party libraries. I simply chose the MS path because it was there and everything was in one neat package. If you packaged up Castle, NHibernate, StructureMap, and others together in a single package maybe I would have chosen that path (and is there really two different paths here? I use both tools together anyways).

Yipes!  Better part of a year?  [And that’s not even counting the SCSF learning curve!]

Not to mention that even the experts wouldn’t want to try to explain it in a short amount of time:

Unfortunately [Entlib/CAB is] not something I could introduce at a conference or User Group session and describe the entire stack in an hour, so I tend to avoid showing off applications and concepts using it as it just turns into a discussion of what (SmartPart) means instead of the main goal like describing MVP which I can do with my own code.

And the promise that even with all of what’s bundled into Entlib and CAB, you could still find yourself dragging in all sorts of other crap:

Eventually I could have a really ugly monster on my hands with copies of Castle, StructureMap, CAB, EntLib, NHibernate, log4net, and who knows what else all living (hopefully) together in happy existence. I don’t want that.

More words to give me pause, from Chris Holmes:

I’ll also say this about ObjectBuilder : I agree with Jeremy; I wouldn’t use it on its own. It’s hideous. It is overly complicated, undocumented and cumbersome. It is the worst part of EntLib and CAB. Fortunately, when using EntLib and CAB I don’t have to manipulate ObjectBuilder. If I did, I’d have abandon both tools a long time ago.

So we come to this question: If I don’t like ObjectBuilder, then why am I using CAB or EntLib?

Now, some people might say “that’s Big Design Up Front”. I’d argue otherwise. Our ultimate goal was testability. We wanted to adopt an MVP architecture so that we could have a very testable UI layer. We wanted automated tested; we wanted automated builds; we wanted the confidence that comes from having a vast suite of unit tests; we wanted the confidence to refactor our code without fear of breaking a tightly coupled system. So our goal was not to have “nifty tools”, but to have a framework to build upon that would give us our ultimate goal: a testable UI layer that we all would have confidence in.

My assumption was that [rolling my own code] would take a considerable amount of time (and not as BDUF; but as time spent building the pieces when necessary. The bottom line is, it still takes time, no matter how you allocate it, and I wasn’t certain how much). That assumption was probably unfortunately influenced by looking at the CAB as a frame of reference and saying, “Holy cow, there’s a lot there…”

So we went with CAB. The idea was that we thought it would help us get out of the gate faster. I thought it would take less time to grok the CAB and make use of it than roll my own code. Maybe that was an error in judgment. It’s certainly possible, I am human and very flawed. But I did manage to grok the CAB pretty fast compared to other adopters, so it seemed like a good decision to me at the time.

I chose CAB because I thought it was the best solution at the time, given everything I knew about software design and weighing all of the other factors involved. I might make a different decision today, given the amount of knowledge I’ve accumulated and the tools that have emerged. I might do just what Jeremy and Oren propose, and grab an IoC tool like Castle and grow my own solutions as necessary.

SCSF, CAB & Entlib: just not ready for the Media Center developer crowd

While having an IM conversation with one of my respected colleagues today, I complained about all the time I was investing in learning about yet another framework:

I just dove deep into the CAB/SCSF/MVC-P crevasse, and it’s amazing how much of learning the bit you need depends on learning the next-layer-down foundational piece – and how many f’n foundational layers there are once you start looking closely.

The thing that J.D. Meier & co did well was provide some automated “wizards” that setup all the skeleton code once you know which pattern you want to use.

The part they addressed poorly is to provide any “entry-level” patterns for weekend hackers like me – everything is all about “steep learning curve, big architecture, lots of pieces to re-use once you figure out the puzzle up front”.  I’m not even convinced I ever want to do this kind of project again, and the amount of setup to even try it is making it less likely I’ll even do it once.

It strikes me that if I were to adopt one of these mammoth frameworks for the MyPicasaPictures project, the only advantage to the pre-defined pieces that are available to fire up at will is that other people (already familiar with the same framework) would have an easier to finding a customizing the pieces they wanted to bolt into.

For the rest of the Media Center community, if they wanted to extend the application or plug in a new module, they’d be forced to suffer the same learning curve as I’m facing right now.  This is not a community that I’d expect to be familiar with these enterprise development frameworks, nor do I feel particularly cruel enough to try to foist such a hairball upon them.

Fascinating quote to end this research vein with:

The end result is that this [anti-Agile programming] architect and I could not possibly coexist on the same project.  My longstanding opinion that traditional architects are useless if not downright harmful remains completely intact.  I guess you wouldn’t be slightly surprised to find out this guy is a big proponent of software factories as well.  Of course, this guy had more people in his talks and better evaluations than me, so what do I know?

If his description is any indication, and if I assume the likelihood that factories-based development suits the Media Center developer crowd is slim to none, then let’s just forget about the whole idea of using factories/frameworks for VMC-oriented development.



Next stop: back to the drawing board.  Perhaps I’ll work on a few crisp use cases to anchor the development of one or more rounds of Agile-esque coding.