FEEDBACK IS A KEY TENET OF AGILE SOFTWARE DEVELOPMENT
A key tenet of agile product development is releasing early and iterating. This is because it is difficult to predict how users will interact with a product and what they will value most. Initial hypothesis are likely to be proven incorrect once users start integrating with the product. There are plenty of famous examples of ‘pivots’ in the marketplace – Paypal, Twitter, Flickr – but it doesn’t have to be as drastic as a pivot, it could be as basic as knowing where to focus the effort next.
Usually Product Developers attempt to identify, justify and specify all of the features they think they will need to launch a successful product, this is what they get funding to build. They try and maximise their budget and create value by trying to maximise the number of features they get built in order to maximise their chance of success. This approach creates waste.
Agile/lean product development favours the opposite, defining the minimum set of features required in order get it in front of users as early as possible, leaving observed behaviour and feedback via analytics/data and usability testing to dictate the priority of feature builds thereafter.
This is generally done by grouping features into themes, feature sets or clusters and prioritising to define a minimum viable product – for the purposes of this paper, this is the minimum set of features we need to launch to start receiving meaningful feedback. Prioritisation happens to take a long list to a shorter list, down to the few things that can be started, the number of which depends on development team size. A backlog is created, which is the subject of constant re-prioritisation, to ensure as the build progresses and the team understands more, only the most valuable things are focused on.
Imagine 18 features in the above diagram. 10 are features that aren’t valuable, very few of your users will use them and they won’t contribute to your product success. About 8 features are valuable and of those, 3 are absolutely essential. Without those 3, you won’t have a viable proposition, so this is the minimum viable product. The problem is at the beginning of a typical planning and specification phase, all 18 features seem equally valuable so prioritisation is important in order to find and focus on only the minimum viable.
Prioritisation is difficult and requires a deep understanding of the opportunity. It is often a negotiation between different stakeholders who have an opinion on needs that must be objectified as much as possible using evidence.
Prototyping and user testing is one way to objectify and gain this early insight but too much of it and the time between feature specification and release is elongated, which can be an issue when dealing with rapidly evolving user expectations and a lack of revenue! Also, if at some point the product happens to lose funding and you’ve been prototyping for 5 months, you will have nothing to show but some validated ideas. A balance is necessary and breaking down large builds into small increments will solve these issues.
Re-organising the features as above, we can see the 3 we must start with before incrementally building the other 5, hopefully avoiding building any wasted features through feedback.
TEAMS SHOULD BE EMPOWERED AND ACCOUNTABLE END-TO-END
To better understand what features users value most in a software product, agile is increasingly being adopted. To make this way of working effective, traditionally siloed organisational ‘functions’ are being reformed into multidisciplinary teams (or new types of silos if you like!) aligned to customer/product metrics and given end-to-end control to deliver on them. A value-stream is made up of people taking ownership of the product over its lifetime and an emphasis on cross-functional roles and individuals with broad skillsets.
Scrum Teams as a collective are responsible for determining what feature developments or increments best achieve their target objective (or metric) and prioritising them accordingly to focus on the most valuable. Scrum Teams are made up of a Product Owner, Developers, Scrum Master, Designers and are supplemented with Architects, Business Analysts and Project Managers depending on the organisation and/or initiative (e.g. a multi-channel initiative).
Product developers and strategists whom have typically conducted research and analysis in order to create visions, product portfolios, launch new products or features (Product Development, Strategy, Innovation) and those that manage them in market (Product Management) are combined and called Product Owners/Managers.
Engineers, whose traditional roles were to take specifications from a business analyst and write code, now have a responsibility to contribute to requirements definition. Those that would typically take a coded, built and tested product and maintain it in market are the same people/team that built it in the first place. The result is one team, with shared objectives, different but complementary skillsets, but increasingly generalists with different perspectives collectively agreeing on and guiding development priorities. Everyone is a product person and everyone understands operations.
Separate innovation, product development, product management, creative, engineering, testing, operations and maintenance teams create inefficiency when rapid change is required. This generally results in the organisation being less effective in building products that match user needs. Organising to remove silos and align to products creates a value-stream of people, processes and technology aligned to common objectives. The closer you can get to this nirvana, the more effective you’ll be!
Digital includes all those things that are required to create and take a digital product to market and keep it competitive. The role of the digital department needs to take direct responsibility of the revenue generated by digital products or the usefulness of internal ones.
- The Digital team exists solely to build and run software products to meet user needs and achieve a business objective, usually profit generation.
- The Digital team has a responsibility to define, deliver, operate, optimise and improve the software from cradle to grave.
- The Digital team includes all roles from Product, Experience, Design, Development, Technology, and Architecture working together under this common objective.
- Due to the nature of digital products, there is a heavy emphasis on the achievement of metrics rather than the delivery of specifications – metrics represent revenue generation and provide an indication of customer feedback.
- If you are working in silos to deliver products, you have a great opportunity to transform.
For more on the subject of digital:
[button link=”http://blog.northhighland.com/digital-part-1/” color=”blue2″ icon=”” size=”small”]Read Part 1[/button]