This

Agile Transformation is hard. You need a big appetite.

Appetite for change.

Name Your User Stories

Even if you’re new to SCRUM, you almost certainly know the popular user story format, ‘As a (type of user) I want (a goal or desire) so that (some benefit is obtained)’. Some people will put the pieces of this structure in a different order so you might see something like, ‘In order to (obtain some benefit), as a (type of user) , I want (a goal or desire)’. Either style is fine.

These ways of writing user stories are popular for good reason. If written well, they can be estimated easily, set the context for further discussion, and are adaptable to change.

Captain Obvious to the rescue

But this canonical format can feel a bit wordy when all you want to do is convey which story you’re referring to in a conversation. There’s a very simple solution that’s often overlooked by some people after they’ve been shown the ‘right’ way to write them. Just add a story name to go along with the fully written version.

Let’s say your story looks like this: ‘As a payment processor, I want to record a payment received from a customer so that they receive credit for the payment’. Now if you want to talk with the team about the story, saying, “Hey, let’s talk about the ‘As a payment processor, I want to record a payment received from a customer’ story” is going to feel like quite a mouthful. But, “Let’s talk about the ‘record a payment’ story” rolls off the tongue a lot easier. This can also make backlog grooming a lot easier because looking at a pile of note cards or a list of stories with the stories fully written out can make your eyes do funny things.

Yeah, yeah, I know. This is so obvious it’s hardly worth mentioning, right? Maybe, but I’ll go out on a limb and say some people’s lives as a PO just got a lot easier.

Thoughts on Agile2012

What a week. I just spent five days in Dallas (Grapevine, TX to be precise) at the Agile2012 conference and walked away with a head full of good stuff. Here’s a brief recap of my experience at the conference.

Value is king

Value may be king, but with so much learning and understanding required to change the mindset of traditional software development to that of an Agile mindset, the rigorous focus on value that is so important can too easily fall by the wayside. But the value proposition was alive and well at the conference. There were 17 sessions on the Business Value and Working with Stakeholders stage alone and, as you might imagine, the need to focus on value was emphasized throughout.

Agile transformation is hard

The sessions I attended and the people I talked to solidified my belief that transformation from traditional software development to an Agile approach is very difficult. In a way, it was comforting to be reminded that I’ve got a lot of company on this long journey. Needless to say the conference had more help to offer than I could even take advantage of. Just look at the sessions that were available to choose from.

The Product Owner role will (and should) change

I talked to a lot of people about the Product Owner role and there’s a common thread that ran through our conversations. First of all, a lot of people are not fans of the term itself. The word ‘owner’ seems to bump a lot of them. Secondly, the PO role is conceptually flawed in the eyes of many. It’s not hopelessly flawed, but it is flawed and I think we’re going to see some important changes in the near future.

When first learning about SCRUM, many people are taught that the PO is the decider, the single wring-able neck. If anything goes wrong, it’s the PO’s neck on the chopping block.

That’s right, kids, the A-Team existed long before the 2010 movie.

But what about all of the other people who burn a lot of calories helping to create a vision, understand the market, define a product, market it, and get it into the hands of users?

Enter the concept of Whole Team Product Ownership.

The care and feeding of a product requires a lot of effort from a number of people, not just the PO. And any good PO is going to listen to the thoughts, opinions, and guidance of everyone involved. I don’t think the PO role is going to go anywhere, but I think we’re going to see more about shared ownership of products with the PO evolving into more of a leadership role. This is a good thing for product owners.

Agile ideas never stop evolving

On Wednesday evening, I was serendipitously asked to join a group of Agile practitioners in a discussion about the course curriculum for product owner certification courses. I suddenly found myself at a table with 15 plus certified trainers, a couple of Agile luminaries, as well as other product owners like myself. Although talking about curriculum might sound boring to some, these couple of hours were a highlight of the week for me. I got to enjoy listening to and talking to a bunch of really smart people about things we’re all passionate about. I think a lot of the evolved thinking about the PO role is going to start making its way into training courses and our daily lives as a result of the efforts the group is undertaking.

Agile2012 is a great place to network

It doesn’t take long before you realize that you’re surrounded by a lot of people who want the world of software development to change. And by change, I mean improve. And by improve, I mean stop doing the wrong stuff and start doing more of the right stuff.

I got to spend time with some old friends and make a lot of new ones. Connecting and reconnecting with so many people trying to do great things was inspiring and gave me a renewed sense of wanting to change the world of software development.

If you have ever been on the fence about going to the conference, get off of it and be ready to register for next year’s conference in Nashville, Tennessee from August 5-9, 2013. This is a tremendous opportunity to learn, teach, network, and be energized and it’s one you don’t want to miss.

There is no try

Shippable: You keep using that word

Shippable. Funny how a simple word can cause so much confusion.

One of the first things you learn when you dive into SCRUM is that the team will produce shippable software at the end of each sprint. At the end of every two weeks I, the product owner, will get to lay my hands on some new features that will work and provide value to the business and that’s great because that’s what I care about. I’m making sure value is being realized each sprint. I could even ship this software (or migrate to production, as the case may be) the day after the sprint ends because these features will be shippable. Fantastic, right?

Whoa there. Not so fast, cowboy.

What’s the problem, you ask? If it’s shippable, why can’t I, you know, ship it? Because when Agile people say shippable, they don’t really mean shippable.

Then what does it mean?

Jeff Patton says that shippable refers to the quality of what’s been built and I think he’s right. It means that it does what it’s intended to do, the code is supported well by unit and acceptance tests, it meets the team’s definition of done (the team has one of those, right?) and is up to the high quality standards of the team such that it could be shipped (or migrated to production) and you’d sleep well, confident that it won’t blow up after it leaves your loving care.

ShippableWait, what’s that? You say you became a Certified Scrum Product Owner and during your [2 days of] training you were told that you’ll work with the team to deliver working, shippable software at the end of each iteration and that, if you wanted to, you could deliver it to users at a moment’s notice?

No, you probably weren’t. At least I hope you weren’t because much of the time, especially early in a project, it’s not even possible. C’mon, think about it. Say you’re building a new system from scratch. You don’t really think you could build enough functionality in your first sprint to release it, do you? Of course you don’t. So if you’re new to this, don’t worry when you finish a sprint with a feature that isn’t fully baked. Many times there are very good reasons to be in this position at the end of a sprint.

Let’s take a very simplified example to illustrate what you don’t want to get caught up on when it comes to producing shippable software.

Say you’re building a web application. It’s early on in the project and you’ve got a couple of basic pages already created, but there’s much more work in front of you than there is behind you. You’ve got a fistful of user stories and to satisfy the needs those stories represent, you and the team have decided you will need to create a new page that will have three widgets on it.  You and the team know those widgets are going to be very challenging to create. To make matters worse, if you don’t get the widgets right, your users are going to be very, very unhappy. These are very important widgets, got it?

You decide you want to take on these risky stories in your next sprint so that if there are going to be any surprises, you can flush them out now and deal with them.  Then someone on the team pipes up and says, “Hey, wait. We forgot about that little user story we have about making it possible for the user to navigate to our new page of widgets. We have to do that story in this sprint too, otherwise our product won’t be shippable because the users won’t be able to get to the widget page.”

Easy now, don’t panic. Why? Simple – you’re not going to ship it right after the sprint ends so that’s not your biggest concern right now. Your biggest concern is making sure these difficult (read: risky) widgets get done and work as expected. You can worry about navigation later.

But be careful because I’m not suggesting you don’t ever need to be concerned with being in a truly shippable state. In fact, the more you deviate from that state the more risk you’re assuming. Business priorities can, and do, change on a dime. If they do change, you could get a call at any time telling you to wrap up whatever you’re doing on the project and release the product into production immediately. So although you’ve probably got some flexibility, always keep your short-term goals in sight. If you’ve got a release date set for your widgets, and I hope you do, then you’ll need to manage the backlog properly so that you’ll get to those navigation stories in time for them to be completed and in your release.