Archive for the ‘Business’ Category

Strategy

VMOST = Vision, Missions, Objectives, Strategies and Tactics

Each product should have a clearly defined product vision, KPIs and strategies if it’s expected for the development team to deliver outcomes/head in the right direction and using the VMOST canvas is an effective way of showcasing what these are in a clear and concise format.

VMOST example

Vision: A passionate and exciting statement which typically should only be one sentence, where in a nutshell it should explain what your ambition is/what is your end goal of the product and who it’s for. More info on creating a compelling product vision can be found here.

Missions: In order to achieve the product vision, there would be multiple high-level missions you need to go on – what are the biggest problems which need solving before achieving the vision.

Objectives (KPIs): You can track progress of your missions through setting multiple objectives (aka KPIs), which would include metrics which are measurable.

Strategies: Initiatives which would deliver/impact the objectives (KPIs).

Tactics: Multiple ideas (Epics) which would deliver each strategy. The tactics should be laid out on the product roadmap, so there’s a nice link between the product VMOST and product roadmap.

Although the product owner is responsible for defining and owning the product VMOST, it’s important that it doesn’t happen in silo, as it takes collaboration with the rest of the business especially stakeholders/data/customers to help provide some guidance on the selection of problems to solve which would be represented on the VMOST.

Once the VMOST is ready, it’s time for the product owner to showcase this in a passionate way across the business and perhaps print it out on A0 to sit near the scrum team on the wall, so it can always be top of mind.

Good luck in creating your VMOST!!

Capacity

If a product is to be sustainable, tech fit, compliant and competitive it needs to have a short and long term development capacity strategy which will help to ultimately deliver the product vision.

Not having enough capacity could mean spending months / years only focusing on upgrading software versions / maintaining legacy technology or meeting regulatory requirements – not making any significant progress on getting after the product vision or surpassing competitors, having too much resource could mean that another product in the business could deliver a higher return with that resource instead, but having the right amout of capacity is important.

The product having the right amount of capacity should mean it’s possible to get after low hanging fruit, maintaining current tech whilst also concurrently getting after the next generation technology (product vision), meeting security / compliance requirements and having resource to experiment.

Understanding what the right amount of capacity should be isn’t easy, but a capacity planner will be able to help. A capacity planner should ideally be driven by points and velocity, so that no matter where the feature is on the feature pipeline (received a high level t-shirt size or has been broken down into stories) it’s possible to easily update the capacity planner with a more accurate estimate as the feature goes into development.

The data you’d typically need to lay out in a spreadsheet in order to effectively capacity plan includes:

  • Date (by month)
  • Team velocity – ‘Points to Allocate to Features’ (which already takes into account average sickness, holidays, ceremonies, breaks, training etc)
  • Forecast of future velocity based on an increase / decrease in capacity eg. Are you planning on adding another team to the product in 4 months time?
  • List of features
  • Estimates (in story points) against each feature
  • Priority order of features
  • ‘Points Remaining’ which is calculated as you start filling up the spreadsheet

It’s totally possible to roughly estimate future features by dev sprints, team sprints or man days instead of points as long as you convert it back to points after knowing how many points a whole team burns each sprint (velocity).

Another reason why it’s essential to have a capacity planner is that based on when features start and finish on the plan will drive the product roadmap dates making the roadmap data driven.

Having a capacity planner available is also a handy report when demonstrating to stakeholders that when features are in the correct priority order and once capacity has run out for a given month, then there’s no more room to slip in anymore work and it’s a case of being patient or changing priority / increasing capacity.

Basics

As a product scales there would often be an increase in capacity / scrum teams working on that product, enabling multiple features to be worked on concurrently, which would be a sensible time to review whether it’s time to adopt the LeSS (Large Scaled Scrum) framework.

As there are some additional elements involved in LeSS vs. Scrum including:

  • All of the Scrum teams work as one team, from one product backlog and with one Product Owner to deliver common goals
  • Having a joint sprint planning with members of each scrum team to decide on what product backlog items (PBIs) to commit to delivering in the next sprint
  • Overall Backlog Grooming (OBG) where members of each scrum team decide on what PBIs to assign to what teams, so they know what features to groom and get in a ready state for an upcoming sprint
  • Overall Retrospective where members of each team discuss highlights from their individual team retrospectives with the aim to learn and improve on how the whole team operates

It’s important to ensure that the Scrum teams have mastered the key elements of Scrum before considering using the LeSS framework, so before moving over to LeSS, see how you’re doing against the below questions:

  1. Are the teams using velocity to measure whether process changes they make are improving their productivity or hurting it?
  2. Are fast estimation sessions happening frequently so that the product backlog has rough estimates?
  3. Is it easy to predict when software will be delivered for the current and future projects based on the backlog being sized?
  4. Are sprint burndown charts monitored every day?
  5. Is analytics part of the definition of done?
  6. Is there a strong DevOps culture in all of the teams?

If the answer is ‘no’ to any of these then perhaps it’s a bit too early to adopt LeSS.

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.