Rune Gyldenløve


Notes, comments and thoughts on current interests of mine

The release

I think we underestimate the psychological effect of releasing software. Getting software, that you’ve put substantial mental effort into creating, out into production is a very fulfilling and satisfying feeling.

Nice as that is though, it is not the only reason why I advocate releasing every sprint. I believe in releasing every increment of product that you build for simple reasons:

  • Releasing more often will make you better at it and thereby lowering the risk of releasing
  • To release often you have to automate more – more automation makes less room for errors in your processes
  • Releasing software gives you the opportunity to get real user feedback on how that software is used. This in turn can spawn new ideas, help you kill darlings that do not work or make changes to features that yield unwanted effects
  • The “complete increment” or “potentially shippable”-rule of lean and agile respectively helps us keep focus on building functionality that adds value now as opposed to constructing “brilliant” or “revolutionizing” features for a future that may or may not come (which, granted, sometimes works against us)
  • A predictable cadence of frequent releases makes release planning easier and can alleviate the need for fix releases

And of course – having a target in sight keeps us on our toes – delivering on that target gives us that warm fuzzy feeling of satisfaction, sprint after sprint after sprint after sprint. The effects of that will have to wait to a later post.

Filed under: Uncategorized

Product owners in agile software development

A brief introduction to agile product ownership.

The Product Owner ensures that the final product contains the exact collection of features that is required to meet the business requirements. She does this by continuously prioritising the Product Backlog to reflect the priorities of the products customers, users and Business owners.

Product Owner
The Product owner in agile development is the key to value driven, incremental product development. The Product owner owns the product backlog and is responsible for it’s content and the prioritisation of that content.

By managing the product backlog the product owner effectively decides what to develop next. Given that we are operating in an agile environment we can assume that we are working on a ”fixed time, fixed budget”-basis. Consequently we must have the ability to vary scope. (If you work on a fixed scope project you are not in an agile environment).

The Product Owner makes sure that we use our limited resources to build the features that yields the most value. The Product Owner decides what does and what does not become part of the product.

Since the requirements for a given product has a tendency to evolve and expand over time we need to find a way to make sure that what we develop is the part of the requirements needed for the product to succeed – and only those features. Every feature put into your product represents a cost in terms of maintenance and evolutionary development. (Another aspect of this is complexity which invariably goes up when the amount of features increases but we will leave that out for now).

The tools we use to achieve the goals described above are prioritisation and time boxing.

The product owner needs detailed knowledge of how her product is utilised to be able to decide whether a given feature is truly needed to support the business case for that product or not. So, if you as a product owner can not answer the question ”how does this feature add value to my product” you’re headed for trouble. You should either investigate further into the matter to understand a features value or simply remove it from the backlog.

The Product Backlog
The Product owner writes a Product Backlog. Before setting about writing the user stories that will describe the requirements for your product you should be able to answer at least the following questions:

  1. What are the unique selling points for my product
  2. How will my product create revenue
  3. Who will be using my product
  4. How will my product add value to my customers

Furthermore you should define the goals for your project and a vision for your product. This will help you when we come round to prioritising the user stories in the Product Backlog.

A projects goal could be something like:

  1. Have a first version of your product released by a certain date
  2. The first version of your product should meet the business requirements from X department (Marketing needs to be able to create and release campaign sites in less than 4 days without the need for a programmer)
  3. A statistics tool must be implemented in the product to allow editors to do follow ups of readers interests.

The vision for your product describes what your product is really about. For example:
My product will be Europe’s best news site for east european citizens.

Obviously, your project goals should support your vision for your product. When you are working with your Product Backlog and need to make a decision whether to put a feature into your next iteration or not, simply asking: ”does this feature help me achieve the goals for my project and does it bring my product closer to my vision for it” will guide you in making that decision. Deciding between two candidates for your iteration will hopefully be easier in the context of goals and vision.

For more information on how to prioritise – try Mike Cohns ”Agile Estimating and Planning” or The Kano Model

Once you have decided on your project goals and is comfortable with the vision for your product you can begin to write the user stories that will make up part of the Product Backlog.

A good explanation of how to write user stories can be found here: Writing Stories. (From Mike Cohns book ”User Stories Applied for Agile Software Development”

Definition of done
You will need a few more documents to go with your Product Backlog. One of them is the Definition of Done. The Definition of Done is there to ensure that when someone within the projects says ”I’m done” everybody knows what that means. Sterling Barton has written a brief description of how one might go about defining a Definition on Done. It can be found here:

Technical prerequisites
Presumably your organisation has an IT or Operations department and sooner of later you will have to find out how they will support your product once it is to be released into the production environment.

Typically these are also the people who set up your developing teams environments (code repositories, continuous integration servers, test servers, stage servers etc).

Ask them to supply you with the information your developers will need and contact information your development team can use when questions arise.

Preferably, you as a Product Owner will also have a contact person from Operations who can act as a stakeholder in your project. Have Operations attend all meetings where decisions regarding the release of your product is made – typically your project steering committee meetings.

Ensure that the team initiates contact with your Operations contact person and informs him of their strategy for development. This should act as a sanity check of the road the team has chosen for fulfilling your requirements. If your organisation has a team of architects and they are not part of the development team don’t forget to do the same with them.

You will want to make sure that Operations commit to decisions regarding the release of your product. Keep in mind that a decision to make an earlier launch is not uncommon in within agile projects.

A plan for the release strategy for your projects evolvement after the initial release is a good thing to start discussing in an early state. If you plan to do frequent releases Operations need to plan for this – for example by automating deploys

Filed under: Role descriptions, , , , , ,


Get every new post delivered to your Inbox.