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’ and therefore ready to ship.

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 has analytics tracking
  • 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.

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.

The Product Group London

If you’re a Product Owner or Product Manager and would like to participate in a variety of interesting product focused discussions, then The Product Group London is for you.

It’s also an opportunity to meet, interact and network with those in a similar role who solve similar problems and have similar challenges.

At the monthly meetups there’s normally a topic of the night and a featured product which gets discussed. For example, the July 2018 agenda was:

  1. Topic of the Night: Developing the role of product management – how do you develop the role of product management in organisations that either (1) have no formal product function, (2) have a product function that is not realising its potential, or (3) have a well-established function and need to develop it to the next level?
  2. Featured Product: Clear Review – Stuart Hearn, Founder & CEO

You can also:

Celebrate

There are always endless amounts of tasks which need doing or processes to improve, but it’s important to frequently stop to say thanks and well done to the craftsman who have created the magic.

Because of the vast amounts of items on the agenda, unless quality time is spent communicating the high valuable work which has been delivered for the business and customers it’s easy for those pieces of work to get forgotten, but when looking back at those items which did get delivered it would always be something to be proud of and something to celebrate with your fellow colleagues.

A few good ways of saying thanks and showcasing the awesome high value work the development teams have delivered:

  • Product iteration alerts – as soon as an item has been delivered, not only is it essential to let stakeholders know what has just gone live to customers, but it’s equally important to shout out the teams who have been involved in the delivery to say thanks and well done. Using some quotes from key stakeholders is a nice touch also
  • Quarterly delivery reviews – looking forward at the exciting future planned product iterations and new product launches happens frequently, but equally it’s important to take some time to look back at all of the awesome iterations the development teams have delivered over the previous few months
  • Team lunches / nights out – escaping from the office to hit a nice restaurant or bar at the end of a milestone or project delivery
  • Adhoc thanks and well done – after an important launch happens, informally gather up the troops to say thanks and well done for their remarkable achievement re-emphasising what it means for the business and customers

There’s plenty of other ways to recognise and celebrate success, but just making a small amount of effort frequently to recognise the hard work and positive impact the development teams are making will inject pride and drive into the development teams.

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.

CompetitorAnalysis

Whilst it’s important to keep an eye on what your competitors are up to, it certainly shouldn’t be in the bucket of tasks to obsess about and instead competitor analysis should be part and parcel of problem solving.

Whether research suggests a specific type of financial product should be launched, a specific mobile payment method is needed, refer a friend rebrand, registration flow optimised or customer support improvements, part of the discovery phase when looking at solutions should be analysing how other companies have solved the problem (including competitors), which would give a wide range of interesting ideas to consider.

It’s equally important to not simply copy what competitors do, but instead have a vision and ambition to deliver a next generation solution leapfrogging the competition.

An important time to analyse other companies approach to a solution especially competitors is their approach to new regulatory requirements, especially as some of the guidelines are so ambiguous and taking a risk approach to some regulatory requirements comes with potential consequences, but equally come with an avoidance of revenue loss and it’s important to remember that implementing regulatory requirements isn’t cheap not to mention the opportunity cost. An example is that if the likes of Vodafone, British Gas, PokerStars, Llyods or Apple have deployed a relatively high risk approach to certain regulations, then it’s safe to say that using their solutions as a guide would be sensible. If the regulation is industry specific then using the market leader could be a good base also.

If you’re one to obsess about competitors or tend to replicate what they do, the next time you have a big change to make or problem to solve, try ignoring that any competitors exist, ignore all current technical limitations giving the development teams a blank canvas to focus on solving the real clear problem at hand and you might be blown away at the creative thinking that the development teams and UX come up with, utilising the wide variety of new technology available which surpasses anything your competitors have got live or on their product roadmap.

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
    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. Realising value sooner – 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 (Dev Ops culture – continuous delivery)
    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
    7. Self organising, cross functional teams including UX and design

    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 over time 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.

    Problem solving image

    There will never be a lack of problems to solve when it comes to product development, but handling the relentless amount of ideas and identifying the right ones to focus on can be tricky if a robust process to prioritise and track all of these is not in place.

    There are many approaches you can take to handle problems and prioritisation, some product management videos I’ve seen describe the product owner to spend most of their time saying ‘NO’ to stakeholders which I tend to disagree with, because technically all problems can be solved and an idea is never a bad idea, but perhaps it just can’t be solved right now due to higher priority work, so a response to show appreciation for raising the idea / problem and that it’ll go through the prioritisation process is a more appropriate response. Some also handle prioritisation and requests by who shouts and flaps the loudest which is equally not the way to go about effective backlog prioritisation.

    Two things you need in order to prioritise effectively 1. Value and 2. Effort to work out the projected ROI. Before you even spend effort discussing how much effort a problem will take to solve, the first thing which should be asked when someone approaches you with a problem, idea or bug is “what is the value?”. As a result of this, you may get:

    • A sheepish response where they don’t know, so they’ll have to go and find out (in some cases resulting in the problem being so small it’s not worth solving it, so you don’t get to hear about the problem anymore)
    • Value provided is minimal (relative to everything else in the backlog)
    • A fluffy response eg. It’ll increase traffic, it’ll increase retention rates etc, with no given metric
    • A significant problem / idea to solve which could deliver vast amounts of incremental revenue, benefits to customers or savings through efficiencies which should be fast tracked through the effort sizing and prioritisation process

    Another question which can be asked to identify value is “what happens if we don’t do it for 3 months, 6 months or never” which will aid prioritisation further.

    At your disposal you should have a data visualisation tool to easily view trend data and access KPIs for your products and features which is another way of identifying value for yourself, but ensuring that you and your Scrum teams are working to solve the highest value problems is fundamental in achieving a healthy ROI and successful product, so by asking just some simple questions up front will make your journey a lot more palatable.

    Positive and collaboration image

    Product Management (Product Owners / Product Managers) typically have a very broad range of responsibilities as they’re quite often seen to be the avenue to ensure not only that ‘things get done’ when it comes to product delivery, but also that the right things get done.

    The size of the business and location of departments can determine what you do day to day, for example a small company a product manager might see themselves fulfilling the role of a marketer, data analyst or developer team lead on top of their product management role, but in a larger organisation who typically handle all operations in-house might see themselves promoting the vision, providing context, prioritisation and collaborating with the different departments to get things done. Lastly you could be in the unfortunate position where you have the developers in one country, the marketers in another and further more the product management team in another country which makes collaboration all the more challenging.

    Product specialists are expected to be well rounded across a multitude of disciplines including KPIs / handling data, prioritisation (effort vs. value), customer service, UX, technical, marketing, Agile and of course product life cycle, but being a specialist in all these areas is unrealistic, so it’s fundamental to closely collaborate with all areas of the business in order to get to the right solution to customers within an acceptable time frame.

    Unlike a dictatorship, collaborating on what problems to solve is critical generating a positive atmosphere, so discussing the problem you’re hoping to solve and solutions openly and honestly with stakeholders and relevant business areas, enables you all to come to a decision together with the customer being at the heart of conversations which will result in delivering a far superior product / end result.

    This actually applies to the majority of roles, but collaboration alone is not enough and it’s equally important to be positive with a ‘can do’ attitude which will likely be absorbed across the ranks, resulting in your fellow colleagues who you rely on so much will rally behind you to fast track solutions to your customers.

    Letting the barriers down, lots of collaboration, positivity, understanding there’s no I in team, believing that you can’t do everything on your own and appreciating the support at your disposal will naturally put you on the right road to success.

    Beauty vs functionality image

    No matter the industry whether it’s automotive, finance, retail, gaming or gambling there’s always going to be a desire to have both a beautifully looking and fully functional site, but the development teams are not normally split out in this way so requirements to improve the look of the site competes with getting new features out the door / feature improvements and UX bugs.

    There isn’t a set rule for weighting the development work as industries would differ for example for Audi the split would likely be c 70% beauty vs. 30% functionality because it’s key to show off the cars beauty representing it in it’s true light, rather than having pixely images which take a while to load or customers not being able to access a 360 degree view of the car. Yet for someone like Amazon, the focus would be on functionality, ensuring that customers can pay with a multitude of payment methods, the UX is slick and bug free as well as having an advanced product search and results function.

    Post MVP launch the product might not be gold plated but ensuring customers have an acceptable UX, feature set in line with the industry and rich content is priority and typically all that customers want and mostly care about.

    Is it worth pulling developers off a key feature / upgrade / stopping a product launch to develop fixes to ensure all buttons have a consistent curved edge, images on a low device usage are high quality, all images are the same size to the pixel or to make numbers flash and sparkle. Customers visit websites because they want something, so why not give it to them as a priority without delay or frustration, otherwise prioritising gold plated design over key functionality could lead to customers going elsewhere for the products / features or experience they want.

    Scrum

    Development teams should decide what agile development framework they adopt/try out using retrospectives to aid improvements and change.

    The way teams operate is significantly different between Scrum and Kanban, but the fundamentals of business delivery stay the same eg. Prioritisation, frequency of 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.

    So many awesome ideas from so many people to improve product, but it’ll always be impossible to fulfil all desires in an acceptable time frame to stakeholders, making prioritisation not only challenging but extremely important.

    Process, data, collaboration and determination can certainly make prioritisation all the more effective and smoother, so looking at these areas in more detail:

    Process: Status of projects, where do product requests / bugs sit in the pecking order, ETA on delivery, investment cost and projected value of projects held in a transparent way will help with the communication overhead and help maintain trust.

    Data: To ensure that high value items are being worked on you need data to backup assumptions. It can be easy to flap and try to make a problem out to be bigger than it is to get it done, but there should always be some kind of data to back it up with examples being: incremental revenue which can be reverse engineered from retention uplift rates or projected acquisition volume increases using ARPU for example. Other ways of projecting value / determining scale of the problem is customer support queries or customer feedback, site loading times, efficiency in terms of £££ saving eg. Man hours / days or software costs etc.

    Collaboration: Discussing value and priority options openly with your colleagues will help you deliver a product in a more confident and focused way, as it’s not easy making the big decisions on prioritisation because what’s at the top or moves to the top means that the items below won’t be done now or perhaps anytime soon, so checking and agreeing on the focus / roadmap helps to give confidence to just get on with delivering a high quality & value product without having to worry about justifying a decision you’ve made alone every minute of the day.

    Determination: Prioritisation changes frequently if you work in an agile environment, so being positive and determined to deliver upcoming projects you’ve been discussing for months or even years helps to keep focus on delivering the key business goals and provides reminders that it’s still on the agenda, no matter the level of incoming bombshells / distractions.

    If someone asks for something to be done urgently without providing any numbers representing the projected value or any element to give an idea of the scale of the problem you’re looking to solve, then asking why do it or what happens if we don’t do it in the next 12 months should help to quickly prompt the need to research more into the value.

    Projecting investment cost and taking time to dig into the real value the product change will make in a collaborative way, will ensure that you’re delivering frequent value to customers internally and externally in a happy, fun and relaxed environment.

    Team-image

    There’s no doubt that it’s desirable for a team to be happy for many obvious reasons including productivity, but a few do’s and don’ts to retain a jolly happy team ☺:
    Do

    • Be polite irrelevant of who you’re talking to – thank you, I appreciate that, thanks
    • Offer help if you see a colleague struggling
    • We have done that – embrace the team
    • Congratulate your colleagues on achievements
    • Share any positive performance off the back of effort
    • Own up / apologise for contributing to buggering anything up accidently
    • Be positive day to day
    • Be honest sooner rather than later so people have time to improve
    • Chill and take time out to talk non-shop to your colleagues
    • Discuss / focus on what problems you’re looking to solve
    • Ask why it’s valuable
    • Allow autonomy

    Don’t

    • Blame a work colleague directly but instead discuss whos responsibility it is and how we can avoid it in future
    • Dictate solutions to colleagues. discuss the problem and how you need help solving it instead. Troops will stand by and support you whatever the need
    • There’s absolutely no need or nothing to gain from being rude or a bully, other than your work colleagues keeping their distance from you. You can always get what you want from being polite and direct.
    • Focus on problems with agreed solutions (negativity)
    • There’s no I in team
    • Contradict yourself regularly to avoid confusion and frustration

    This may all be obvious, but get it wrong and there could be an expensive mass exodus which will impact productivity, but adopting at least a few of these will result in Spartans banging their swords against their shields ready to defend the realm with you.

    Context switching

    There’s never just one thing you could do, not just a few things, but there could be hundreds of things you could possibly do to deliver value, so by being reactional with a ‘just get it done’ attitude could result in little progress towards delivering overall business goals and lead to a few frustrated developers.

    Product development isn’t as quick as setting up a new programmatic ad campaign for example and instead can take weeks to carefully craft a solution collaborating with colleagues along the way. Also with development costs not being cheap means that not making a sensible decision up front could be costly.

    Context switching can impact a variety of key elements:

    • Waste – it can take hours / days for a developer to jump from one project to the next especially if they’re unrelated and the code is complex. There’s also risk that some of the learnings from the original task would be lost even if documented.
    • Morale – one of the most frustrating things for a developer is context switching either by switching in progress work or frequent disruptions. Developers take pride in doing a high quality job and to do that takes detailed technical planning to ensure they do the job well, so pulling the rug beneath them often ends in frustration. Typically they just want to get a job they’ve started on done and see the fruits of it.
    • Delivering value frequently – adapting to change quickly is important, but you may find changing a strategy often results in delivering very little.
    • Prioritisation – expecting a product owner or someone in a strategic position to juggle a significant amount of projects at once will end in the highest priority work not necessarily getting done, because it takes time to groom and value projects / requests, so if there’s less time to do this, work could be prioritised based on who shouts the loudest.

    Context switching can negatively impact anyone across the majority of an organisation and is often caused by unnecessary flapping / panicking, but with a robust and strict new request process and well oiled live bug process can not only keep context switching to a minimum, but also ensure that teams are working on the highest priority item delivering value frequently to customers.