Product Owners’ guide to Agile Scrum. Part1 – The growing difficulty of change

Agile development has taken the world of software manufacturers by storm. Versatility, flexibility, ease of adapting to change are but a few of the many advantages held over classic, waterfall methodology.

Although internally, software houses introduce agility relatively easy, having proper training, practice and continuous improvements, the process often requires clarification for the client, represented by the agile product owner (often the same person). 

Agile project management relies on brainstorming, contribution, and cooperation of all the team members, rather than on a thoroughly defined plan and following documentation. A typical agile team, eg. working in Scrum methodology is made up of three main actors – a Product Owner, a Scrum Master, and a collective of a Development Team. For the larger part, an agile team is supplied by the software development company, but the Product Owner is an external, untrained and at most times the most inexperienced member of the team. Yes, being a client of an agile app developer, you (or someone appointed by you) become, for the duration of the project, a part of the team.

As there’s a tendency among businesses to actually hire product owners, let me share a little tip for starters: Don’t hire a guy to own your product – if you can’t do it yourself, find a product owner among your loyal employees – someone who knows and shares your vision.  

The Agile manifesto

Agility of development requires prioritising (not replacing) certain values over others. People’s interactions over processes and tools, releasing working software over completing documentation, Product Owner’s collaboration over contract negotiations, and most importantly – responding to change over following a plan.

The last two prioritisation are arguably the most important and client dependent, and adequate Product Owner’s input in both of them is crucial for the project’s success.

More about Agile Manifesto Principles you find in separate article.

Product Owner Role

Here’s how developers expect the product owner to contribute in particular phases of Scrum agile development. We will concentrate on the in-team communication with the product owner, as all the external influence and interactions don’t belong in a Scrum methodology and can be both disruptive and damaging to the process.

Who is a product owner?

Working as a product owner means becoming an integral part of the team. You will be required to be in regular contact with the rest of the team from the very beginning of the project. Your main job is basically to tell the rest what to do… or rather what it is that you expect the product to be. The vision, idea, business value, expected User Experience, brand identity – all of them are up to you to communicate and approve with your Scrum team. You will also be a SPoC – Single Point of Contact – communication bridge between Scrum Team and rest of involved parties

The best way to contribute to the project’s success is having a clear vision of the product you are ordering.

Responsibilities at each stage of project

The project Initiation

At this stage, the project will start taking the general shape. Expectations, requirements, timeframe, and scope of works is supposed to be outlined here as comprehensively as possible. You, as Product Owner, should know what you want. It’s your product being developed and you are the only person that is able to define the functionalities, looks, features of it.

You are also the one that will be accepting the proposed solutions. All of your requirements will be put together to create a project’s backlog – a list of all the parts of the product that need to be developed.

Change it when it’s the easiest

At this stage, adaptability to change is the simplest. As everything is so far done only “on paper” with no actual programming involved, changing your mind about this or that is easy to facilitate and doesn’t cost (precious) developers time just yet. Feel free to question, disagree, propose and change your mind to your heart’s desire. The more is clear about your ideas at this point, the better (and cheaper) for the future progress of the project.

Design

After establishing the Product Backlog, your product’s design can commence. Here, your role will be to accept the proposed solutions or reject them and look for better options. Until you’re happy with the results, the team will keep changing, adjusting and perfecting the product design. The more feedback they receive from you, the more satisfactory the results will be.

Introducing changes both major and less significant at this point is still an easy process, but it’s worth keeping in mind that by now more work and time of the team members are involved. This means that it’s good to consider the significance of the change. Will it make a difference? Add value? Be worth the money spent?

Change is welcome, when it makes sense

As much as agile development welcomes change and has the capacity to adjust to it, the reality is that the later the change is introduced, the more complicated and time consuming the implementation of it becomes.

At the design stage, it’s good to think ahead as far as conceivably possible about the consequences of altering the product. The vision of your its final shape should be fairly complete by now, and all the important pieces included in the Product Backlog, ready for development.

Product development

This is the stage where the real (read: expensive) work starts. Splitting the backlog items into Sprints, establishing time frames for each Sprint, defining deliverables and conditions of approval. It will be important for Product Owner to be present at each Sprint start – to establish and agree on the Sprint Backlog. If any issues arise or clarification is required during the Sprint, you should also make yourself available to the team.

Identify and address issues early

The quicker a problem is addressed, the fewer resources it will take to fix it. Typically, Sprints are completed in 1-4 weeks, depending on complexity, the size of the backlog and projected issues. This is the phase of your project, where introducing change will become increasingly more problematic.

The rules of Scrum require each Sprint to be a closed unit once initiated. This means you cannot add new items to the Sprint Backlog when it’s already running. That includes not only items from the Product Backlog but any variations or changes to items in the current Sprint.

Changes and adjustments are best proposed at the Sprint Retrospective. In Scrum this is the time all the Sprint work is reviewed and issues needing attentions identified.

Don’t mess with a running Sprint

If you think a change is unavoidable and regards a currently running Sprint, your best and cheapest option is to abandon the Sprint all together and start over with a new Sprint Backlog. Any alterations must be put in the Product Backlog first, and afterward, they can be included in the next Sprint.

Alternatively, a whole new Sprint can be created for the change itself. This is recommended for any changes that extend the duration of a Sprint beyond recommended 1-4 weeks.

Loose some to win some

The changes you propose for the project may have various effects on the timeframe and the overall cost. It’s worth considering reduction of the Product Backlog items by the items that are not crucial or which can be developed later. This will offset the T&M losses produced by the introduction of new features or other changes.

The difficulty of introducing changes increases with every completed Sprint. Alterations that may seem simple from your point of view may require considerable changes to the code, so it would be best to leave the estimation of the required resources to the specialists. If what you hear from them is not to your liking, maybe it would be better to leave things as they are and continue the project according to initial requirements.

The further the development progresses, the more parts of the product will be completed, tested and working. If you decide at some point that you no longer require a certain completed item, remember that the resources have already been spent on it and just because the item will not be included in the final product, doesn’t mean it’s not billable.

Want to know more about the development process? Read our Android & iOS app developer guide.

The testing

Once the product is completed, it will be given over for testing. Although particular products of Sprints will have been tested already, now that they are put together into a complete, working product – we need to see if it was put together right. The final testing is crucial at this point, to find out if all the pieces of the puzzle fit together and comprise your ordered product.

At this stage of work, the matter of introducing changes becomes highly problematic. Adding new features, screens or functionalities to a completed, untested product is from a programmers point of view a nightmare.

Time is (Client’s) money

They might not (although they should) tell you this, but often a change might mean gutting the app’s code and rewriting huge portions of it, altering parts already made and tested, or in extreme situations, you might hear that to do what you’re asking, the project needs to go back to the drawing board.

This translates directly to costs and time. It will create issues of possible need to adjust the team, delay planned work of testers or adding a specialist that was not initially included in the project, especially if the nature of the change falls far outside of the scope outlined in its initial phases.  

Final testing is the phase where any change translates directly into a vast increase in cost. The bigger the change, the higher the price you pay, and the longer it will take to implement.

Early bird…

At the beginning of your road, you got an estimate of the project. For any reasonable developer, it included a certain overhead for changes or unforeseen circumstances, but no one estimates with overheads for defying reason.

Agile principles and values do welcome change throughout the development. The “cause and effect” nature of software production carries certain consequences when the timing of the changes is wrong. The consequences of early changes are small or even negligible. The later you propose them, the more painful the alterations become, both to the developer and your wallet.

Once you build a house, it’s hard to un-build it

In short, you could compare agile software development to building a house. When just talking over an idea (initiation) for it – changing stuff is free and easy. Once you give it to the architect to design – changing your mind about the shape of it will cost you a little.

Once the building (development) starts – introducing alterations will cost considerably more work and materials. Once the building is complete and ready for final inspection (testing), trying to change stuff will mean taking something apart and starting over.