In an Agile sense, you probably work in one of two types of companies. While there are certainly hybrids of these two examples, bear with me for a while.
The first type are IT-focussed, <em>tech-savvy</em>, often relatively new companies. They sell stuff online generally or at least create products that require frequent changes or improvements.
These Type A companies have an IT infrastructure that was designed from day one to allow concurrent development, integrated testing, continuous integration, perhaps even continuous deployment, because updating their product frequently is important, both to them and to their customers.
These companies have evolved their entire operating model to continuous and rapid improvement of existing – and new – products. They practice Product Development and everything they do is geared towards that.
IT is structured by product lines, directly answerable to the business, their recruitment, personal development, organisation structure, processes, their entire culture is driven by the need for constant change.
They will generally practice Scrum or Lean, possibly with XP, perhaps using something like SAFe if they are large enough to warrant that.
The other type – Type B – comprises those more traditional, older companies, like banks, insurance, pharmaceutical companies and the like, companies where IT is not central to their core business. It’s not that IT isn’t important to them, but that IT is not integrated into the business, it’s a separate function. Some were probably founded a hundred years ago and IT became a necessary evil around the seventies, but it was difficult for most people to understand so it became a cost-centre, an expensive overhead. The systems were huge mainframe-based systems most of which still exist to this day. Changes to these systems take time, partly because of the complexity of the systems, partly because they were not designed for modern integrated testing practices and tools, and partly because the changes required are usually substantial in nature. They are often in heavily regulated industries and one change of regulatory regime results in a two-year change programme. Not one ideally suited to agile development, but one with a clearly defined goal, highly detailed and fixed requirements, an immovable deadline and often cost constraints as well.
So when we consider how to apply Agile at each of these types of companies, we need to be conscious of their vastly different needs and environments.
While type A implements change through continuous Product Development, type B implements change via projects. Why? Because they need to. Because sometimes there is a need for a Sponsor, for governance, for solution architecture.
In this environment projects make sense; they have a whole portfolio of them.
So the next time you say to someone “you don’t need a project manager or a Sponsor or a contract”, think again. And instead ask “so how agile can you be? Let’s do that.”