Today, all companies wants to become agile. This is great. Most of them wants to be agile by applying one of the Agile methodologies. What is strange. Let’s go through the intention, what shrives this „agility movement“!
Looking into the statistics you may find the same result: two-third of the large IT projects are in risk and two-third of the projects were in risk fails! This means that almost the half of large IT projects started will fail! This is a terrific amount we agree.
The cost of these failures is gigantic. First, the direct cost spent to the project target goes to the dogs. The larger portion is in the field of the expected result, the lost income of the failed projects! If you look around your company to get the opportunity cost used for project financial planning, you will have a great guest of the minimum loss of the failed projects there.
On the other hand, what the sponsors and the management wants? Simply: successful projects, cost effective operation, great team and last but not least appreciation.
Some would say, that „The Largest Failed Project Ever“ is a good award, but they are the minority.
We see that the result of the large amount of failed project is so far from the thing management wants, therefore they have to take action!
Unfortunately the managers have to manage large variety of project types and solutions, and none of them can understand all the details of all the different kind of activities they have to care. Management needs to use generic tools and methodologies, which let them manage the ecosystem around them: motivation approaches, financial planning, organisation models, controlling technics, reporting structures, task management tools, information templates and so. All these topics are developed on their evolutionyear by year. As the failure rate is still there and seems to be constant, the management toolset has to change again and again.
Here we arrived the question how companies select tools and methodologies. None of them can try everything, therefore they select using the same way as all of us tries to find the best things: preference based.
Preference is to use something what is already successful. How do you find something successful? By the information around you. The things more people speaks about seems to be the more successful, therefore that is the most probable selection of others. Yes, it is like a fashion.
Failures say, you need something new, which can be anything: insource, outsource, off-shore, near-shore, Angular, open-source, agile, creative and/or open-air office space, BYOD, work from remote, AI, Big data, digital, automation, etc. Did you ever hear about either one of them?
Each can help - if you do it well. But you have to do it well first! This is the baseline!
Our topic is agility, therefore turn back to it and look, how to recognise an agile organisation! They have:
- Daily standup
- Large white walls with coloured stickies
- They use JIRA
- They deliver in sprints
- Loose, informal culture
Are those enough? Alas they are not. Too many teams, which meets either all of them topics above generate uncontrollable costs and unsuccessful deliveries. These teams are the ones, who thinks that externalities make someone Agile.
Before going forward we have to clearly understand the difference between being Agile and being agile. The following comparison board shows the Agile principles and the definition of agility:
Agility by dictionaries
- Ability to move quickly and easily: though he was without formal training as dancer or athlete, his physical agility was inexhaustible.
- Ability to think and understand quickly: games teach hand–eye coordination, mental agility, and alertness.
- Agile people quickly solves problems.
- Quick and effective
The Agile principles
- Customer satisfaction by early and continuous delivery of valuable software.
- Welcome changing requirements, even in late development.
- Deliver working software frequently (weeks rather than months)
- Close, daily cooperation between business people and developers
- Projects are built around motivated individuals, who should be trusted (some definitions mention agile people here)
- Face-to-face conversation is the best form of communication (co-location)
- Working software is the primary measure of progress
- Sustainable development, able to maintain a constant pace
- Continuous attention to technical excellence and good design
- Simplicity—the art of maximizing the amount of work not done—is essential
- Best architectures, requirements, and designs emerge from self-organizing teams
- Regularly, the team reflects on how to become more effective, and adjusts accordingly
The board will help you to identify if you are Agile or simply agile. Agility is crucial if you would change things around you and Agile methodologies help to plan and follow your actions. Agility is a must, Agile is an option. Agility is the launch-site of Agile.
I would turn a bit for the basement of agile organisations, what is confidence. There are things which builds confidence and you have to aware not to fail any of them!
If you have the good basement you need some extra, to „build the walls“: accountabilty, being well organised, strict controlls, and a good target which pulls you towards itself.
At last I would share you the info picture of Reactor which shows what tools and technologies we used in the course of development and communication till now. You would now that some of them was dead-end, therfore we change (example: OpenAPI exercises) others are still there.
The team worked remotely, therefore we didn’t have daily standups, we used JIRA for requirement administration (we had user stories there) and to define sprints, we made fast decisions and were brave to try new things. The Reactor development was agile while it was not Agile.