Superpower #11 – Climbing Down

Agile Values
As you probably know, the agile manifesto is purposely short on details and long on spirit. In fact, it is so short on details it fits very easily in a blog post:

Manifesto for Agile Software Development

We are uncovering better ways of developing
software by doing it and helping others do it.
Through this work we have come to value:

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

That is, while there is value in the items on
the right, we value the items on the left more.

Enterprises Need Rules
It’s a great set of values right? We seem to forget how simple and meaningful they are as we try to implement agile in the enterprise.

zealot tree

the zealot tree

Maybe it’s because we are lazy or maybe it’s because we are just humans, but once agile is introduced everyone starts to get ideas about what should or shouldn’t be DONE, instead of what we should and shouldn’t VALUE. I believe you need some structure as soon as there are more than two people involved, but we should  keep it as loose as possible and aligned with what we value — always know why you are doing something.

Be Culturally Adaptive
Recently, I was talking with John Ryan, an agile coach at BigVisible, about our implementation of agile and the rules we have in place to run our scrums. We also discussed how some people were dissatisfied with our agile adoption and the suggestions that our brand of agile wasn’t really agile. Asking for John’s opinion on our rules, he said (paraphrased), “Every company implements agile according to their own norms. I call it ‘culturally adaptive agile.’” He also said:

It is important to note that while we establish a foothold by respecting the existing culture, true transformation can’t happen unless we keep lifting the bar higher. The question then becomes, “which way is up?”; the answer is “toward the Agile values.” …adapt at first to find the right starting point and then keep challenging to grow.

As we chatted a light turned on in my head – people who get the most invested in agile are often focused on the rules we have rather than the values. If you lose site of the difference between ignoring those values and breaking one of the rules your organization set, zealotry is the result. And like other forms of zealotry, it alienates people and those people may begin to resist agile in general because zealots are so vehement in their support.

Be Enthusiastic But Climb Down
I cannot tell a lie, I sometimes get stuck on “the principle of the thing.” And when a shiny new idea comes along, I have been known to get a bit overly enthusiastic. Mixed together with the imperfections of the world the result can be zealotry. Passion makes the world go ‘round, but zealotry just turns everyone off.

So as for me – I resist. I take a deep breath. I climb down out of the Zealot Tree. You should too.

Posted in Super Powers | 1 Comment

Super Power #10 – Controlling the Tides


Three is the magic number

Part of your work as a PO means controlling the tides, or rather, controlling the waves.  You need three waves to get your users’ attention…

Picture your sponsors laying on their metaphorical beach and casually considering the features you completed in the last sprint.  Are they really engaged or do they just want to get back to their magazine and that umbrella drink?  One of the challenges I’ve had in my time as a Product Owner is to get true engagement from users before releasing.  True the ideal is just to release early and often, but in an large enterprise that is often not possible.  With our releases being no more frequent than monthly, and usually more like quarterly, we need sponsors and users to engage with our system and think about it as if they are actually using it.

We have tried a number of techniques to accomplish this:

  • Standard demos after each sprint
  • Supplying a link to our system (easy as we make web apps)
  • Conducting usability studies and doing paper prototyping
  • Reviewing wireframes and click-throughs as a group with our business partners

The issue with all of these, I believe, is that you get limited engagement for a limited time.  Even if you succeed in getting their attention you still suffer from their lack of familiarity with the product, so they spend all their time just groking it.  Remember that it took you many hours of mulling things over, discussing with your scrum team or other product team members, etc before the vision was clear to you.  

Back to our beach – I have now observed on two occasions, that using the techniques above works but only about the third time your users see something.  When the THIRD wave hits them, they understand what they are seeing and have had enough time to consider how it applies to them.  This is when you begin to have productive conversations and get actionable feedback.

So, while I would love to hear your opinions on this, my team’s next project will involve getting things in front of the same audience of users three times in as short a time as possible.  It may be poor substitute for releasing (which gives you new information like usage tracking data), but many times in my company, this is the best I can get.

How many waves have to wash over your users?    Many of my users are frequent travelers and/or are high level executives, so maybe it’s different for you?

Posted in Super Powers | Leave a comment

Super Power #9 – Leadership

So you’ll have to forgive this unabashedly America-centric theme, but I recently saw an ad for the new Captain America movie, and wondered how that might fit our growing list of PO powers. Then it hit me — he doesn’t actually have any super powers, but according to the super hero database he is, “…[A]n expert tactician and an excellent field commander, with his teammates frequently deferring to his orders in battle.”

This element of leadership is really important for a product owner team.  Let me explain…when we first started our transition to agile, our product owners were told they were supposed to write the stories, define the acceptance criteria, and prioritize that with stakeholders.  Then they needed to communicate that to the team and continue explaining things as they worked through their development.  But what about all the Business Systems Analysts (BSAs/BAs)?  They used to do a lot of that (though perhaps in a bit less directive way).

The teams all identified early on that there was a problem here, that BSAs were not nearly as well utilized as they had been in a pre-agile world.  And we also wanted to accomplish a number of strategic initiatives with the PO team including formal usability testing, click-throughs (in Adobe Fireworks), more direct observation of users, etc, etc, etc.  This stuff never happened though because the poor POs were trying to do all the analysis themselves because that’s what they were told.

Recently though, we decided to do something about this and I proposed the BSAs should take on the early analysis in a project as well as any of the research into financial calculations, etc (I work in Finance remember).  All of this work would be moved from POs and would be packaged up as small projects to be prioritized at our Meta Scrum.

So far so good.  Our Business Analysts are cranking through projects and our POs have been able now to focus on some really important issues too, like usability testing, story mapping with stakeholders, and sketchboard sessions (which I’ll be talking more about soon).

Do your business analysts fit into agile?  If so, how? If not, why?

Posted in Super Powers | Leave a comment

Real story mapping!

Ok so this is just a quick note to say I am excited about a story mapping session coming this week.  Normally I don’t broadcast thoughts like this but (a) I wanted to let you know I’m still alive and (b) this is significant in my organization.

My users are executive level and we have never tried to map out an agile project with any of them before.  We will have real high-level stories, a real map, real cards, developers in the room, and several actual users there too!

I should clarify that we involve our stakeholders throughout our projects on an ad hoc basis, in sponsor calls, and in a bi-weekly review.  We also provide access to a live ‘sandbox’ so they can interact with new features between releases.  But this involvement in the mapping hasn’t happened before…

I’ll let you know how it goes.

At the start

So that really couldn’t have gone better.  We started with a review of our project goals, which they helped us improve, then I gave a quick overview of what a storymap was (and what stories are) and encouraged one of our sponsors to stand up and put the card where he felt it should go, priority-wise.  After some clarifying questions, he pinned it up and we were off.

We tried to help things along by having pre-written cards for the high level categories and also for the epics they were prioritizing and started by giving them permission to tear-up, re-write, and add to these and they did all of that.  Categories were completely re-worked to better fit their mental models for the way they worked and the time flew.

After a couple of hours and a ton of great conversation, we had a great

The ending jumble

jumbled pile of cards on the board — perfect.  We have since organized it a bit more and are working through some initial paper prototypes to share back with our sponsors and some other users.

Beyond just being a successful day, this really cemented story mapping as a useful process in the minds of our users — now of course they want to do it with every project!  It’s as if we’re practicing agile software development or something…

Posted in In Between Episode | 2 Comments

Super Power #8 – Quick Draw

So about that survey last week…it was um, really successful…to the one of you who took it…so uh, if that one person is reading this? Just remember what you entered, k? And I’m just gonna let that slip away and NOT put up another survey…maybe ever. Sorry ‘bout that.

THIS week though, we’re doin’ a super power, baby! I promise it will be way more fun than my son had this morning (when he had a tooth pulled).

The problem? People, including you and your stakeholders, are not very good at predicting what features will be effective and popular and those that will not work well. That is precisely why I wrote about shrinking your app to better focus on the best features. That’s reactive though, surely we have to be able to do something to be proactive?

Enter the quick draw power. No, please don’t quick draw your weapon and disable users who don’t like your app…I mean quickly draw a sketch of an idea. Prototyping is powerful for helping you improve your odds of building the right stuff.

As I wrote about in Taking Blind Leaps, one of our development teams was working on a graphical tool that could do scenario analysis. Early on in the project, we brainstormed with our users and came up with some great ideas for overlaying different sets of securities onto their main view to help them generate ideas. This sounded interesting to them but not interesting enough to make it a key part of the project and so we moved the stories around it to the bottom of the backlog.

Otherwise, the project proceeded and was considered a big success, but this overlay piece ate at some of us. A couple of sprints before the final release the team really started pushing to do a spike to show our stakeholders what was possible with the overlays and a few other advanced features. At the demo, we showed them the new views and how they might be interconnected, which went really well. The shock came as we did the usual confirmation and shuffle of priorities in the backlog, and he put this new set of features at the top.

A very gratifying result that unfortunately came just as the project time and money were running out. We are definitely going to pursue the features we showed them in the prototype but now it will take a lot longer and will have to compete with many other priorities. And the bottom line is that I want to get this kind of thing done much earlier in the process next time.

So what can you do to get this kind of result? A fully functional prototype will definitely do the job but I will be trying a number of different things so we can find the most effective (and inexpensive) way. For instance, I and two other product owners on our team are going to UX Week this year to learn about paper prototypes, among other things. My current belief is that you have to visually engage your users, not just verbally convey an idea.

I know there are lots of people out there who know more than me and would love to hear what you find most effective for prototyping new features. And I will post a follow-up to this if I personally find something really effective in the coming months.

Add to DeliciousAdd to DiggAdd to FaceBookAdd to Google BookmarkAdd to RedditAdd to StumbleUponAdd to TechnoratiAdd to Twitter

Posted in Super Powers | Tagged , , | Leave a comment

Super Power #7 – Taking Blind Leaps

Mistakes are inevitable. As a product owner, you need to be decisive and use all the knowledge and resources at your disposal. In the end though, you sometimes need to just be a daredevil and make decisions with incomplete information so the team can build something. With that comes a 100% possibility that you will eventually decide on a course that is…less than ideal. This really is ok because the purpose of a sprint is to produce features of value but also to learn something, and you actually learn a lot from being wrong!

Let me give you a couple of examples…

Sometimes you will be right
In a recent project to produce a pretty cutting edge visual tool for portfolio analysis, IDaredevil PO took a chance on an idea where we would overlay different universes of securities that can help our investment group find new ideas for their portfolios. Prior to seeing this overlay idea, our stakeholders didn’t think they would be very interested in it (and sadly this led us to prioritize it to the end of the project). Once we gave them a demo, however, they lit up and as we summed up the new list of priorities (with the overlay now at the top) our key sponsor said, “You know when I walked in here today those were not my priorities, but now that I have seen it, yeah, I think this is the most important next step.” So I learned if you can demonstrate vision and correctly anticipate the needs of a user group, risks can pay off big. That project will now continue very fruitfully and may end up helping many more investment professionals as we expand it.

(Note: This is very different than simply building some new widget because it is possible — we married the possible with the desirable to find a really great idea. It is all about the users needs.)

I was proud to be a part of that effort but it doesn’t always go so well…

Sometimes you will be flat wrong
On another project about a year ago, I wrote a story for a system that tracks company earnings and changed the logic for how we calculate fiscal year ends. My decision ended up causing confusion with those entering the earnings numbers and ultimately we had to change the logic back to the original way. I made that decision with incomplete knowledge and the thing I learned was to make sure I always have an active, engaged stakeholder group on every agile project.

In the cases where I was wrong, I have had to deal with some user frustration, but I believe this is entirely worth it if the benefit is that I can make real decisions as a PO and keep the iterative process rolling. It also helps greatly to have the support of upper management as our company was historically averse to any significant level of risk.

Risk is part of the job
Taking a leap may result in a mistake and our job as product owners is to take that risk responsibly and learn from it so we hopefully make fewer mistakes as time goes on. Remember that these small mistakes are far better than completely blowing a project as is possible without iterative development. Review your work every two weeks with your stakeholders and developers, and figure out what’s good and what should change. The end result will be a better product.

Mitigate what you can
Of course being decisive and learning during each sprint can be augmented by good story prep, usability testing, direct observation of your users as they work, and interviewing those users (though this last one is likely less useful than the others).

One of the things I really enjoy about being a product owner is the ability to just try something. Often you don’t know if something will work until you see it, so don’t be afraid to explore those possibilities along with the stories that are more predictable. You might just add a hell of a lot of value.

As always, love to hear if you think this makes sense in your organization (or not) and what experiences you have had with being a daredevil (who, after all, was that blind superhero guy who did a lot of leaping).

Addendum: I was at the AgilePalooza conference today in Los Angeles and David Hussman was giving the keynote. He said many noteworthy things (checkout #agilepalooza on twitter for others’ thoughts), but the point that caught my attention was about Malcolm Gladwell’s book Blink (this is a really good read, btw).  The main tenet of the book was that people usually make better decisions when they make a decision quickly rather than gather all available data, analyze, and THEN decide.  This complements what I was saying in this post — I think you as a PO must always be trying to understand your stakeholders, your current technology and see emerging trends better but when it comes down to a single decision…just make a choice, it’ll probably be the right one. Either way, inspect, adapt, and move on.

Add to DeliciousAdd to DiggAdd to FaceBookAdd to Google BookmarkAdd to RedditAdd to StumbleUponAdd to TechnoratiAdd to Twitter

Posted in Super Powers | Tagged , , , , , | 2 Comments

Super Power #6 – Shrinking

Byoooo!! You need the power to shrink (your app) because it will solve two problems I bet you have. One is that your team is not happy about what they see as “re-working” features they just created. The other problem is your stakeholders/customers probably ask for enhancements and you can see in your usage logs that similar features already in production are not being used.

Let me elaborate…

Problem 1 – Is it Re-Work or Learning?
When you’re first building out a system or set of features, I’m sure you prepare your backlog as best you can right? That means meeting with stakeholders and really understanding what they are hoping to accomplish. Then you help them envision what the product will look like based on those needs and formulate a draft backlog of stories (and story map if you are really on top of things). This makes you happy.

Then you have your first sprint or two and show the results to your stakeholders. They love it. Great! …except can you make this view show by currency instead of country? And can you let them group all the companies up into industry groups instead of industries? And can I have onion rings instead of fries? As a good agile product owner you know this is the right outcome because you have LEARNED from previous work and now have the chance to make it better for your users.

So then why do you get the evil eye from your team when you bring these new stories into the next planning session? I think it’s because in the times before agile, this kind of “re-work” was bad. It meant you didn’t finish your analysis or you got the requirements wrong. The thing is, even in waterfall you would have developed these same features, but you never would have gotten early feedback and the users would ultimately have had to live with their initial (sub-optimal) decision. The core problem here is that people (including you and me) are poor predictors of what elements of an application will succeed and what elements will fail.

Problem 2 – Simplicity vs. Bloat
Let’s say your application is now 12 months old. You have managed the backlog well which means that, all things being equal, you are working on lower priority features now. If you don’t have a ‘less is more’ attitude, you might begin to implement all the random nice-to-have stories your stakeholders brainstormed at the beginning of the project.

Hopefully, you can see this coming though and talk to your users about discarding these ideas – or trying a very rough version of them to see if they provide value. And if you are really feeling courageous (and have some usage metrics to back you up), try talking with users about eliminating features entirely. It is counter-intuitive but you may be adding value because you are increasing SIMPLICITY and ease of use.

There is actually a lot of controversy out there about whether you should try to be simple and meet basic needs well (e.g. Apple), or whether you should load as many features into your application as possible (e.g. Microsoft). I am in the first camp (but see here if you want to read a rant about the ‘more is better’ perspective). Interestingly, both camps agree that the majority of features in many applications are rarely used — I have seen statistics ranging from 5% to 30% of features being frequently used, but even 30% is pretty darn low.

A Solution to Both
To help me communicate about this to others on my team (and now you), I created a little illustration below encapsulating the agile version of “less is more” (click to enlarge…in case you have never been on the internets before). It essentially says this: developing 100 features without re-work feels like you did more than building 75 features with re-work UNTIL you realize that in the first (non-iterative) scenario only 30 features will be used AT MOST and in the second scenario 60 will be used. The jury is still out on whether you can get that kind of bump just from an iterative process, but I can say anecdotally that we have made several mid-course corrections to our systems that lead to much greater user satisfaction and use.

Do as little as possible.

As Jeff Patton said (and I paraphrase), “Our goal is to get the job done with the least amount of development.” This was a bit of a revelation to me – historically our efforts to develop applications inevitably became a game of adding every requested feature…and then struggling not to be crushed by the burden of bugs and production support that came from these overly complex systems.

I think there are big implications here and would love to hear your views on thinking small.

Add to DeliciousAdd to DiggAdd to FaceBookAdd to Google BookmarkAdd to RedditAdd to StumbleUponAdd to TechnoratiAdd to Twitter

Posted in Super Powers | Tagged , , , , , , , , | 1 Comment