Posts Tagged ‘Efficiency’

Devops

Development effort isn’t cheap, but extremely valuable no matter what industry you work in, so once a product iteration is ready to ship, automating the final steps including the software build, deployment, environment and release process will help continuously deliver customer value in an efficient way without unnecessary delays or bottlenecks.

DevOps is the combination of cultural philosophies, practices, and tools that increases an organisation’s ability to deliver applications and services at high velocity: evolving and improving products at a faster pace than organizations using traditional software development and infrastructure management processes. This speed enables organisations to better serve their customers and compete more effectively in the market.” – AWS

There’s often a significant amount of thought and effort which goes into getting an idea into development, so when the code (solution) is ready to kick off the build (ship) process, it’s important that this is as automated as possible to avoid unnecessary delays with customers getting hold of the feature within a timely fashion.

Due to the rise of the DevOps culture, it’s now possible to automate the whole build, deployment and release process. As well as customers getting features sooner as mentioned above, other benefits of adopting a DevOps culture includes:

  • Software Development division remaining competitive
  • Reduction in waste from having to wait for software to build, deploy, dealing with environment issues and working with the operation team to handle the release
  • Increasing the R in ROI (Return on Investment) as less waste results in delivering more value to customers
  • Improving team morale – dealing with environmental, build and release issues manually isn’t fun
  • Improving on sprint goal complete rates as it’s less likely stories will drag over to multiple sprints because of build / release issues
  • Decreasing lapsed time of development work
  • Improved security
  • Easier to track build to release timeframe
  • Automated
  • Scalable

Adopting a DevOps culture should ideally come from bottom up rather than top down – a Product Owner shouldn’t need to create stories, sell in the importance of it to dev teams or prioritise it, as optimising the software build and release process should be BAU (Business as Usual) and should always be constantly looked at and improved.

As development teams adopt a DevOps culture and they start migrating over to a fully automated process, the benefits will be obvious and lucrative.

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.