Traditional project approach
Agile Product Ownership in a Nutshell
Agile brings a number of new principles and insights to projects
- Team members have much more to say about the project and are therefore often in multiple alternating roles: advisor, executor, designer, planner
- The design of a project result gradually develops over time and is usually not predetermined
- Project steps (milestones, interim results) are cut into smaller parts, making the work easier to understand and can be adjusted more quickly if an element to be built does not work out as desired
- Teams are invited to try out things that promote innovation and creativity (and more motivation!)
- The planning of the project is based on smaller elements, which is more realistic (compared to large deadlines over ‘a few months’)
- The team will start building almost immediately and will not wait for instructions from a project plan
Working in the Agile way has a few major advantages
- The iterative approach allows you to steer the project in a different direction if necessary, for example if the specifications of an intended project result in change in the interim
- By regularly delivering intermediate results, problems and errors are more likely to come to light
- The whole team is involved in the construction and development of a project instead of this being done by individual specialized designers, project leader(s), builders and testers
- The team is less under pressure because there is less chance of ‘cramming’ too much work into an iteration (compared to the pressure to reach a deadline that is not realistic).
- The relatively short iterations make the progress of the work more visible, which motivates the team and provides more insight into the progress to clients
(see also: the Agile manifesto)
After the success of Agile methods such as Extreme Programming, Scrum and DSDM in the ICT world, the approach is now used more often in other environments. There seem to be parties that want to apply Scrum everywhere, but that is not a good idea. Nor is Agile always a better approach than traditional project management.
Sometimes it is a good idea to think through a project carefully before getting started. Working in an Agile way is not without pitfalls or disadvantages.
Types of Agile, what is Scrum?
Just as with ‘normal’ project management, various schools have arisen within Agile. The best known are: Extreme Programming, Scrum, DSDM, Chrystal Clear and many Agile methods for large groups (‘scaled Agile’). Scrum has become escpecially popular and is now the most used Agile system, although … read also: What is Scrum?
Just as with the project management methods, almost no one follows the Agile methods to the letter. And this is the same with Scrum.
There are all kinds of variations on Scrum and therefore the discussions about what works or not, how strict you have to apply certain Scrum rules (“should iteration be a fixed period or may it vary?”) And even whether a project management system should be called Scrum or Agile.
We meet teams who think they are ‘Agile’ when they meet once a week and discuss a todo list (which they have renamed to the Agile name: ‘product backlog’). Or a construction site where Scrum was introduced because the team now starts every morning with standing work meetings (even though nothing else was adopted from the Scrum method).
The fact that organizations experiment with different methods and apply their own Agile ‘sauce’ or brand of project management can only be a good things. Things need to be appied by individuals and should be custom-made to fit people’s requirements. So we must continue to innovate, including at the organizational level.
The confusion that arises from the various ways Agile is applied sometimes can be inconvenient because it can brings confusion and miscommunication.
For example, as a result of our Agile Scan, we encountered an organization where there were three different definitions of the Scrum roles and their related tasks and responsibilities. No wonder the Agile projects were not running well and people kept blaming each other!
A project team (and mother organization) must at least decide between eachother what Agile means to them before they apply their own Agile approach. But we often come across companies that do not yet dare to work with Agile, or only want to ‘half’ implement it for various reasons. Or companies that stick with a project leader, even though an Agile team does not have this role and, moreover, such a role gets in the way of the Agile process. We also regularly come across. statements such as: “we do not have to plan because we use Agile” or “Agile is more of an attitude and mindset, so we do not have to work in a structured way”. But in fact Agile is not that flexible and is certainly more than just a mindset. The more important underlying question is: how should we organize our project and what agreements should we make about the approach?
The advice to organizations and project leaders is therefore: learn the Agile approach so that you can decide whether, how (and if) you can use it in your projects.