If you ask a senior manager in an IT company today, they would say that they are Agile. Their explanation would be something as follows. They would say that they had followed waterfall and in some cases no development process at all for a good time period and that things had been all over the place. They would then go on to say that the management made a conscious decision to switch to Agile and that since then, everything had been smooth sailing.
Have you ever been brave enough to tell someone that they are not Agile? You may be told off, be treated as a traitor or as a mad man or even end up being reported to police ☺. The simple reason being that Agile is perceived as been ‘good’ or the ‘best’ in most people’s mind. It is like saying the other person that they are not ‘good’ or they are not the ‘best’.
People may say that they are agile simply because they have implemented the agile ceremonies or practices, gone through the agile principles defined in the manifesto and because they are diligently following the scrum ceremonies and getting on with feature development as early as possible. So, you can casually mention to them that ‘Hey, you are no longer agile, you’ve adopted immediate development as opposed to agile development.
Why have project management approaches come into being? During the initial stages of software development, may be in the 1980s and early 1990s, the development activities happened in an unstructured and ad-hoc manner where lan-driven or change-driven approaches were not in place. Like with any other industry, approaches and processes came into being to solve this problem. Waterfall, Iterative, Spiral and other approaches were introduced as a result. However, with time when ailments were found in the waterfall approach, the cure introduced by scholars and other management consultants was Agile.
Has it solved the problem?
We still take forever to deliver projects. Still there are issues in the requirements, code, and quality. Agile has not made things quicker but it has just given more flexibility in terms of requirements management at the expense of quality and predictability.
The Agile manifesto is like the bible to agile practitioners. Yet only a handful actually read the book word to word from start to end. Even if they read it, only a small number of people end up following it and that too follow it in a sensible manner.
Myself coming from Sri Lanka have worked in a company which is one of the best software companies to work in the country. The company has embraced agile diligently where even the CEO is a Certified Scrum Master. The company has a unique culture, where the staff is encouraged to develop soft skills, do extra activities such as sports, attending industry meet-ups, and having fun in addition to carrying out day-to-day work for customers. The positive vibe created means that the company gets the best resources and university students from the country. Simply put, the success is not attributable to Agile but to the staff working there. The team follows different flavours of Agile such as Scrum, Kanban and Lean. But most of all, they work with a fair amount of common sense and empathy.
Projects are unique in terms of requirements, constraints such as time, cost, effort and quality and in terms of expected outcomes. One size does not fit all. Hence, each project will face its own set of problems which results in the team requiring to make decisions while the project is in progress. Be it a waterfall based project or be it an agile project, every project team must face a bumpy ride during its duration. Hence common sense must prevail.
Even if you feel that you are a fully Agile company don’t you still face the following problems?
- Inability to finish planning during the specified sprint planning session
- Not getting the helicopter view of the project which results in horizon planning rather than long term planning. Planning being limited due to shorter sprint durations
- Looking at making complete architectural designs and not being confident in an evolving architecture
- Fear of having to do rework which may result in cost, time and quality overruns
- Continuous integration resulting in infrastructure, production scripts to be run over and over again
- Trouble in managing stakeholder expectations as well as the stakeholders not being able to define requirements well ahead thinking that things can be changed any time
- Team members getting on with development without properly discussing requirements, designs and progress
Above are only a few of the problems with Agile teams. I’m sure that there are many more.
So, how do we get out of these problems. It’s so simple. It has to be through common sense. Common sense must prevail as to how blockers are removed, how work can progress without detailed requirements or designs, how to best utilize technical and physical resources to develop and deploy solutions and so on.
As an IT professional, the best approach is to take one day at a time or even one hour at a time. Be ready for change and be able to adapt to situations. Discuss and argue, but make a conclusive decision to make conscious, rational decisions. This will help projects to succeed.