For sure Agile is a hot thing in today’s IT. At first being Agile was rather special. Today everyone claims to be Agile. Great results have been delivered thanks to Agile. Therefore it’s not that strange that everyone wants to have a piece of this pie. But will it really support YOU in achieving YOUR goals? In this post you should find the answer to this question.
CIOs under pressure
IT departments and providers in general and the CIOs in particular are under pressure. In today’s demanding business environment new digital business models are being introduced. While maintaining the existing IT environment, IT will have to support these new demands as well. The daily reality of rather traditional project management and development approaches blocks them in responding quickly to new emerging needs. Due to this they don’t manage to be a real business partner.
This demand-supply “conflict” increasingly becomes a reason to choose an Agile approach hoping this will increase the project development speed resulting in adding real and instant business value.
“Done well, Agile development can be an integral part of the portfolio of methods that the CIO uses to deal with increasing business demand for innovation. Done badly, Agile development will create a lot more problems than it solves.”
Recently I provided a keynote at a PMI conference claiming that the implementation of (Agile) tools will not necessarily improve the relationship in between business and IT. The implementation of tooling should be based on common sense. In case implemented well, you might be able to profit.
Practice makes perfect
Agile is basically a rather wide container term. It contains several best practice tools, methods and approaches. Due to its complexity you won’t become Agile overnight. And for sure you will not manage to become Agile in isolation. It really demands intensive cooperation in between business and IT.
The Gartner research provides 10 guidelines for implementing Agile successfully.
1: Agile not just one thing
Agile methods are many different approaches that share the same philosophy. But they are far from similar, so better think twice. It is best to choose one method, for example Kanban or Scrum, that seems to suit you well. Implement it according to the book and give it a serious try for a while, at least a month. After gaining some experience you can consider selecting other methods/tools as well.
2: Cherry-picking not allowed
Agile methods are in general very systematic. Therefore, you will have to fully implement them at first to profit from them.
Cherry-picking of the things that you believe suit you best will lead to sub optimization although the participants might even not notice. Isolated scrum implementations by IT departments are such an example. For them it feels great to have standups, sprints, etc, but if the business is not involved honestly not much has changed.
3: Agile needs two to tango
You will not profit too much from Agile without involvement of business management, IT and end users. As described above, an isolated Scrum implementation won’t work. The organization will start profiting once the business side among others appoints a Product Owner who actively participates in the project.
4: Walk first before running
Experienced Agile practitioners manage to handle big projects, just like well trained sportsmen finish a marathon or triathlon. It takes some time to gain the experience to handle bigger projects.
At Goyello we decided to implement Scrum in 2009. We chose one already rather well organized project of which the client was willing to give it a try as well. Several years later we felt sufficiently experienced to manage a big project for an insurance company Agile.
5: Becoming Agile equals continuous learning
Once you adopt Agile practices you should be willing to improve yourself continuously based on frequent reflections.
6: It’s all about teams
A small team is the corner stone of an Agile project to deliver results. The ideal team size is seven, plus or minus two people. The team is responsible to deliver according to what has been agreed. This includes taking the responsibility for fixing bad results delivered by one of the team members. The most efficient team work will be achieved when the team is sharing the same workspace.
7: Documenting and eliminating of technical debt is key
Technical debt is the difference in between the current software state and what it should be like according to demands regarding for example reliability, performance, usability, scalability, maintainability and security. This difference occurs in every development process, independent of the chosen approach. The difference is that within an Agile approach this technical debt will be noticed and included into the definition of new work packages.
8: Cooperation with suppliers might require additional attention
Because Agile only works well when business and IT intensively cooperate, it will change the existing outsourcing models. You can no longer just define your needs and wait for the delivery. Is this bad news? I doubt it. Honestly, I don’t believe that model has ever worked well. An Agile cooperation with a provider will have to be based on mutual trust. The provider will have to become a real business partner.
The Agile model will demand adjustments at the side of the outsourcer. Additional capacity and skills will be needed to manage a distributed agile setup.
9: The impact of Agile goes beyond IT
The main thing in Agile is continuous delivery of working solutions. This demands continuous engagement of both business managers and end users. It will result in a continuous flow of new and adjusted software. The organization might have to adjust to be able to handle this flow.
10: Agile might not be your Holy Grail
I guarantee that not all problems can be solved just by implementing an Agile method. It wouldn’t be fair to claim it is better than other methods. Depending on your situation it might occur that non-agile methods are most applicable to your business. Common sense should prevail to decide what method suits your challenges best.
Give Agile a try
Personally I wouldn’t like to claim that a CIO or an IT department SHOULD embrace Agile. The only thing I can say is that we are very happy that we did it in 2009. Well implemented it can really make project delivery more efficient and may be even more important, more effective. Unfortunately, there are many bad experiences as well. You will notice when you search online for “Agile failures”. It’s hard to generalize, but in many cases a bad implementation is probably the cause.
The 10 guidelines mentioned above might help you to decide whether Agile will work for you and/or your organization.
We like to share our knowledge and experience with you. In case of any questions feel free to contact us, or leave your comment below.
VP Software Development Europe for Aspire Systems. Sociologist and electrotechnical engineer, a great combination that stimulates him to look for the best working software solutions for clients. Passionate about converting great ideas into new solutions. Married and a proud father of 3 great sons. Training for and participating in triathlons/runs to stay fit.
We process cookies and make them available to Google Analytics (a service provided by Google, Inc.) to improve the performance of the website, to learn your preferences about using it and to tailor it to your needs. The data will be anonymised before being transmitted. If you do not agree to this, you may disable cookies in your browser. If you do not change your browser settings, you accept the fact that it saves cookies.