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.

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.

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?

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?

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

UPDATE
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…

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.

WordPress(.com) won’t let me embed the survey using an iframe so just go here.  It’ll probably take you about 3 minutes.

There’s a place you can throw in suggestions too if you think some piece of the puzzle is completely missing.

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, I 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.

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.

Get high. Just remember to come back down when it's time.

Flying (at different altitudes) is one of the most critical super powers of an unbreakable product owner. As a PO, you need to keep your audience in mind and adjust your vocabulary and level of detail accordingly. Too little for the development team and they will build a skewed version of the feature, too much for the executive sponsor and you will lose their interest and possibly their support. And you have to fly in between them as well when you are discussing the project with other IT professionals or mid-level working groups in the business. The real-world power here is empathy – putting yourself in the shoes of the people with whom you are speaking.

When discussing things with a team, be specific. Really set aside the time you need and research your stories in-depth so you can provide all the necessary details. Clearly write out the backlog story and highlight key acceptance criteria. Everything beyond that needs to happen in discussions during planning and during the sprint. I personally love the business analysts I work with too, because they help me cover all the details I miss with my strategic, rather than tactical, mindset.

When reviewing the latest sprint’s efforts with stakeholders, you need to give them all the practical details, especially the visible changes. You also need to communicate in a non-techie way about the changes they cannot see. This is difficult as you emerge from the nitty gritty of a sprint but you will lose your stakeholders if you give too much detail. Definitely say things in layman’s terms like, “When you enter a number in this box, it calculates the duration. And it lets you undo it by clicking…here.”

Definitely DON’T say, “When you select this field with your mouse and enter the appropriate data, it generates a message that calculates the duration using the e=mc squared divided by pi, formula. Then you can revert to your original state by selecting this widget, that accesses up to 10 of your previously made decisions.” None of that is bad information – have it ready if they ask, but they do not necessarily want to know all of the fascinating detail you now possess. Every one of us occasionally “builds a clock” when someone asks what time it is, but resist. They will love you for it. I’ll go into the problems this “Curse of Knowledge” causes when I review the book Made to Stick.

And for that 30,000 foot altitude I mentioned above, see my post on selling your ideas to high level executives.

I used to be annoyed that I had to repeat myself so many times as a product owner, but over time I have realized that it is actually translation, not repetition, and it is very valuable to everyone when you can fly back and forth to different altitudes with ease.

Addendum: Realized I was not clear about the context here (as pointed out in the LinkedIn Product Owner’s Help Desk group which you should join!) – you should absolutely have development team members talking directly with stakeholders in reviews, story mapping, etc.  This was just intended to highlight that POs have a responsibility to understand business jargon as well as technical jargon and make sure communications are smooth.

The 'line in the sand' conversation.

But don’t worry, you as a product owner super hero have your trusty utility belt containing a “line-in-the-sand-conversation”. And it goes something like this:

UNBREAKABLE PO: Stakeholders! I am excited to report we have completed over half of the original project scope! On top of that, we have made many adjustments and additions with your help that have resulted in a project far superior to the one we originally envisioned together.

STAKEHOLDER: That’s great! So at the beginning you said you could deliver everything by July. We’re still on track for that, right?

UPO: Hmm…no, but thankfully we have been regularly reviewing the priority with you every two weeks so those features that will not be in the application are definitely the lowest priority features. Let’s review that list now to make sure we still have it right. I have drawn a line under the last story we will be able to complete. Everything below will have to be part of the next version [or release].

STAKEHOLDER: Looks good but can we just try to squeeze in those three things right under the line?

UPO: Yes dear stakeholder, you can absolutely have those three new features before the end of the project…what would you like to tradeoff so we can make that happen for you?

STAKEHOLDER: They don’t fit huh? Well how do I know how much we need to tradeoff?

UPO: No problem. We have put a rough size estimate next to each story…we call those points. Don’t worry about what the numbers mean, you just need to trade off about the same number of points for the stories you want us to include.

STAKEHOLDER: Alright, let’s get started. How about this 3 point guy right here, that’s not critical…

…AND IT BEGINS…

This is a simple but magical technique, one I have used a number of times with different stakeholder groups and it seems to bring out the rational side in everyone. If you clearly lay out the rules like this, they tend to play by them. Crazy right?

The first time I did this I expected a big conflict but after a tiny bit of exasperation, my stakeholder/sponsor began trading. Obviously, waiting until halfway isn’t ideal so if you are tracking the project burndown and notice things getting off-course by more than a day or so, think about having this conversation. I like to give it a little time as velocity sometimes picks up as a project progresses and the team gets comfortable with what they are doing.

Let me know if you do something different or how this works for you once you try it.