Posts Tagged ‘Agile’

Once you’ve created a solid Product Vision, it’s likely you’ll be asked to provide more granular details on the ‘what’ and ‘when’ and the Product Roadmap is a great way of helping you answer that.

The product roadmap is also a good way of giving the development teams an idea of the exciting upcoming features / problems to solve for the product.

Key points of a Product Roadmap:

  • It should be at a high level eg. Epic, feature or iteration level – Epic level is a preference as then it maps nicely to the product backlog items (PBI)
  • It needs to include dates spanning the next twelve months whether monthly or quarterly
  • The bars on the chart show when items start and when the development will be complete (live hidden)
  • One of the most important things is to educate development teams and stakeholders that the drop dates are an intent (not commitment) of focus / delivery and that things can and will likely change, so it’s advisable to avoid spending significant amounts of time making each item exact, as the desire from the business would be to have a rough idea of the twelve month view rather than knowing whether something starting in six months time will be delivered exactly a month later than that for example
  • The roadmap needs to be easily accessible by anyone in the business where they can use their network login and can also access it from outside the office eg. on the train – if it’s hard to access, people just won’t view it and assume there’s no plan
  • It needs to be updated frequently – if it’s regularly out of date, again people just won’t access it

Product Roadmap examples

Roadmap sample 1

Roadmap sample 2

The most important thing about the Product Roadmap is to always provide a sign of intent for when product items will be delivered over the next twelve months, with the key word being ‘intent’ here ie. Not exact drop dead delivery date and a couple of people with experience of productivity could use gut feel which is totally acceptable, rather than dragging developers away for days on end to roughly size big pieces of work which will either 1. Change anyway and 2. Be extremely inaccurate as unknowns result in estimates going through the roof.

A sign of intent for the next twelve months for the product is also better than a half empty roadmap!

Vision

It’s worth spending time coming up with a compelling vision statement, because it’s something which will be repeated over and over again as it’s the key driver to drum up excitement, passion, investment, confidence and trust that the product end goal is rather spectacular, solving the big problems and then in turn delivering huge value for the business and customers.

First things first, craft your vision statement which should only be one clear sentence, where in a nutshell it should explain what you’re looking to deliver, to who and why giving off a wow factor:

Vision statement

Then create a product vision board specifying who the target market is for your product, problems the product solves, clarifying what the product is and how the product is going to benefit the business and customers:

Vision board

Lastly, having a vision diagram is a great way of providing stakeholders and the business with a snapshot using one image of where you’re at with the product and where you’re heading. Having colour coding for ‘live’, ‘in progress’, ‘planned’ and ‘to do’ would cover it – there are plenty of mind map tools to help you visualise your product, one of which is Lucidchart which comes as a plugin for Confluence also. It’s important to keep the product diagram focused on high level features rather than detailed technical solutions around systems as that would be more of a technical architectural diagram:

Vision diagram

Having a solid product vision isn’t just to help the business allocate resource, but it’s also essential for the developers to know exactly where they need to head and ‘why’.

ScrumCards

A self-organised development team working together successfully to achieve common goals within the sprint boundary (typically every two weeks) is only possible if the teams ceremonies are done which includes:

  1. Daily stand-up – the scrum team need to meetup daily on time to discuss what they did yesterday, what they’re planning to do today, highlight any dependencies, issues or help they might need
  2. Updating the scrum board daily – whether the source of truth is the physical board or a digital version eg. JIRA, the scrum board needs to reflect the current state of play with regards to the sprint progress, so the team can understand how they’re progressing with their sprint commitments and sprint goals
  3. Regular backlog grooming sessions – in order for the development team to be able to work on the highest priority PBIs (Product Backlog Items) in the next sprint, they need to ensure they meet up regularly in order to get at least the next three sprints highest priority backlog items in a ‘ready‘ state
  4. Roughly sizing the backlog – in order to predict when customers will receive tweaks to the product, it’s important that the product backlog is roughly sized to aid delivery ETAs, but also prioritisation
  5. Retrospectives – meeting up once a sprint to discuss what could have gone better in the last sprint, what went well and what to continue doing. The format is flexible and the most important thing to do at the start of any retrospective is to focus on actions front the last retrospective – unless actions are done (the team learns), retrospectives are pointless, so it’s absolutely crucial that the things which the teams are keen to change / improve on is actioned or tried at least.
  6. Sprint review – showcasing what awesome iterations the team has been working on to get feedback and a round of applause from stakeholders

In order for the scrum team to be able to fulfill their commitments they should be getting significant help, guidance and support from the Scrum Master or Team Lead, Product Owner and the Development Manager and only once the above points (basics) are being done well, can a team start to seriously look to improve their velocity and scale successfully.

Kpi

In order to prioritise effectively you need both the projected value and effort, but these aren’t always easy to come by. Projecting value can be particularly challenging if the data isn’t easily accessible which can have a knock on effect when analysing your KPIs (Key Performance Indicators).

Ensuring that a product / feature have KPIs is beneficial for a few reasons including: Aiding prioritisation, celebrating success, feeding back on software development iterations and to feed into the general product vision and wider business goals.

Your KPIs don’t have to be a financial value (although a good attempt at projecting a monetary value should be made to aid ROI projections) or just one KPI, but they just need to be measurable, an indication of success and for them to be linked in someway to the overall business goals, so how can you identify what your KPIs are:

  • Incremental revenue – benchmarking on existing revenue volumes for the relevant feature in question. What do you anticipate increasing the revenue / ARPU by
  • How many customer queries are you hoping to reduce and how much does it cost per contact
  • Is it solving a common problem / request that high value players have been submitting
  • Will solving the problem increase website stability, reducing downtime for customers
  • Are you expecting to increase customer acquisition numbers / conversion rate
  • Will it increase retention rates – a measure of this is churn rate / drop off as well as LTV
  • Efficiency savings – by completing a piece of work could it increase team output / Velocity whether it be development or a marketing team
  • Feature traffic / usage – if conversions or direct revenue from the feature isn’t relevant then at a minimum having sessions, dwell time and value of customers using the feature can be used as a KPI

    Identifying your KPIs is one thing, but having the data available at your disposal on a self-service basis to cut, analyse and share is naturally fundamental, but once you have identified your KPIs and have access to the data, you can be confident that you’re well equipped to contribute to the Agile piece, but also your helping meet the wider business goals.

    Agile

    There are two main definitions of ‘Agile’ which people tend to refer to when 1. Delivering software iteratively and in increments rather than holding all of the software back delivering one big release somewhere down the line and 2. The business responds to change / demands rather than sticking to a long term strategy just because it was previously agreed.

    Both definitions of the term are valid, but in software development the first use is most common whereas everyone else in a business typically refer to the second.

    Scrum is the most common Agile framework where typically the expectation is that you release code / software to live every fortnight / within the Sprint whether it uses a feature switch or setting the code live to customers. This has many benefits such as:

    1. Guaranteed value being delivered within the sprint off the back of the development work the team committed to during sprint planning
    2. Predictability of future software releases
    3. General team organisation – all work in the sprint will be fully done so you won’t have to deal with the previous sprints pre-production testing or release in the following fresh sprint, making it less messy and reducing the impact of context switching
    4. Responding to customer feedback quicker adjusting scope for future iterations off the back of it
    5. Large chunks of development work won’t be sitting on the shelf collecting dust or thrown away without any customer / end user receiving any of the goods
    6. Ability to deliver the highest ROI pieces of work, so rather than having to wait until a feature is gold plated, you may find after the 3rd iteration that the majority of value has been delivered, therefore it might be higher priority to start work on another feature than fully completing the existing one

    Only once you’ve ticked off all of the above can you say that you develop software in an Agile way.

    The business use of the term Agile is more focused on the ability to adapt to change quickly and shuffle around priorities to meet changing core objectives within a reasonable time frame, rather than continuing to work on something which will generate half the ROI than another feature or a feature which is no longer needed. Naturally you need to include any context switching cost when changing in flight priorities and it’s recommended not to change high level priorities frequently because you may find yourself delivering very little overtime and instead just causing lots of admin and frustrated developers.

    Being Agile is certainly not easy to achieve, but having the ambition and desire to start delivering value in an Agile way is something which is definitely worth any necessary process or infrastructure change in order for the benefits of Agile to be unlocked.

    Scrum vs kanban logo

    Development teams should decide what agile development framework they adopt / try out using retrospectives to aid improvements and change. The way teams operate are significantly different between Scrum and Kanban but the fundamentals of business delivery stays the same eg. Prioritisation, frequently delivering value to customers, agile software delivery and development team structure / support. So what are the differences:
    Scrum

    • Scrum is one of the most popular ways to implement Agile. It is an iterative software model that follows a set of roles, responsibilities, and meetings that never change. Sprints, usually lasting one to two weeks, allow the team to deliver software on a regular basis.
    • Teams commit to delivering two weeks worth of work, but if the original plan changes by even adding work, removing work or changing work / stories within a sprint would mean the team fails in achieving the original sprint commitments / goal
    • If teams deliver what they commit to then they celebrate passing the sprint (which was the sprint goal) ie. a teams goal is to deliver on their sprint commitments, not to get the actual development / value live to customers
    • Set Scrum ceremonies such as daily stand ups, fortnightly sprint planning, fortnightly backlog grooming and a retrospective
    • Sizing user stories which can be a different size
    • Sprint burndown charts to measure progress
    • You have a team velocity to help set realistic future sprint goals and project feature ETAs
    • Normally there can be no dependencies when committing to work in a sprint so even more upfront planning / scheduling / grooming is needed

      Kanban

      • Kanban, meaning “visual sign” or “card” in Japanese, is a visual framework to implement Agile. It promotes small, continuous changes to your current system. Its principles include: visualise the workflow, limit work in progress, manage and enhance the flow, make policies explicit, and continuously improve.
      • The goal is to move user stories / bugs through different stages of the development cycle with the goal to get the story from one side of the board to ‘live’ / ‘done’ ASAP
      • The stories high up in the backlog / coming next should be broken down so that each piece of work is roughly equally sized allowing you to gauge an average story cycle time and deliver value frequently
      • The team are typically not bound by time limits to getting work done and instead restrict WIP by dev status to ensure value gets delivered frequently to customers
      • Grooming, stand ups, planning and retrospectives are not mandatory but regular grooming, stand ups and retrospectives are recommended to ensure efficiency is at a good level
      • As there’s typically no fixed deadline on work getting done, teams can spend longer on thorough investigations into multiple solutions if needed. Also on the other end having a column on the Kanban board for demos, pre-production work and a column representing live is also possible allowing stories to be closed only when value starts getting delivered to customers
      • Because of the above, it makes the status of development work crystal clear rather than a sprint ending and you having to dig around to find out where it is and spend more effort / create additional release stories trying to get it live
      • The team lead and dev manager role is even more important to ensure the team are trained up, working efficiently and resourced to get the job done
      • As teams pick work from the top of the backlog adhoc, it’s likely a new highest priority item will be picked up sooner than if it was at the top of a Scrum board as you don’t have to wait two weeks until the sprint finishes before it’s in development

        Both Scrum and Kanban have plenty of pros, cons and bring different challenges to the table, but give software engineers the autonomy to get through the backlog without sprint boundaries or artificial deadlines then you’ll likely see productivity, quality and communication increase, with the caveat that they must have strong support from the team lead, dev manager and PO who aren’t affraid to get stuck in.