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.
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.
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.
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.
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.