This is the Engineering Culture Podcast, from the people behind InfoQ.com and the QCon conferences.
In this podcast, Shane Hastie, InfoQ Lead Editor for Culture & Methods, talks to Kent McDonald, Steve Adolph and Ryland Leyton about the state of business analysis and product management in agile product development. They were participants in a weekend workshop where the Agile Alliance and the International Institute of Business Analysis were collaborating to produce a revised version of the Agile Extension to the Business Analysis Body of Knowledge.
Key Takeaways
- Analysis skills are necessary for successful product development
- We don’t question and challenge the rationale and strategic alignment of projects enough, which results in lots of waste from doing the wrong projects or building the wrong features in a project
- The best return on investment that you can get is to stop wasting your money
- Value is hard to define but crucial to identify; the definition of value will be different in every context
- Agile methods provide for learning and rapid feedback, which enables us to optimize value and ensure strategic alignment in product development
- User stories are conversation placeholders, not orders to be fulfilled
Subscribe on:
Show Notes
0m 49s Introducing the participants.
2m 14s Tackling the misconception that agile development doesn’t need analysis. In a rush to adopt agile, some organisations dropping analyst roles without understanding the implications of doing so.
3m 27s There is confusion about what role business analysts can play in agile development.
4m 01s There are several different models for incorporating all the skill sets needed around analysis, product ownership and product management.
4m 37s Analysis in agile environments is still needed and the skill sets are necessary for successful product development.
4m 53s Analysis is about identifying what the actual need is, challenging to ensure that the need is real – should we even bother trying to address this at all?
5m 00s The hard questions about whether a problem should be solved are frequently not asked resulting in lots of waste.
5m 20s The social and collaboration skills become more important in agile development. The underlying skills of analysis are still crucial to success.
5m 39s The need to be a boundary spanner bringing different perspectives and viewpoints together.
5m 57s The need to move away from order taking to boundary spanner. Analysis in agile development is a very social role.
6m 15s Analysis skills reside in many different roles and doing analysis in agile development is far less prescriptive that has been the case.
6m 44s You need to have a very comprehensive toolkit and have the ability to relate the tool needed to the context of the work being done.
7m 13s What organisations need to do in order to get the maximum benefit from analysis skills.
8m 22s Value management is a new skillset that is needed – avoid waste and only do what is valuable and aligned with organisation strategy.
9m 40s Being able to pare down what is being done to the essentials and reducing the wasted work is the way to actually get the benefits that organisations are looking for when they adopt agile development.
10m 17s Analysis skills needed to constantly refine the backlog and help the product owner see when enough of any feature has been delivered; being able to stop work on one piece and move to the next piece of value.
10m 35s Do the thing that has the most value and don’t be afraid to kill a project if the value isn’t actually there. The best return on investment that you can get is to stop wasting your money.
11m 05s Three skills needed to be successful in agile development:
- Your professional skill (UX, development, testing, design …)
- Skill in the use of agile techniques (how to participate in an agile development team)
- Collaboration skills
11m 40s Some product owners have good product skills and good analysis skills, however many don’t and they need to be supported by someone who does have.
12m 13s What is value? How do we identify the value in a product backlog, how do we know when to stop?
12m 38s Value is complex, it comes in many forms and is dependent on the context of the work being done. Sometimes it really is, “I will know it when I see it”. For any feature:
- What revenue does it generate for us?
- What opportunities does it open up for us?
- What risks does it reduce for us?
- What social good does it enable us to do?
- How does this contribute to us meeting the organisation’s strategy and objectives?
13m 52s One way of examining value is “have we satisfied the needs which we determined were important to meet our strategic goals?”
14m 09s An important conversation to have very early in an initiative is to ask what value means in this context, because it is different in every different context.
14m 58s A technique to help identify value in an item is Four Box Prioritisation:
- What is the value to the business of this thing?
- What is the value to the customer of this thing?
- What is the dev estimate (size/cost/points..)?
- What is the cost to the organisation if we have this thing?
Use this to help prioritise features for development.
16m 44s Sometimes you have to force-rank the backlog, and this can be problematic where there are different stakeholders with conflicting viewpoints.
16m 58s Find ways to make “value to me” visible as well, in order to expose hidden agendas (“I want this feature because it will help me get my bonus”)
17m 38s How do we help organisations take this way of thinking into the way of working?
17m 53s Explore value in the organisation’s context and then use it to help make decisions, and stick to them.
18m 35s There is a push to move away from projects towards product-based delivery. There is a risk with a product focus that we are unable to stop work because the product has taken a life of its own. Sometime the best thing to do is to abandon work on a product because it has outlived its usefulness to the organisation, or the cost of maintaining it exceeds the possible return.
19m 35s Agile methods give us the tools to provide feedback mechanisms and expose the real value, or lack thereof, in a feature and adapting to the feedback quickly enough that you can steer the development towards better outcomes.
20m 35s It’s important to understand that we are spending real money when we iterate around a feature, so find ways to make the cost of learning and feedback as low as possible.
21m 00s There are ways to reduce the cost of feedback, such as paper prototyping and low tech tools.
21m 30s Modelling seems to have gone out of fashion with the adoption of agile. Models are a cheap and quick way to narrow the solution options and reduce the length of the feedback cycle.
22m 05s Use prototyping and modelling to help overcome the “I’ll know it when I see it” response to needs analysis.
23m 30s What is next – what is the future of product management and analysis?
24m 02s Building the right things, and support that with devops to ensure we build them the right way and get the feedback that is needed.
24m 44s Many organisations that have adopted agile have missed the strong engineering practices which were actually a core part of the ideas from the very beginning. The practices from eXtreme Programming that have been around for 15 years but often neglected or overlooked.
25m 01s We are starting to see more conversations about addressing the upstream activities – where does the product backlog come from, at the same time DevOps is giving us visibility into the downstream activities, and we are able to see the end-to-end view of value delivery.
26m 55s Champion the idea of “How will you know”, looking at any feature or backlog item and ask the hard question of how we will ensure there is actually value there, and what the metric is for identifying the value. Everything we do must be linkable back to an intended outcome and have a metric which tells us if we are getting closer to the outcome.
28m 01s We can and should have both value and intent as part of the backlog, however very few organisations have the level of discipline needed to make this a regular practice.
28m 50s Many teams have forgotten that the items in the backlog are placeholders for conversations, rather than directives that must be implemented unthinkingly, however some teams and organisations are getting it right.
30m 40s A measure of agile maturity is the ability to have the conversation with the whole team about where a backlog item fits with the overall product vision, why the item is there and what it is for, then allowing the team to challenge, explore and suggest ways to achieve the outcome in a truly collaborative environment.
31m 30s The aspirational goal is to be able to move away from having a job title of business analyst and identify a set of common good practices around analysis that any team member can use, and that are constantly in use to ensure that we stay focused on delivering the right product, right.
32m 05s The most engaged developers challenge the backlog items and are likely to come up with better ideas, engaging in the conversation around value, cost and the best approach to delivering on the need rather than just meeting requirements.
33m 44s Let people know that they have both the right and duty to challenge and question requirements – the point of agile is about individuals and interactions, we need to open up the conversation, set time aside and ask team members for their opinions in a safe environment.
34m 30s Set time aside on a regular basis to have the conversation that explores with the whole team if there are better ways of achieving the goals than those which are currently being explored.
35m 05s Development team members are professionals who care about doing good work, are intimately familiar with the workings of the product and have creative ideas about how to do things better – we need to create an environment where they can question, explore and suggest ideas and treat the backlog items as they were intended to be – placeholders for a conversation.
36m 00s Ensure there is a shared understanding about what value means in the context of the initiative.
36m 30s Accept that every team is different – the way you communicate with different teams will be different and linked to the maturity, practices and environment the team is operating in.
37m 10s Be a communications hub for the team – bringing people together and facilitating conversations rather than trying to define requirements in detail.
38m 55s Help ensure that the backlog is refined and items are clear when they come into the conversations, become a positive actor to facilitate the work of the whole team.
Companies and organisations mentioned
- Agile Alliance
- IIBA – International Institute for Business Analysis
- PMI – Project Management Institute
Resources
