Archive for the ‘Business’ Category

Idea

Getting an idea (problem) to customers (solution) is a complex cycle no matter what organisation you work in, but constantly monitoring and optimising the whole cycle will make it as smooth and efficient as possible improving the ROI for product iterations.

Irrelevant of the size of the problem that you’re looking to solve, it’s still important to firstly understand the value of the problem – why does it need to be discussed any further let alone hit the development teams for rough sizing? Unless you have data or a solid rationale to specify the size of the problem or opportunity, it simply shouldn’t go any further than the analysis stage. Not only is the value crucial for prioritisation, but it’s also important for the development team to know the benefit of working on the PBI (Product Backlog Item).

Once you’re confident the problem is worth solving, then it’s time to set the priority by weighing up the opportunity with all other PBIs and having a gut feel on size is totally acceptable at this stage to avoid draining the development team time with every single idea and talking about work, rather than progressing with solving high priority problems.

Before the feature touches a team for grooming it’s important for Product, Delivery and Technical to collaborate on how much resource gets assigned to solving the problem or phase eg. One team, two teams or all teams – depending on the option could impact in flight features and efficiency, so it’s important to collaborate over different delivery scenarios before rushing into a decision just because a deadline looms, as getting more teams onto a problem to solve could make the delivery go slower and impact efficiency unnecessarily.

Getting a PBI / Feature from idea to a ‘ready‘ state for development stage takes a significant amount of grooming which involves the Product Owner, Development Team and Technical Architect all of which is vital to ensure that when development starts that the right problem is going to get solved in the right way, rather than anyone wondering during development what problem they’re solving, what the value is or having to do loads of rework further down the line. This is one of most important parts of the delivery phases with the key elements being:

  • Solid ‘As a’, ‘I want’, ‘So that’ description which should give a crystal clear indication of who wants what and why
  • ‘Value’ of the problem
  • Acceptance Criteria of the requirement
  • Background / context which could be a link to Confluence which shows ‘As Is’ and ‘To Be’ flows / UX and can be used as part of a kick of for the feature to the development team
  • Any dependencies
  • Notes from the team working with the Technical Architect on any up front technical designs

When the PBI is in a ‘Ready’ state and prioritised high enough, then it goes into development whether that’s in a Sprint if it’s Scrum or on a Kanban board. The ‘in development’ phase gives you the most opportunity to improve efficiency / throughput and the Scrum Master is key to help the team achieve this (continuous improvements) whether it’s helping unblock impediments, coordinate with other development product lines or suggesting ways of getting PBIs over the line. There’s no harm also in hiring a Scrum Master for a team using Kanban, as ultimately the Scrum Master role is to help / support the team progress and the things which a Scrum Master would help out a team for Scrum would also apply to Kanban eg. Chasing down impediments, coordinating dependencies, removing blockers and working with the Product Owner on improving the quality of the Product Backlog.

Delivery

Once the ‘Definition of Done‘ (DoD) has been met including demo approved, it’s time to ship the product iteration to customers. Believe it or not, after all the work that happens prior to this, the release process is the part that could get stuck for weeks depending on the architecture and how the release process is monitored for Scrum (as often it’s outside of the DoD), but again this is where the Scrum Master can really step in to add value coordinating with release managers, but also suggesting release, environment and pipeline improvements to the development team and PO by reviewing delivery KPIs. For Kanban, tracking the release process is much easier as every process up to live gets incorporated on the Kanban board as there’s no set time boundary aka sprint.

Lastly it’s time to go back to step 1 (the analysis phase) and iterating based on how customers use the latest product iteration.

Like I said at the start, the Idea to Customer cycle is complex and involves a lot of people, but monitoring, testing out other agile frameworks and optimising the phases within the whole cycle will yield in a higher & quality throughput of features getting delivered to customers, so it’s important that the people responsible for Product, Delivery and Technical collaborate closely having this high up on their agenda and regularly communicate to the business the fantastic efficiency improvements which have happened recently and what’s up next to optimise.

CSPO

Whether you’re a product led organisation or keen to take product ownership to the next level, a good way to ensure that Product Owners are well equiped to effectively handle their product in an agile environment is through various Product Owner Certifications.

The first level of certification is becoming a Certified Scrum Product Owner, where the course is typically over a two day period with modules including:

  • Introductions to Agile and Scrum
  • Agile Basics
  • Scrum Basics
  • Roles and responsibilities
  • Team Chartering (Ready, ‘Done’ and Team agreements)
  • Product Visions
  • Product Roadmaps
  • User Stories
  • The Product Backlog and Product Backlog Refinement
  • Agile Estimating and Planning
  • Sprints
  • Participant-Driven Q&A

Acspo

Once you’ve become a Certified Scrum Product Owner and you want to take product ownership to the next level then attend the Advanced Certified Scrum Product Owner® course which includes:

  • Product Backlog Prioritisation & Refinement
  • User Stories
  • Rapid Vision Generation
  • Roadmapping That Works
  • Value Proposition Design
  • Hypothesis Testing
  • Use Cases
  • Getting to Done
  • In-person Collaboration
  • On-line Collaboration with Weave
  • Understanding Yourself as a Product Owner
  • Lift-off for Agile Teams
  • Scaling Scrum and other Agile processes
  • Extreme Programming
  • Facilitative Listening I & II
  • Inclusive Solutions

Csppo

The final step is becoming a Certified Scrum Professional Product Owner. Certified Scrum Professionals challenge their teams to improve the way Scrum and other Agile techniques are applied. They have demonstrated experience, documented training, and proven knowledge in the art of Scrum.

Are you ready for the next level of experience and expertise in the art of Scrum? If so, it’s time to elevate your career further by earning the CSP®credential.

Ownership

The product development lifecycle is complex, but in order for it to run like a well oiled machine there needs to be solid product ownership at the heart.

The below video explains Agile Product Ownership incredibly well and covers:

A typical Product Owner R&R would also be:

  • Market analysis
  • Competitor analysis
  • Customer analysis
  • Trends
  • Product line strategy
  • Product Vision
  • Product Roadmap
  • Backlog prioritisation
  • Epic / feature scoping
  • Epic breakdown to user stories
  • Requirement workshops and documenting them
  • User story definition
  • Detailed acceptance criteria
  • Backlog grooming
  • Sprint planning
  • Acceptance of user stories
  • Retrospectives
  • Daily stand-up

More info here on how to scale product when the time is right.

Learning

There are three major types of learning:

  1. Learning through association – Classical Conditioning
  2. Learning through consequences – Operant Conditioning
  3. Learning through observation – Modeling/Observational Learning

This article is focusing around No2 (learning through consequences) and the reason for focusing on this is because it’s so popular for fellow work colleagues across any business to recognise a problem / something not getting done and the consequences of not solving / doing it, that they just get stuck in and solve it themselves because they’re passionate about the business they work for instead of leaving it for the person whose responsibility it is to solve the problem / complete the task with risk that it’ll likely not get done.

Now, many people would say that’s brilliant team work and a fantastic ‘One Team’ attitude, but actually the action of solving someone else’s problem / completing a task for them is stopping the actual person whose responsibility it is to do it from learning. Also there’s the point about the person should be doing what they’re paid to do, but most importantly unless people experience the consequences of not doing elements of their job, then they’re simply not going to learn the importance of doing that element of the job and that they need to perhaps adjust their processes or admin to ensure they take control of their responsibilities in future.

Like I said at the start, if you’re passionate about delivering value for the business then it’s certainly not easy to avoid getting stuck in and it’s hard to avoid reminding people to do their job, but if you want to achieve the goal of the person who should be solving the problem or doing the task actually does it as expected in future, then the only way this will happen in the long run is by that person recognising the consequences of it not being done, so then they can avoid leaving it in future.

There will naturally be times when someone is clearly over worked and can do with a hand and that’s where you could come in to help, but if it’s someone close by spending most of their time surfing the net or playing ping pong in the games room, then you need to take a step back, try and ignore the problem not getting solved allowing them to deal with it however they feel is effective, but what is for certain is that problems / processes don’t normally get done on their own.

Scale

Once a product is mature and the product roadmap is filled up with valuable product iterations, it’s likely that the product owner and senior management will be keen to find out how some of the financial value driving product iterations can be delivered sooner.

Whilst having to balance technology improvements, technical debt, regulatory, security, bugs, dev ops and business requirements with only having one development team on the product stream would make this difficult, as there’s little room to work on multiple different types of work concurrently eg. business requirements concurrently with the more technical driven requirements.

To work on different sets of requirements concurrently, the product would need to scale which would involve adding additional product development teams to the product line. With more development teams working on the product would also require additional firepower from the technical architect and product owner role if delivery is to remain efficient and ROI positive.

An example of how you can scale the product owner role across multiple development teams who are working on the same product line:

Chief Product Owner (CPO)

  • Responsible for ensuring that the Product Owners are handling their product lines effectively
  • Handling the high level product strategy across all product lines

Product Owner (PO) / Senior Product Owner (SPO) of the Product Line

  • Market analysis
  • Competitor analysis
  • Customer analysis
  • Trends
  • Product line strategy
  • Product Vision
  • Product Roadmap
  • Backlog prioritisation
  • Epic / feature scoping
  • Backlog grooming
  • Sprint planning

Product Owner of the Development Teams (Associate Product Owner (APO))

  • Customer analysis
  • Epic breakdown
  • Requirement workshops
  • User story definition
  • Detailed acceptance criteria
  • Backlog grooming
  • Sprint planning
  • Acceptance of user stories
  • Retrospectives
  • Daily stand-up

The Associate Product Owner of the development teams could also be referred to as Feature Product Owner, Junior Product Owner or Product Executive.

In order for the Product Owner to be able to focus on the product vision, prioritisation of the product backlog and product strategy to ensure the product remains competitive, it’s important that when adding additional development teams to the product that they get additional product owner support to help them out with the more tactical day to day activities, as you can see from the split in tasks above – Product Line Owner handling more strategic tasks especially prioritisation in all instances and the Associate Product Owner handles more tactical tasks.

Spreading a product owner too thin with little support could result in a lack of focus on both product strategy and getting product backlog items delivered in an efficient way.

Greener

There will always be an endless list of all kinds of problems for a business to solve and it’s how people come together to solve the problems which accelerates the execution of viable solutions and positive changes.

Some problems will be easier to solve than others, there will be a multitude of lengthy conversations about how to solve certain problems and there will be various opinions on the value of the problem to solve, but it’s important to respect the person responsible (and accountable) for solving the particular problem and rather than moan about things not being solved / done how you’d expect, then use influence, positivity and collaboration instead to see how things could look from a different perspective, because ultimately everyone’s heading for the same goal and would be passionate to solve problems in the most effective way.

It’s also not easy to ignore a process which you seem to have various problems with especially when it’s not a priority to solve for the person who’s responsibility it is making you feel frustrated, but you could try rewiring your brain to obsess about problems which are within your remit to solve or contribute to solving instead and when asked by senior management “what improvements do you think we can make outside of your remit?” then you’re totally within your right to give an honest answer along with what you’ve tried to do to help.

Before you jump ship because you think the grass is greener, have you thought about:

  1. Collaborating on the solution with the person directly whose responsibility it is to solve the problem in a positive way – you never know, the person who’s responsibility it is to handle the process with the particular problem at hand could do with your observations or opinion on how to overcome the problems they’re facing
  2. Obsessing about solving problems which you’re responsible for and reviewing whether you’re fulfilling all of your R&R, as not solving your own problems could have a direct impact on other areas trying to solve their own problems
  3. Discussing openly with your line manager about how they think you could help contribute to solving the problem
  4. Is it a valuable problem to solve relative to other problems across the business
  5. Listing out all of the positive and good things about the company
  6. How lucky you actually are
  7. Making more conversations
  8. How much autonomy you already have to make big changes

When you get approached with an attractive offer by a recruiter or are fed up of certain problems not being solved, have a real think about how you’ve made an effort to help solve the problem by collaborating, because you may find the same problems if not more might exist on the other side of the fence, resulting in being in the same position in six months time with your new company.

Ops

All products will have an element of BAU (business as usual) and strategic work, where both are equally important to get after if the product is to remain competitive now and in years to come.

BAU work can also be referred to as ops (operational) work and I’ve always preferred the word ‘Ops’ over ‘BAU’ because no problem to solve should be looked at as solving it in the usual way which BAU can often be treated like. Also there’s often a stigma attached to BAU irrelevant of the business value it drives which is bonkers, so let’s look at the definitions of both:

  • BAU – work which doesn’t involve significant architecture redesign or thought, but BAU work is typically the blood line of the business
  • Strategic – work which involves a significant amount of up front technical design and often uses the latest / next generation technology. Strategic work often comes into play if there’s an architectural org restructure, the existing technical platform is no longer fit for purpose or it’s a new product

When it comes to delivering either BAU or Strategic work, there’s a couple of ways:

  1. Simply follow the same agile process which any other problem does, which includes adding a high level PBI (Product Backlog Item) detailing the problem to solve with value and then the Scrum Master / Team Lead looks well ahead in the product backlog to start contemplating approaching the ‘how’ with very close collaboration with the Technical Architect (TA) with the aim to get the item in a ‘Ready‘ state for development. This would in turn lead to the development teams planning in Technical Support backlog items to help the TA with technical designs, spikes or investigations well in advance of the problem appearing towards the top of the backlog which applies to both Scrum and Kanban.
  2. Split development resource into BAU only and Strategic only

The risk with No 1 is that the Scrum Master doesn’t collaborate with the Technical Architect soon enough resulting in the PBI hitting the top of the backlog before technical designs have started, causing significant delays to getting after the strategic work.

But there’s a much bigger risk to No 2 where there would naturally be a big reluctance for a team to work purely on BAU and therefore miss out on any green field project and there’s risk of breaking the ‘One Team’ mentality across the product development teams working on the whole product together and in turn impacting team morale.