If DevOps aims to create a culture where build, test and release can happen frequently and reliably, then most large IT organisations are not equipped for this kind of culture. Project management is also a topic that is ripe for major change due to the fact that IT is shifting towards products: after all, customers buy IT products and not projects.
In many large firms there are separately managed development, support and release teams with no incentives to work collaboratively or with a sense of shared values and outcomes. There can even be extreme cases where support/operational teams engage in a turf war with development teams to undertake minor enhancements and bug fixes and thus risk destabilising a codebase due to being outside of the wider knowledge-base where the code is built and maintained.
The same can apply to managing vendor systems too. I’ve also seen release teams that operate totally independently from development teams to manage a large suite of application releases with the upshot of not knowing enough about the systems to troubleshoot problematic releases or know which components to shut down and in what order as part of a release process. The problems created from these organisational silos mean relegating releases to weekends only so as to minimise weekday disruption.
When was the last time Google, Facebook or Amazon took their services down to perform an upgrade or release? These are the kinds of outcomes that DevOps aspires to. When the bar is raised to the level of end-users not knowing when a release is happening, except to see some new feature on a later login, then the rest of the software engineering community needs to sit up and listen. This also bears testament to the agile principle of self-organising teams who take complete ownership of delivering a feature from conception to release.
I would go as far as to suggest that the likes of release teams be abolished and that function sits within the development team. If they can’t be trusted to have access to production systems, or at least to have a level of access that enables them to start and stop process and execute release scripts, then why would you trust them to build the software in the first place?
Likewise, QA teams are going towards irrelevance when a self-organising team includes the unit and functional/behavioural tests needed to satisfy the functional and non-functional requirements. Graphical user interface (GUI) testing can also be fully automated. A traditional culture of developers handing over to QA testing creates intellectual laziness that results in sloppy work.
Well-crafted user stories with agreed acceptance criteria that the stakeholder has helped shape means that a self-organising team can get on with the job end-to-end. Operating in this manner means that at the end of a sprint a relatively small amount of change (but a change that is valuable) can be released. This greatly lowers risk. I know of teams who release quarterly or less. That is a huge risk to stability.
Even in the most regulated environment there needs to be a culture that facilitates frequent, incremental releases. It also enables firms to be competitive by getting to market fast and allowing stakeholders to shape the priorities. Naturally you need support teams to take phone calls, be at end-user desks where applicable and respond to alerts and triggers from monitoring tools. DevOps seeks to address the dichotomy caused by support teams being hived off into generalist teams that are separate from and almost ignorant of the product development teams. At the very least there needs to be rotations of developers working with the support teams and the support engineers working to populate the product backlog and help shape the sprint planning with product owners.
Project management is a topic that is under intense scrutiny as a discipline where methodology has become the tail that wags the dog. Too many times I have seen project management ‘professionals’ with very little context of the domain in which they operate. To them the underlying product could be anything, but they claim their process can fit any industry. This approach makes it hard to have a good dialogue with stakeholders when it comes to negotiating priorities, planning sprints and making sure that certain ground rules are adhered to in the development process.
If the project manager has no context of the user stories, their complexity or whether adequate acceptance criteria has been defined, and their role is merely tracking and reporting, then this is a low-value activity dressed up as something useful. A competent scrum master possesses domain expertise and the confidence to re-jig priorities in tandem with what the stakeholder envisages. Contrast that with a traditional project manager who wants to see everything locked down for many months ahead and can be thrown into a tailspin if features and priorities are adjusted after the ‘project’ has been planned.
We don’t work like this anymore in a dynamic business environment where everything from political, regulatory, economic and competitive events mean changes of strategy must be executed rapidly to ensure products hit the mark with customers.
The scrum master ensures the rules of agile product development are respected, e.g. not allowing an in-flight sprint to be adjusted. This is the point of sprints and planning for them. Upcoming sprints allow stakeholders to re-evaluate the list of user-stories and their content to his heart’s content, but once that sprint becomes the live one, it is going to be delivered and not tinkered with in-flight, otherwise effort is wasted. Many organisations have failed to grasp the significance of meddling with in-flight sprints in terms of lost productivity, damaged morale and financial repercussions to the budget.
The kernel of my argument is that if you have self-organising teams then you are able to do more with less people. Teams that operate in a truly agile manner don’t need a business analyst to hand them a requirements document or a QA team to point out their blunders. They are empowered to manage their destiny. This can include getting their own infrastructure (e.g. servers and databases with a cloud vendor on a pay-as-you-go model) that also reduces the need for those expensive in-house data centres and armies of infrastructure engineers.
My team won’t be coming to me and saying my feature is being held up by needing to wait three months for new hardware to be procured after they have filled in a 100-page capacity planning and architecture document for the infrastructure team.
Software engineering is about building great software products that fulfil end-user needs. Everything else (hardware, middleware, networks, databases) are a commodity and can be handed over to expert purveyors in all but the most specialised cases. Finally, self-organising teams, if empowered from top management, can be freed up to get on and deliver valuable software frequently, creating value, saving money, being highly motivated and helping their firm stay ahead of the curve.
