You may be one cool tool away from adding precious time back to your day or dealing with background noise at home. Check out these recommendations from other IT professionals
Beware the dark side of agile project management
Many teams don’t do true agile project management; they simply break legacy development process into two-week sprints. Here’s how to improve – and reap the benefits
Many IT teams and organizations are not realizing the full value of agile development and are struggling with what they call agile project management.
I believe that the term itself is creating more problems than it is solving, and that’s why so many IT teams are finding it a huge challenge. In short, overlaying a sequential project management process on an iterative agile development process is counterproductive.
Why we need agile project management
Speed to market and innovation have been key business drivers for many years, but they are even more urgent now that so many businesses have effectively become tech firms. There are few companies whose business model is not deeply dependent on their technology solutions and platforms, regardless of what industry or business they are in.
That’s pretty obvious for financial services companies, but it’s just as true today for the big sports franchises like the NFL and for logistics companies like Uber.
In a nutshell, a true agile development practice delivers three compelling business benefits that all firms need right now:
- Provide early and continuous delivery of value
- Reduce risk and impact of errors
- Improve alignment with client needs
Tips to improve agile project management
But in reality, most teams that adopt agile project management are failing to achieve these results. Here are three reasons why, with counterintuitive tips to improve the situation.
1. Acknowledge that agile is not a new version of a waterfall SDLC, where you do legacy development in sprints
So many teams are working this way without realizing it! They are still doing a sequential project lifecycle following a legacy approach. They define functional requirements, then do high-level design, then code, then test, having broken down their coding portion of the lifecycle into two-week sprints.
Waterfall projects assume that you know what the solution needs to look like before you get started. That means you can define all your requirements and design the solution up-front.
Agile projects assume that you are dealing with business challenges for which solutions are not readily predetermined, so you don’t know what the solution needs to look like before you begin designing and building it. Here, each sprint is like a science experiment where you test a hypothesis.
As in a science experiment, the result does not always prove your hypothesis is true. A successful experiment or sprint gives you a better understanding of what is true and what is not so that your next hypothesis and experiment/sprint will deliver a better result and get you closer to your truth.
Instead, many organizations are still doing waterfall development, but within what they think is an agile framework.
[ Read also: Agile vs. DevOps: What’s the difference? ]
2. Engage all groups across the organization with a stake in the outcome
Too many organizations engage only the development team in each sprint, just like they do in waterfall development. By the time they deliver any product to clients (internal or external) they are already quite far down the road to solution delivery. That makes it more difficult and expensive to course-correct, just like with waterfall.
Keeping a cross-functional product team fully engaged throughout each sprint reduces the pressure to get it right the first time because this cross-functional team is engaged in the learning experiments described above.
This should include external customers wherever possible, to avoid the “build it and they will come” syndrome. It’s also key to avoid the legacy approach of throwing specs and deliverables over the wall to each functional group.
[ Want to give your team a greater sense of urgency? Get our new resource: Fast Start Guide: Creating a sense of urgency, with John Kotter. ]
3. Recognize that the Agile Manifesto does not include the term “agile project management”
There are no projects in agile or scrum. (Just look at the Agile Manifesto published at scrum.org.) With scrum, we prioritize our user stories into backlogs and manage how many of them we address in each sprint. We strive to deliver working software at the end of each sprint, but such working software is a minimum viable product (MVP) or a minimum viable subset of the desired product.
This is a big problem for most business leaders, who are accustomed to approving IT development projects based upon a specific set of requirements delivered in a specific timeframe and at a predetermined cost.
Until and unless they accept the idea that they are no longer managing projects with fixed functions, timeframes, and costs, as they did with waterfall, they will struggle to use agile as it was designed to be used. And they will fail to realize the promised benefits of better software developed more quickly with lower risk.
Leadership teams need to recognize that we’ve all moved on from pounding nails with hammers. Agile is a new model that does not fit within a legacy project management framework.
[ What tools help support scrum, kanban, and other agile methods? Read also: Top 7 open source project management tools for agile teams. ]
Put it all together: Trust in two-week experiments
Achieving better business outcomes with agile requires that we give up the notion that agile is a project-based SDLC where we simply break our legacy development process into two-week sprints.
Starting with the development team, then including all the business and client stakeholders and even top management, enterprise agile requires everyone in the firm to accept a new approach to developing and delivering IT solutions.
Our entire organization needs to believe in using two-week experiments to learn what we need to deliver as we move through the agile process. We need to accept that not every sprint will deliver a better product. Then, and only then, will we give up chasing the ineffective notion of the need for better agile project management.
[ Culture change is the hardest part of digital transformation. Get the digital transformation eBook: Teaching an elephant to dance. ]