Agile Project Management in Enterprises

Agile Project Management in Enterprises

Big companies generally have a problem of being too slow, with too much WIP, and too many features in the backlog.

Traditionally, big companies would need 6 months for gathering requirements, another 6 for development and testing, plus worry if they have an opening in their development schedule and capital for the feasibility study to get things going.

There's also another problem. Big companies need new features to stay competitive but features are always a gamble. About only 10% of new features get desired benefits. The faster you can put out features on the market and test them, the faster you can differentiate the heroes from the zeroes and recoup the invested capital.

Products need to ship in six months. Otherwise, some Chinese company will steal our idea, have them on our competitor's store shelves, and take the majority of the market.
In these competitive times, the name of the game is quick time to market and to fail fast. We just can’t have multi year product development timelines, waiting until the end to figure out whether we have a winner or loser on our hands. We need short and quick cycle times to continually integrate feedback from the marketplace.
But that’s just half the picture. The longer the product development cycle, the longer the company capital is locked up and not giving us a return. The CFO expects that on average, R&D investments return more than 10%. That’s the internal hurdle rate. If we don’t beat the hurdle rate, the company capital would have been better spent being invested in the stock market or gambled on racehorses.
When R&D capital is locked up as WIP for more than a year, not returning cash back to the business, it becomes almost impossible to pay back the business. - The Phoenix Project: A Novel About IT, DevOps, And Helping Your Business Win

When big corporations decide to be more agile, they need methods that work at a large scale. They also need a lot of cross-functional coordination so Development, Operations, and Sales & Marketing can work together efficiently.

The best approach that enables corporations to be more agile is the DevOps movement, which usually consists of:

  • Work visualisation with Kanban boards
  • Faster time to market for new features
  • Lower failure rate of new releases
  • Shortened lead time between fixes
  • Faster emergency changes and recovery
  • Small and frequent releases
  • Controlling WIP
  • Faster feedback loops
  • Ensuring quality from the start
  • Continuous delivery and automated deployment
  • Aligning cycle time of operations with cycle time needed to keep up with customer demand (called takt time)
  • Standardized environments across development, QA, and production
  • Short sprint intervals and reduced planning horizon
  • Scrum-like team roles

Big companies often combine Agile and Waterfall, where they use practices from agile methodologies (like sprints and roles) and the efficiency of waterfall, thus creating an Agile-Waterfall Hybrid.

Agile is not a silver bullet to late projects. Big companies who choose to go agile face a whole new set of problems and risks. Here are some side effects that happened at Microsoft once they switched to agile mindset:

The problem happens when the entire company is completely and totally focused on developing an absurd number of new features and products, giving them completely unrealistic deadlines, and then shipping software on those deadlines no matter how buggy it is.
The idea is that everything is serviceable over the internet now, so they can just "fix it later", except they never do. This perpetuates a duct-tape culture that refuses to actually fix problems and instead rewards teams that find ways to work around them.
The talented programmers are stuck working on code that, at best, has to deal with multiple badly designed frameworks from other teams, or at worst work on code that is simply scrapped. New features are prioritized over all but the most system-critical bugs, and teams are never given any time to actually focus on improving their code. - Microsoft employee