So You Want to Be Agile? A Beginner’s Guide to Agile Project Management. Part 1

In an age of rapid technological progress, more and more companies are deciding to employ Agile methodologies to improve project management. Agile allows them to find ways to complete a project while not exceeding its budget and to develop solutions meeting the needs of their clients.

We prepared a series of articles about Agile project management to answer your questions such as:

• How can you prepare yourself to reap as many benefits from Agile methodologies as possible?
• How can you turn the flagship slogans of Agile marketing into actual benefits for your products?
• What do you need to keep in mind to really make work smoother using Agile?
• What steps should you take in order to develop top value products?
• How can you achieve an actual increase in team productivity using Agile methodologies

Different approaches to Agile project management

As far as Agile project management is concerned, there are two clearly distinguishable attitudes.

On the one hand, developer teams and promoters of key Agile ideas spread news far and wide about having carried out projects according to these methodologies, having completed organisational transformations, and having signed new contracts for delivering Agile projects.

On the other hand, clients remain uncertain about whether or not Agile project management will be beneficial for them. What they fear is that the absence of an exactly defined scope for a project may result in increased costs or constant changes of the implementation schedule.

Enthusiasm on the part of teams paired with apprehension and resistance on the part of other interested parties may lead to corruption of the methodology – which was, after all, created predominantly with clients in mind.

Agile project management, or how to make work more effective without increasing the workload

This is the best sales-related slogan of the Agile methodology and, at the same time, one of its benefits accompanied by the greatest number of conditions which need to be met.

Condition 1: Dear clients, please don’t spend too much time trying to imagine the final result of work.

Unfortunately, this is difficult to do as the human mind (and the sponsor of your project) has a tendency to dwell on it. When we try to tell someone about what we’re working on, we can usually picture the end result in our head. How can you deal with this challenge?

• Focus on defining the functions of the product in your organisation and the needs of clients which it will help to meet.
• Order roles and functions in such way as to have a clear understanding of what should be created first (i.e. what to start with or what to check in order to be sure that you wish to invest in the project and keep it going).

While developing an online shop, don’t assume straight away that must-have price comparison tool. Perhaps you don’t need that feature right from the start? Consider implementing it at a later stage of work – maybe it would be worth your while to integrate it with an existing solution or conduct an analysis in order to see how many clients actually use it? Before you decide to spend additional money on developing your dream tool, you should first answer the questions above.

Condition 2: Do not waste time on overanalysing things

Note what is meant here by overanalysing: dwelling on something which “may or may not be implemented as part of your product, perhaps in a year or so.” Rest assured that it won’t be there – and even if it is, its form will not be as you planned half a year earlier.

Don’t let solutions you already chose grow on you too much. My experience in implementing projects tells me that your decisions often have so much impact on the structure of the project that a solution selected well in advance turns out to be unnecessary or too time-consuming. If this is the case, you have to analyse the situation again (and you were supposed to do less, right?).

Don’t fall head over heels with your first choice

A team of developers may be your safeguard against falling head over heels in love with a specific solution of your choice. Present your ideas, your vision of the product, and your concept for the stages of its implementation to the team.

The team will provide you with feedback and tell you whether to use a solution to which further elements can be added in the future (it may be more expensive at the moment but cheaper in the long run) or to stick to a here-and-now option. Initially, this may seem like a better and quicker alternative but developing it will require more work at subsequent stages of the project.

Condition 3: Manage the scope of your project in an informed way

The power of the Agile approach lies in managing the scope of your project – this is why you need to be able to say “NO” (or, at least, “NOT YET”) to interested parties.

I have heard of many situations where the scope of initial implementation was defined, including its date, and then, when everything seemed to be going smoothly and when the workload was about to drop, additional requirements sprang up, affecting steps which had been agreed-upon – “this is not how we imagined it” and “this does not work the way we expected it to.”

Note down underlying versions of application

Some of such changes may actually turn out to be very important so you can consider it a success that they were communicated to you before the implementation. However, there are always people who will conclude that the first version – the one without blinking colours on the button – would be good enough.

It‘s best to note down principles underlying versions and implementation of application in order to be able to review them and consciously decide to add other elements to the scope. It’s not necessarily a bad thing. if the first version of your application doesn’t meet 100% of user expectations, As Henry Ford once said: “If I had asked people what they wanted, they would have said faster horses.”

Condition 4: Do talk!

It’s worthwhile to consult your team of programmers when managing the scope of your project. A functionality which seems like a walk in the park from a business perspective may mean a lot of work in terms of system structure development. If implementing a functionality entails certain risks, remember that reducing the scope of work takes you a step closer to reducing workload.

The developer team should also accept some responsibility for “working less.” Dear Client, that’s why you should talk with your team members as often as possible and consult with them before you ask them to develop some functionality. It’s possible that when working together you’ll succeed in choosing a solution that will meet the needs of your company without requiring radical changes and considerable work input.

Tools for scope management

Scrum and other Agile methodologies provide you with tools for scope management.

Do you feel that you’ve been “experimenting with” some functionalities for too long? Maybe you should consider reducing the length of your sprints to make yourself and the developer team run shorter tests and verify business theories. Within the Unity Group, we have considerable experience in implementing such projects. If you’d like to learn more about them, please read about our work methods.

In the next parts of our series about Agile methodologies you’ll learn:

• How to define values as part of a project and how to check if you are achieving values you have set? (Part 2)
• Why you should not restrict project implementation methods? (Part 3)

As Unity Group we use Agile Methodologies in everyday tasks.
Feel free to contact us and we’ll be happy to answer all of your questions!