Embrace agile values and priciples
This article is based on own experiences and reflections about Marty Cagan's best selling book Inspired. The key to succeed with your efforts of becoming a true agile operating company is not on rolling out agile methodologies like Scrum, Kanban or a mix of both. On the contrary, as a company you need to understand and embed agile value and principles. This is a long lasting process of change, it takes experienced ambassadors with authority and enthusiasm, people that stand up for the idea being agile and are able to convince your team(s).
Managing change
When organizations reorganize product development processes towards agile methods the motivation for doing so is often either following the trend and/or the expectation of being able to deliver products faster. Thereby the underlying values and principles of true agility are being forgotten or worse never understood. Moreover, when it comes to managing change it often gets worse before it gets better. I've seen companies where this change process stopped somewhere along the way. To become truly agile cope with setbacks and be persistent.
Processes are not key
One trap, when it comes to introducing agile processes like Scrum, is that it may end in contradicting with the first agile value: Individuals and interactions over processes and tools. Whereas processes provide a good framework for orientation it is ultimately just a mean to an end and not the desired outcome. Thus, if you are too focused on getting the Scrum artefacts right you may end in a waterfall like paradigm.
Agile waterfall trap
If the product owner sits down, writes the user storie based on what clients or upper management want to have achieved and passes on the task to the engineering team to implement it within their sprints, then this is not an agile process. This is rather waterfall with agile buzzwords. It makes the engineering team to the sole recipient of orders. Therewith dismissing major advantages of being agile:
- the team must work together. Involve all disciplines from your team (engineers, designer, product) from the very beginning to achieve a common understanding of the business problem and a sense for accountability
- innovation often evolves from engineering perspectives, you dismiss great possibilities by soley keeping them the recipients of orders
Demonstrate the agile idea
Sure, for managing change we need a frame to interact in and processes that provide orientation. However, to become truly agile the team needs a leader that demonstrates agile principles throught the day, in the way decisions are made and work is approached. It is about the following key principles:
- focus on valuable software delivery
- learn continously and be open to changing requirements
- promote a sustainable development pace (!)
- be self-organizing, trust your team mates and work togehter
- pay attention to technical excellence
- reflect your approaches regularly and tune it accordingly
Product discovery
This is where you set the stage. As a team in the product discovery phase you make the decisions of what ideas you are going to implement. Those decisions have a major influence on your product outcome (think about customer satisfaction, behavior change). And your outcome (not output!) has a major influence on the impact (think about ROI, brand awareness) of your product to the market. Go with your team along a discovery journey. Sometimes those journeys are straight forward and other times you need to invest into prototypes and testing to elimiate associated risks and validate whether your ideas are worth implementing.
Outcome, not output
Accustom yourself with the fact that nevertheless how quickly are you deploying features, there will always be more product ideas and requirements than what your product team is capable of implementing. And it is also not about implementing as much as possible in terms of outcome because a product with 100 feature of which 90% are useless provides less customer value than a prodcut with only the same ten useful features (at least from a usability perpective).
In other words, a great product team is concerned about the outcome of their products. This is why you should always keep a close eye on how your customers are using your product and how well does it solve their business problems. Do not just take new requirements for granted: Instead question them. Figure out who asked for it. And what problem it is intended to solve? Why is this a problem you should care about?
Managing risks
Assessing the risks with each idea is crucial. Your team should address the following questions to understand the potential and risk of the respective idea:
- Value risk: Is the product idea solving a customer problem?
- Usability risk: Are your users able to understand and operate with the product?
- Feasability risk: Are you as a team able to build the product?
- Business risk: Does the product work within the constraints of your organization?
Start with the most pressing risk first. Discovery is all about learning, the quicker you learn that a certain idea is due to high risk not manageable the better. Then you can treat your discovery journey a success and elaborate on the next idea.
Discovery techniques
[wip]
Product delivery
As soon as the risks for a product fail are eliminated or at least classified into a range where the likelyhood of product success significantly exceeds product failure the delivery phase can start with the goal of delivering working software.
Implement with execellence
[wip]
Assure quality
[wip]
Deliver savely
[wip]
Further resources
- Agile manifesto with the four core values as base for agile software development
- Agile principles are guidelines for working truly agile
- Inspired a book by product manager veteran Marty Cagan about how to create tech products customers love
- User Story Mapping by Jeff Patton explains how to serious product teams can raise their game to the next level to build the right product