Whoever starts learning about Agile usually has a lot of questions. Totally normal. I was, for example, recently asked whether mixed forms of Agile and Traditional project work are possible. More precisely, the question was:
Some projects need to be rolled out within fixed budget and time frames – is it possible to work with a mixed form of Agile and Traditional here?
First of all, it should be said that mixing Agile and Traditional is a possibility, of course.
Whoever sets out to work Agile, usually cannot avoid mixing the methods anyway. If only because people tend to fall into old patterns. But also because entire organizations can not be converted to agile by pressing a button.
And this is true even if (but actually JUST BECAUSE) we know that exactly THAT is what we try to achieve with again and again enrolling restructuring measures within the companies of ours.
Again and again with moderate to no success.
By the way, this is also often the case when “Agile marching orders” are given in order to change the way of working into any kind of “Agile culture”.
This of course is terrible. (Also usually terribly unsuccessful.) And – let me mention this very clearly – completely unagile.
But back to the question.
But back to the question.As specialists of their own work, teams always choose those forms of collaboration that are good for them and their business
This means: It is possible that teams simply use agile and traditional approaches.
But even if ýou’ll find ways of doing from different worlds, it is more likely that teams will opt for one form or the other in the medium run.
By the way, this is true whether there is fixed framework of time and budget.
In this context
In this context I would like to remind you that Agile working frameworks were invented because more and more often “traditional” means could and can not prevent that teams fail to meet the requirements of time and budget.
Or to put it another way: Classical management is no guarantee that project goals are being met.
THIS is a lesson we really should have learned by now.Especially in Germany, after Berlin, Hamburg and Stuttgart – to name just the most expensive tip of the iceberg. You surely can think of some more examples of your own company projects that got out of hand.
But it is not (only) the fault of classical management approaches that this happens.
Rather, NO approach whatsoever can guarantee that the goals will be reached.
Neither can Agile. But it handles this fact openly and in a particularly effective way.
How projects develop can be estimated in advance.
And project can be planned for. Nevertheless, the unexpected can happen. And it does so on a regular basis.
Regardless of how projects are managed.
No matter how well they were planned.
And no matter how well they were monitored.
So there will not be one hundred percent security
even if clients, owners, management and team alike would like to see that happen.
Agile approaches and methods
such as Scrum and Kanban openly acknowledge this. (Meaning acknowledging both: that there can’t be complete security AND that we all urge for it.)
So, in a sense, as a second-best solution, they strive to maximize mutual reliability. At the same time, they minimize project risks through methodological principles such as: Using expert knowledge across the team, turning those affected into participants, short experimentation, feedback and learning loops, etc.
Experience shows that this works very well.
The speed and accuracy of goal getting usually improves very quickly. Also and especially with fixed requirements for project or business goals.
By the way, these fixed requirements for project and business goals exist not only for some, but ALWAYS for ALL business activities and projects.
About that, however, some other time…