The Challenges Project Managers Need to Overcome When Going Agile

With Agile and Scrum, the process or framework is the easy part, while the ‘soft part’ – the people and culture, is much more complicated. This is because they rely much more on people and values, unlike more methodology-driven processes that are learnt until you can do them. But how good is methodology when it comes to innovation? One key reason for going Agile is it enables people to be creative and come up with ideas, those which can’t be killed off with process. With Agile, people are given freedom – but they need to understand what to do with it, as well as what they are expected to produce with it. Crucially, this freedom comes with responsibility and the need for confidence – a big cultural change which can be daunting and off-putting for organisations, not to mention challenging for the project manager individuals concerned. The renewed optimism in market forces and resulting pressure from competition might just be enough to convince companies to move towards a more innovative, and therefore Agile, direction. For those that do, there are challenges that can make Agile difficult to implement in the beginning, , but by being aware and mindful of the benefits it will bring to productivity in the long run will not fail to make it worthwhile.

Trust

Once a decision has been made to go Agile, people want it to happen on the spot. They might do the two-day training and expect that they can now be Agile. The problem is it involves trust – and this trust has to be earned over time, on both the management and project team sides. A big issue is with management not trusting people. It is much easier to put trust in a process that is validated, than in people – because you either don’t know them or because they don’t have the right skills, or if they do, there is always the risk that things might happen that they’re not equipped to deal with. To overcome this, management need to understand that to go Agile they are taking a risk, but that there is a very good reason for doing so.

Empowerment

A big part of Agile is giving the project team the power and responsibility to make all decisions. Until this point, management has been making the decisions the project team executes. So if you say ok, let’s switch, this will be too fast. It has to be done in small steps, with the first step being to challenge the decisions, then make some decisions with management at your side – so if they are bad decisions, management will be there to help. People generally want to be empowered, but they are scared of being responsibility and accountable for these decisions. This is a problem because they will then start reaching for management to take responsibility for ideas, so their freedom is compromised. You can see how easy it is to kill off the empowerment ideology. But this can be avoided by taking it slowly and by working alongside management to encourage people to make decisions – even stupid ones. They should not feel that if they make a bad decision, there will be consequences for them. It’s all about the process of learning to make them and as well as having confidence so they are not afraid of making a decision. By being handed responsibility gradually by management, the project team will soon understand that they are in fact the most skilled to make these decisions.

Self-organisation

Being able to organise is a whole different science to that of executing.  Again, it relies on a lot of freedom It’s similar to asking someone to not only be responsible for doing their job, but for the result of their job. Most people are in a comfort zone – when you ask them to do something they are not used to do doing, you are asking them to exit their comfort zone. Again, this can cause problems, but as long as there is a will and a need to deliver results, it should not be hard to overcome.

Generalising specialists

Traditionally, people are used to focussing on one particular area of expertise, but with Agile you are supposed to be part of a team in which you know – and can do – everything. But being able to do things is one thing – being willing to do things is another. Many people still want to compartmentalise their job, and only be accountable for that job. People can also think of themselves as overqualified for some of the jobs they are supposed to be doing as part of the team (e.g. a developer doing testing). But if you don’t step in when needed, things won’t get done and then the whole team has a problem. Instead, for Agile to work, everyone needs to be accountable for the result. Once they are aware of this, Agile team members should be much happier to jump in when someone needs help.

The Lack of Leadership Leads to Management

When confronted with the alternative of being more self-organising, decision-making and accountable people tend to blame management for not giving them enough freedom or trust. Which might be the same thing, in fact!

Meanwhile everybody seems to agree that without management, everything could fall apart and, in most organisations, it will. But then management means centralised, top-down decision, putting people in execution mode and basically a command-and control structure. Not very productive in today’s world. The management perspective on the same thing is quite different. In fact, it is the opposite! Most people managers complain about low motivation and morale of their teams, lack of accountability and initiative, consistently missing objectives, being over the budget and late.

“Knowing yourself the way you do, would you trust yourself?”

And here come a few tough questions: is management a pre-defined solution to organise people and achieve results? Or is it just a consequence of people not being able to get things done on their own? The challenge today for most professionals is to prove themselves able, confident, empowered and competent to get the job done. With all the tools and methods today people are getting the right skills and the right structures to perform with little or no involvement from a superior.

Probably there will always be some structures and hierarchies and bosses but for sure the society never looked so flat as it does today. So, showing some leadership might actually be the solution.

Top 5 Agile Concepts You Really Need to Grasp

The Agile Mind-set.

To many people Agile is just another approach to project management, another set of methodologies which means applying different processes to achieve the results. And it is that too, but it is much more than that!

Before even talking about Agile methodologies we need to understand and accept the idea that Agile is first and foremost, a mind-set. It is a way of thinking about the work that you do and challenge many of the things you do. And more importantly, always trying to see if there’s a better way of doing things.  Agile is a way of achieving results that is based not so much on what plans or processes are directing you to do but more on what is the right thing to do. To put it simply, Agile is adding value through your personal contribution and ideas beyond what people already expect you to do. It might seem like plain common sense to act based on your core values but as many of those who have implemented Agile can tell you, it is not that easy. It is not easy because we have to deal with existing processes – and they have to be respected – hierarchies, customers who might not fully understand this way of working not to mention that the whole system of values could be corrupted.

Luckily, there’s a solution to this. In the Agile world people regard the Agile Manifesto (www.agilemanifesto.org) as the most important document when you are at the beginning of your Agile journey. What is does is to lay it out for you as simple as possible what are the values you should share when you are doing Agile. And because the common sense seems to be the theme here, the manifesto reiterates simple concepts like valuing people, helping your customers and delivering something of value that could benefit your end customers. This set of values and principles that you find in the manifesto is so fundamental that, in many people’s experience, when Agile implementations fail, they don’t fail because of a poorly implemented methodology but because people break the values in the manifesto.

Slicing your product

One of the benefits of doing Agile is that you are delivering your product faster and ensure you are delivering the right product. You do that by slicing your product and delivering a slice of that product with every iteration. We call this iterative and incremental.

Being able to slice your product and deliver it in thin slices has two major benefits:

Your customers are getting some functionalities – hopefully the most valuable – quite quickly and they don’t have to wait until to end of the project when they get the whole product. They will get the whole product in the end of course, but in slices delivered after each iteration. It might not be the whole product you’ll get after each iteration – and it is not supposed to be – but for sure it’s better than nothing. Not to mention that if you really manage to slice it into independent pieces, your slices could deliver value by themselves. So, every few weeks you’ll get something!

Your customers can provide some valuable feedback early enough so you can still act on it. So, what kind of feedback could they possibly provide? First, they can say they don’t like what they see. It’s never nice to learn you are not building the right product but if that is the case, you would want to know it as soon as possible. With many other approaches to project management, you usually learn that at the end of the project when it’s too late to change something. In Agile, we call this “fail fast”. If you were to fail you would want to fail fast and cheaply. The other benefit of having your customer validate the product is that they might get more ideas of new functionalities that they may want in the product and maybe they were not obvious at the beginning of the project. A famous acronym in Agile is IKIWISI (“I’ll know it when I’ll see it”) which means customers react much better when they are shown something. If you want, you can look at this as a customer co-creation of the product.

Limit your inventory

This is probably less obvious at first sight but it is one of the cornerstones of being agile. It simply means we chose to focus on fewer things rather than on high volumes. We could just say focus but very often we have to deal with so many things in parallel that it is hard to concentrate and focus. When a Scrum team plans a Sprint, they limit the inventory of work they will focus on to just one Sprint – a few weeks. They do keep in mind the overall product but they commit to a small piece of functionality and focus on getting it done. When a Scrum team performs a Daily Stand-up, the talk about what they did the day before, what they plan to do in the next day and what’s blocking them. So again, a very limited inventory. What is the benefit of operating with a limited inventory? First, you will finish faster which means you are delivering something. Imagine you have to work on a piece of functionality that takes 10 days. If you split that in 10 pieces you might actually deliver something every day. The smaller piece might not be fully functional by itself, but you can show progress. Operating with big inventories has a few problems. You will spread your attention on multiple items and you will not be able to focus. You might end up working a lot but not necessarily delivering something at the end of the day. Working with big inventories requires also a lot of extra work which is not necessarily valuable for you customers, things like more meetings to sync, more emails or documents to write and read, increased and often more complicated communications and collaboration.

Achieve flow

Another thing which is not widely known about Agile is that people who are doing Agile know that are part of a flow. They understand that by themselves, as individuals, they cannot achieve much. If I were to pick an example, I would pick a software developer. This developer might think that he or she can work independently and build code or software features. But in the same time the developer could also realise that he or she needs somebody to prepare the specification – possibly a business analyst – somebody to do some design – a designer maybe – or somebody to build the architecture and the databases. And this is only what happens before the developer actually does some work. Equally you can apply the same thinking to what happens when the software developer finished the work. Those functionalities will have to be tested, integrated, deployed, maintained, etc.

In Agile, we understand we are adding value only if we deliver something valuable to the end customer. That means we need to see the whole flow, understand who does what and constantly think about ways to improve this flow by making it faster and faster. To continue with the previous example, our software developer will be more concerned about how the end product gets to the end customer rather than how he or she can do more work individually. Our developer might realise that in addition to writing code, he or she can provide a lot of help and support to the colleagues involved in other parts of this flow. In the end, you are as valuable as the result you are producing.

Embrace Kaizen

The Japanese word “Kaizen” has become more a philosophy than a simple word. It means focus on continuous improvement all the time. Instead of big initiatives and dramatic transformations, we try to change something small every day and become better and better. In every Agile methodology, we talk about how we can build better products and how we can be more efficient, which normally translates into better and cheaper products.

Just to illustrate, let’s pick Scrum, one of the most famous Agile frameworks. At the end of each Sprint, the team will do a Sprint Review and a Sprint Retrospective. These two ceremonies – yes, that’s how they’re called! – are the Kaizen moment.

The Sprint Review is the moment when we look and the product we built in the Sprint and try to see if there’s a way to improve it. And to do that, we do a demonstration in front of real end customers. We are showing them the product hoping that they will get inspired and give us more ideas about what new features we can add to the product. So, with this we are trying to improve the product.

The Sprint Retrospective on the other hand, aims at improving the processes. The team gets together and tries to identify things that can be done differently, tools that can make them more productive, processes which could be optimised, time that can be saved. Implementing these ideas normally leads to better processes, more results per Sprint, so a more efficient team.

In the end, the Kaizen philosophy is quite clear and simple. It doesn’t really matter what you do and how you do it, just give yourself some time to reflect and improve it. That’s why we say that in Agile the only relevant competition is yourself a Sprint ago. If people truly embrace the Agile values they will do this naturally with no pressure from the outside. They understand that by improving the product they are building and the processes they are using, they have a tremendous added value which makes them reliable partners for their customers. In conclusion, doing Agile is not really that hard. But it requires a good understanding of a few things like the ones we’ve covered here.

Once these concepts are clear, accepted and shared, doing Agile becomes just a formality. Or just plain common sense!