In my last blog, I left you with the question: Is the agile method good for any kind of project?
Let’s first agree on what it means to have an agile approach to working. Currently this is a very popular word, next to cloud and digital. To me, this is about being effective, fast, reliable, and communicative as well as optimizing whenever possible, focusing on individual tasks, and maintaining control of the final outcome. Speed is as important as constant focus on quality. At the end of the day, it is all about finding balance between speed and precision.
Now let’s look at an ‘Agile methodology’. Agile methods are mentioned in the Guide to the Project Management Body of Knowledge (PMBOK Guide) in the Project Lifecycle definition: Adaptive project lifecycle, a project lifecycle, also known as change-driven or agile method, that is intended to facilitate change and requires a high degree of ongoing stakeholder involvement. Adaptive lifecycles are also iterative and incremental, but differ in that iterations are very rapid (usually 2-4 weeks in length) and are fixed in time and resources.
Agile aims to enable new product or service development in a highly flexible and interactive manner. It requires capable individuals from the relevant business to be consistently open to customer input and non-hierarchical forms of leadership. It’s a bit like bees. There’s no team leader, no manager, just a high level of interaction and commitment by all to the allocated task. The Queen Bee just makes sure there are enough bees to do the job.
This means that Agile Project Managers should be fluent in so-called soft skills: connecting people, interacting with them, and quickly spotting and closing communication gaps. This is also about team building and coaching, which is closely aligned to the skills and methods required for Organizational Change Management.
Going further, Project Managers should act as facilitators and ‘servant leaders’ to empower their teams to reach their own conclusions. These skills enable Project Managers to accept input from team members and project stakeholders while gaining their commitment to deliver project outcomes.
Thinking about my own experience and the projects I’ve managed, I know how incredibly difficult it can be to take the position of a coach, or, as some might call it, a servant to the project team, rather than an individual contributor. Taking a backseat to the team and letting them shine in the spotlight does bring impressive results—and that’s what matters.
So coming back to my question: Is every project relevant for the Agile method? I think so. Of course in some cases, agile methods will be followed 100% while others will just apply a small portion of them.
To understand the main differences between the classical and Agile methods of project management, I find the comparison below to be simple and straight to the point.
Agile methods use expressions like: timebox, daily stand-ups, scrum, extreme programming, increases, and MoSCoW (Must have, Should have, Could have, Want have). Without jumping into the definition of each of these, you can tell it is all about speed and making sure EVERYTHING is delivered within the agreed time and cost and with assured quality. It does not require linear thinking about features and deliverables. Algorithms are linear, and PMBOK provides linear steering. Agile is accepting the changing ecosystem and going in circles and iterations rather than taking the traditional linear approach where a task is completed and approved before moving to the next task.
The market says Agile is mostly for software development, but Capgemini finds tremendous value in using it for transformation and transition projects.
The project managers who support our transformation projects are shifting their thinking about managing time, cost, and scope constraints, and taking a new approach to managing uncertainty, risk and change. The combination of such project managers and transformation consultants is our recipe for success.
How are you applying an agile methodology in your operations?