Programming in the pandemic - Plutora: Don't dream it, value stream it
With only a proportion of developers classified as key workers (where their responsibilities perhaps included the operations-side of keeping mission-critical and life-critical systems up and online), the majority of programmers will have been forced to work remotely, often in solitude.
So how have the fallout effects of this played out?
The post is written by Jeff Keyes, VP of product at Plutora — the company is known for its technology which works to capture, visualise and analyse critical indicators of speed and quality of software delivery
Keyes writes as follows…
With almost every business today driving to produce ever more software as part of their customer offering, the challenges that have hit software delivery during the past 12 months have threatened to put many businesses on hold. Among the challenges is how to cope when we’ve gone beyond decentralised teams, to decentralised teammates. Maintaining high quality, efficient software delivery that keeps customers happy and delivers value to the business has been dealt a real blow with a suddenly mandated remote workforce.
Communication chaos
For developers, remote working has created a vast number of silos. You have separate teams that do the deployment, the environment testing, the acceptance testing and many more. They all rely on different tools which even prior to the pandemic made communication between them challenging – now with all of these teams working remotely, this has only got harder.
Visibility while working remotely is extremely important, especially if your development culture, like most, has traditionally been face-to-face. Platforms such as Zoom, Microsoft Teams and Slack have been a lifesaver for many businesses, but in software development, many teams have found that these platforms aren’t quite the answer.
Keyes: Don’t dream it, value stream it.
Value stream management has been one solution to this, helping to bring employees across all teams and levels together in one platform with full visibility. By considering all of the activities that deliver a product or service when approaching software development, it allows teams to manage their work from idea to delivery and full collaboration regardless of how many different tools need to be integrated throughout the toolchain into the single platform.
Foundations of success (or failure)
During the past year, we’ve seen application development boosted in some organisations and fall by the wayside in others. Here are some key themes that have affected who succeeded and who struggled.
The successes:
- Teams with mixed on-premises and offshore teams that already had methods of communication and work tracking that didn’t require in-person communication. They’ll have seen an increase of work-hours as travel was eliminated and likely, work overran outside official work hours.
- Teams that relied on communication as a natural part of their work (for example, completing a ticket, changing status, or logging issues) rather than requiring meetings and emails to notify colleagues.
The struggles:
- Environments that utilised a work management type board – think Kanban-style tracking for standups – as they’ve been forced to instantly change their tracking tooling.
- Reduced executive visibility, where the management style of ‘manage by walking’ is completely eliminated, leaving them in the dark.
- Systems and environments that required in-person management – teams hadn’t counted on managing these remotely.
DevOps of the future
The pandemic has driven most organisations to make many changes that will likely continue to be required in the ‘new normal’, including the software application development methodologies that are used.
Building DevOps-oriented product teams breaks inter-team dependencies (physical and process) to reduce the need to communicate across multiple teams, while DevOps automation eliminates hand-offs, therefore requiring less interaction.
However, to maintain visibility, reliance on tooling for progress is critical. Scrum often is an interim step toward autonomous, completely transformed Agile and DevOps practices. A Kanban-style work mixed with DevOps practices can be highly beneficial, as it evolves traditional scrum and prescribes release processes all be built into the pipeline where they are run continuously.
The more we progress toward true DevOps and Agile transformation, the more suited to remote work we are.
To many, frameworks such as ‘Scaled Agile’ and ‘Disciplined Agile’ are seen as the target rather than a basecamp to DevOps practices. While important on the journey of transformation, modern practices can’t lose sight of the need for continuous improvement, decentralisation, smaller teams, and smaller more frequent releases.