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.
MORE ON AGILE PROJECT MANAGEMENT
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. ]
Subscribe to our weekly newsletter.
Keep up with the latest advice and insights from CIOs and IT leaders.
Weather you are working in an agile environment or Scrum. I think one common thing is the use of effective productivity tools like TaskQue which helps in achieving deadlines of the project. Secondly, the established organizations have good processes but the real challenge comes in new companies where you have to implement new processes. Agile adoption is not that easy. People in companies are often reluctant to change.
I like the emphasis you're placing on the inspect and adapt concept that agile software development embraces, but teams also need to be a bit careful to not think of it as an experiment so much that they risk the ability to deliver on their sprint goal. Some unknown is always part of the process, but backlog refinement, spikes and user feedback in sprint review all help to take some of the unknown out of the process of consistently delivering working software.
When did Agile start reducing risk? Agility starts by accepting risk.
Agility reduces risk because you are constantly (short cycles) getting feedback and not waiting 18 months to realize you delivered something that the customer or user doesn't want. Focusing on the delivery of value. It also makes things very transparent which can certainly add risk, but those risks are there anyway wether you know about them or not, now you just know they are there.
Agile scope, Agile schedule and Agile budget. Good luck in selling that dark side risk to managers. Another article article that ignores what it takes to sell a solution. Agile is another series of broken promises and an alternative in change management.
Another think to consider to have real successful Agile project is that each team working on a sprint should collaborate with each other to ensure proper impact assessment and avoid doubling works and remain focus on quality to better fit customer needs. I have seen to many sprint teams working in silo, redoing analysis, evaluation that were already done by other teams and not considering the impact of their development/design on other part of the sub-product. A lot of time can be lost and risk for the project to be overrun by cascading issues.