Posts Tagged ‘Product Development’

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.

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.

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.

      satisfied_customers

      No matter how much marketing you deliver, whether it’s billions of banners on the most premium sites in the world or you’re top of key generics consistently for Google, unless you have a stable product offering which customers genuinely embrace, then your brand has a fairly bleak future.

      Historically you could spend your way out of a crisis, but now if your site crashes often, you hide key T&Cs, mis-sell promotions, have a complex user journey, product not available on multiple devices, then in a few years time your brand value will show a clear decline which would eventually kill your business unless you adapt fast.

      I think the below video demonstrates the future in a fantastic way and how consumers will shape products, businesses and communication. The good thing about the future is that it will kill a lot of cow boys who are short sited and have no long term business strategy.