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.

Heart beat

In order to get an idea (problem) to a customer (solution) there can be as many as 5-8 different levels / key roles to play from Developer to Product Owner and to get the idea delivered in an efficient and effective way, it’s important that everyone plays their part and gets stuck in.

One way of ensuring that you’re delivering real value by playing a part in the idea to customer flow is by providing regular heartbeat updates to your peers and stakeholders.

Dependent on the role you play, will depend on the type of heartbeat update you’d send out:

  • Developers – all that’s required from a developer (or QA) is to update the agile software tool eg. JIRA on a daily basis which will automate any type of report eg. Sprint burndowns, sprint delivery report for the Scrum Master and Product Owner
  • Scrum Master / Team Lead – fortnightly release update on in flight product iterations (epics), risks to delivery and mitigations to be sent to peers, Development Manager and Product Owner
  • Development Manager – monthly update on delivery efficiency improvements, development recruitment and strategy to deliver upcoming product iterations to be sent to peers, Product Owner, Technical Architect and head of development
  • Technical Architect – monthly update on technical architecture solutions for upcoming product iterations and quarterly presentation on architecture vision to Stakeholders, Development Teams, Product Owner and head of department
  • Product Owner – fortnightly sprint review and sprint goals report, bi-monthly update on what product iterations are up next with a product roadmap update and finally a quarterly presentation on what value has been delivered, what’s up next and an update on the product vision. The majority of updates to Stakeholders, Development Teams, Technical Architect, Directors, CTO and head of development

Once you’ve mastered the format of your updates, actually changing the content shouldn’t take long at all, so it’s easy to send out your heartbeat updates on time, but by not sending out any updates could easily give the indication that you’re a passenger on the idea to customer flow.

Communication

With more communication methods available at your disposal, it makes good communication easier now more than ever.

With face to face, email, chat message services, presentation formats, video conference calls and agile software among some of the key forms of communicating, there’s no excuse for either not communicating effectively or causing delays to delivering value to customers due to a lack of communication.

Let’s look at these communication methods in more detail and an effective way of using each:

  1. Face to face – preferred and ideal method at any given opportunity as you can often get the details you need in a single conversation avoiding email tennis and it’s a great way to collaborate easily. Also it builds positive intimate relationships which is incredibly important, so try as much as possible to escape from your desk / technology and pop over to speak to them face to face
  2. Email – great way of providing status updates to various people / distribution lists in one hit. Try to avoid email tennis though and relentless conversations especially if the person sits close by as it’ll help avoid spam to others! It’s essential to have a good email handle process to avoid missing important emails also
  3. Chat Messenger Services (Slack) – fantastic way of collaborating in an efficient way quickly. Have a quick question, want to share a document or link to a group of people or team, working remotely and want to join the conversation or simply chat quickly whilst you’re at your desk, then Slack is a great solution. When a new project kicks off, having a Slack group setup makes collaborating even easier. Also it’s developer friendly
  4. Presentations – lots of people don’t read all of their emails or have an organised email process to avoid missing emails, so gathering up a group of people to give a face to face presentation of information is a great way to get your message across in a neat and visual way. Also it gives an opportunity for some good questions to be asked and you can be more confident that the audience listens vs. sending the information out through a different communication method and it getting ignored
  5. Video conference calls (Skype for Business) – this makes collaborating with external companies, another division abroad or someone working from home easy, simple and effective
  6. Agile software (JIRA) – add everyone who’s interested in the relevant work item as a watcher allowing for development updates to be automated. Adding comments and tagging individuals in is an effective way of getting an answer or communicating also

It’s not just about communication, it’s about effective communication and there’s plenty of opportunity to use the right method at the right time to achieve this.

With facilitating processes and tasks at the heart of the Scrum Master role, it requires someone with a proactive, helpful, motivated, can do, kind, organised and supportive mindset in order for requirements to be solved in an efficient way in the right priority order.

With the Product Owner, Developers, QAs, Technical Architect and Stakeholders all focused on getting their job done where there are clear boundaries, it needs someone to fill any missing gaps or connect them together in order to get the job done, which is where the Scrum Master comes in.

Let’s look at a day in the life of a Scrum Master:

Scrum master

Done

Once the product backlog is in a good quality condition and the product backlog items (PBIs) start moving into development, there’s a significant amount of tasks to tick off before the feature can be marked as ‘done’.

Typically a development team would use a ‘definition of done’ (DoD) as a reference to ensure that none of the processes get missed off before it’s ‘done’, as each of those processes are essential and could have considerable consequences for the business and customers if it’s not done.

Some examples of what could be in a definition of done:

  • Code is reviewed by someone who didn’t do the PBI
  • Code is deployed to test environment
  • Feature is tested against acceptance criteria
  • Feature passes regression testing
  • Feature passes smoke test
  • Feature is documented
  • Feature approved by UX designer / stakeholder
  • Feature approved by Product Owner

Missing any of the DoD processes before a feature gets delivered to a customer could result in critical bugs across the feature, causing bugs across other features in the code, bring down the product or delivering the wrong requirement, so it’s essential to take the definition of done seriously even if it means taking the PBI over to the next sprint resulting in potentially not meeting a sprint goal.

Invest

In order to avoid lots of panic and chaos the day before sprint planning because there’s no work in a ‘ready‘ state, it’s essential to have regular backlog grooming sessions which would result in having at least six weeks’ worth of high priority ‘ready’ work in the product backlog.

To get PBI’s (Product Backlog Items) in a ready state, it can take a lot of effort especially when it comes to chasing down dependencies or getting answers around the business requirements, but this is where the Scrum Master comes in to help out – although the Product Owner owns the product backlog, it’s the responsibility of the Scrum Master to help, guide and support the team to ensure they’re having frequent effective backlog grooming sessions, so there’s a good few weeks worth of ready PBI’s.

A new PBI is the start of a conversation and shouldn’t include solutions, so there should be ongoing questions around the requirements well in advance of the work going into development, until the development team feel they have enough information to size the PBI and then mark it as ready if there’s no dependencies.

It’s important to have a good quality product backlog (high priority items in a ready state) and frequently groom PBIs, to ensure the development teams are not only working on the highest priority items, but also that they’re working in an efficient way.

Some tips to getting a good quality product backlog:

  1. Create the user stories and prioritise in the backlog sooner rather than later – as a minimum the story needs to include ‘as a’, ‘I want’, ‘so that’ language with some high level acceptance criteria which will help start the conversation with the developers, giving them weeks to ask questions up front before it appears towards the top of the backlog.
  2. Making the problem / requirements clear with a stakeholder point of contact within the story for reference
  3. Having a clear title (summary) to the story, so you don’t have to open it up to find out what it’s about
  4. When there are questions from the developers to answer either by the Sub Product Owner (or Product Owner), stakeholders or technical, try to avoid leaving these unanswered for days – these should be responded to immediately as a priority
  5. For the ‘Feature Backlog‘ to be presented to the team monthly or bi-monthly, so they know clearly what the value of the relevant PBI’s are with some context around them
  6. Having flexible backlog grooming sessions – there’s no rule here, the teams can get together everyday if they like to groom the backlog until they’ve caught up
  7. Reinforcing to the development teams that they don’t need to know exactly what code to write and where in order to size the PBI, but instead the sizing should be based on a suitable solution making some assumptions
  8. Attaching customer flows / UX to the PBIs, with a link to ‘As Is’ and ‘To Be’ documentation

At least 10% of the teams time should be spent on grooming the product backlog and unless enough time is invested or they don’t get the support they need from the Scrum Master or Product Owner, then there’s risk of inefficiencies or the teams working on low priority PBI’s (Product Backlog Items) as the high priority items aren’t being groomed enough in time for sprint planning.

To compliment the Product Roadmap, there should be a prioritised product ‘Feature Backlog’ which gives both stakeholders and the development teams a detailed overview of the Product Roadmap items still at that high level (Epics / Product Iterations).

If you use JIRA to manage your software delivery projects and you have your product roadmap items at an Epic level, then you’re able to simply setup a Kanban board with just one column called ‘Feature Backlog’ with a filter set to show only Epics and Epics which are ‘in progress’ or ‘to do’.

To visualise the feature backlog in a better way than the Kanban board, it’s possible to also show that same JIRA epic search filter across the likes of Confluence or Aha! where you can specify what JIRA fields to show.

Depending on your custom fields in JIRA, looking at the Feature Backlog should give stakeholders and development teams working on the product a high level (iteration / epic) idea of:

  • Priority order of all epics / iterations
  • Status – what’s in progress, planned or to do
  • Business value – whether it’s driving x incremental revenue, saving x money, avoiding x fees, meeting regulatory requirements, contract deadlines, tech debt, advancing technology etc
  • Description of the iteration / problem you’re solving
  • Delivery date which should match the dates on the product roadmap
  • Size of work

The Feature Backlog is a great way of showcasing at a high level the value of the product iterations which are currently being worked on and what’s planned in the next twelve months.

The Feature Backlog also helps the development teams understand the details of what problems are upcoming to solve, so they’re able to think about how to approach each epic / product iteration well in advance.