The Product Owner role in business application development

At the core of all agile/lean practices is the minimization of work in progress (WIP). The more WIP you have the less visibility and control over the actual output of work. You may have made a major error which has not yet been discovered and will result in reworking all other current work in progress. If your WIP is small (hours or days) than you have minimized this impact. If your WIP spans several months you may have a huge task ahead of you. The top three things required to manage WIP down are:

• Quick decisions - we need to be able to turnaround a question or clarification to a decision quickly, if not it is all too easy to just start on the next piece of work or make assumptions to keep moving
• Regular checking - when we have a requirement for quick decision we need to accept that some may be wrong (and we need to change direction). We can only confirm we're heading in the right direction with regular checking (automated and manual) to maintain the confidence that the WIP is complete.
• A team culture that focuses on collaboration - A command / control process with many 'quality' gates slows down progress and drives up WIP. To turn around a decision to a deliverable requires a highly collaborative approach where contributions from all parties are encouraged.

In Scrum, the Product Owner role plays a critical part in all three of these and is almost entirely responsible for the first two. So it's critical that you get a Product Owner on the project that truly understands their role. This role needs to combine authority (to make low to mid level decisions without the need to convene committees) and speed of decision making (so that WIP is minimized). So in theory the perfect Product Owner has complete authority to make decisions and is available to turn around those decisions quickly (same day at minimum)

Whilst this is certainly achievable in small organisations or software solutions that support a small silo in an organisation, in most reasonable sized business projects this position doesn't naturally exist and all too often we don't identify a single Product Owner and adopt alternate methods:

• The IT project manager (or Scrum Master) assumes the role with inevitable consequences. Assumptions are made to keep the delivery moving and WIP down, business users reject those assumptions later and rework is required, which will lead the project manager to become more cautious and require signoff from stakeholders, eventually moving the role to a low authority / low speed point - exactly the opposite of where we want it.
• A steer co is setup to handle decisions. Whilst this is appropriate at a high level (should we undertake this project or not) it is not appropriate for the minutiae of decisions required during a project and results in a very slow decision making process and driving up WIP in an attempt to maintain delivery pace.
• Alternate options include an Executive sponsor (not highly available, but with authority) or
• Relying on stakeholders - usually more available and responsive than execs, but if there are more than a couple the decision making authority is completely diluted.

With none of the above options being ideal, a Product Owner should be appointed with:

• Authority from steer co and sponsor to make decisions on their behalf (monthly steer co sessions to keep them on track)
• Knowledge of the stakeholders business processes and the ability to look ahead in the project backlog and consult with them on future requirements
• A close working relationship with the IT project manager (or scrum master or scrum team) to provide fast turnaround on clarifications / decisions to keep them moving in the right direction

Getting as close as possible to the ideal Product Owner is probably the single biggest factor in successfully delivering agile solutions. I've been lucky enough to have worked with a few business people who are 'naturals' in this role, but for each of them there are many more who fail either through indecision (I'll need to check with...) or abdication (Can't IT just figure it out?).

Development skills interchangability - 'Online', 'Backend', and 'Mobile'

Many business systems these days are written as web applications - either hosted in the cloud in a true multi-tenanted environment or on the internal corporate network. They are often written using the same technology set as consumer web sites. It would not be a stretch to assume that developers who have worked in these technologies can switch between them freely. Whilst this is true in general there are many issues which are particular to one type of system and not the other. For example:

• Performance. Whilst performance is an issue for both types of development the causes of performance issues are often quite different. In online apps it's often caused by sheer volume of requests - an architecture supporting a high read/write ratio is going to be of most use - caching, separation of responsibility (CQRS), scalable architecture. In business systems performance issues are more generally the result of low level algorithm choices. The former is a more challenging architectural issue, the latter a more challenging coding issue (which is why back end developers believe they are the 'real' coders)
• Deployment. Again both environments have deployment challenges. But back end deployments are usually more 'big bang', easier to schedule (any weekend is fine), but are likely to have more integration points with other systems and more complex pre and post deployment testing cycles. On the other hand online deployments are about limiting or eliminating any outages required to perform the deployment. Again this comes back to a quesiton of system architecture, if your deployment takes a scorched earth approach where you spin up new servers, deploy new code, run automated tests, then instantly cut over you can (with careful state management) perform outage free deployments.
• Feeback. User feedback is critical to any good software. With business systems you can just ask the users. With public sites you can do that as well but you also want to track and analyse the data collected from the site.
• Development process. I've been a proponent of agile practices for a long time I think they're suitable for both environments, however it fits perfectly the online environment as you want to be making lots of small incremental changes and have the ability to quickly change direction should your analytics prove you made a mis step. Most software development groups would now be at the stage of using unit test and continuous integration. Online teams should also be considering continuous deployment and strong feature management (so we can disable a feature that has been deployed if required, or A/B test a feature we want to assess)
• Browser support. Business systems are developed for 'captive' audiences where a standard browser / operating system can be mandated or controlled. This makes it easier for developers to develop and support. Online needs to consider both browser and device with a huge percentage of web traffic moving to mobile devices all online content needs to be responsive and designed appropriately for all browsers and screen resolutions available.
• Usability. Business systems are used by regular users doing their job. Their user interface needs to allow them to complete that job as efficiently as possible. It is acceptable to place a lot of controls on one screen IF it is achievieving that aim. The online user is usually an infrequent (and at best a casual) user of your site. Their UI needs to be as intuitive as possible (and if under an advertising revenue model one that delivers more page impressions!). Whilst UX is important in both cases the lack of available user feedback means you need to pay more attention to it in the online space.

Of course whilst we're talking about online development there's the question of mobile. Native Apps, Hybrid Apps, Web Apps, Mobile friendly web sites all come into the picture and choices of which to adopt depend on a range of factors including device feature accessibility (GPS, camera, etc), performance of the application, level of disconnected use supported, usability requirements, marketing / discoverability, and obviously cost of development (and on going maintenance). In the modern world of web development - where changes can be deployed at will with little regard for backward compatibility issues the on going effort to maintain native apps should not be underestimated - it's more akin to client/server than web development (and it's not really like either). Native apps should only be used when the device features, access to specialised gestures, or speed is of a major concern.

So can developers move freely between these environments? Of course they can, but whoever is leading the team (and determining the architecture of the solution) needs to be familiar with the potential issues.