Agile or not?

Every organisation and every team needs to deliver its work. The agile ways of working seem to be a de facto standard in the IT industry and quickly take over other sectors. It is not surprising, here [1] and here [2] you can see how Agile methods outperform classical management approaches in IT. Would Agile practices be the best choice, no matter what? I'd challenge it as different situations require different ways of handling them. 

In this article, I'll share some ideas as to how to choose work management practices for a particular case, namely how to select between process management, classical project management, agile project management or crisis management, depending on the situation.

After reviewing several frameworks, one thing becomes apparent. It is all about the complexity and how to deal with it. If a situation is pretty straightforward, then going Agile might not be the best choice and vice versa. 

CYNEFIN FRAMEWORK

One approach for deciding which method to choose could be using the Cynefin [3] (pronounced as kəˈnɛvɪn) framework. This conceptual framework aids decision-making in different contexts. Cynefin puts every situation in one of the five domains/contexts.

The first domain is Simple or Clear, representing the "known knowns" situation. An example would be when the client did not transfer the loan payment to the bank on time [3]. The case is a typical scenario for a bank, where the clerk will find the proper process / best practices for this situation and start acting on it. Thus, it is usually apparent what work to do and how to do it. Classical project or process management is the most suitable for these cases. 

The second domain is Complicated, representing the "known unknowns" situation. A typical example here would be a car that produces some noise. An owner gets it into the car service. A car is a complicated system, but if you engage experts and spend some time, they can explain how it works and what to do with the noise. Classical project management and hybrid practices are most applicable to such situations.

The third domain is Complex; it's about "unknown unknowns". Examples include biological systems, complex software systems, markets or corporate cultures. If you touch a frog in some place, its leg will flinch. It is not precisely clear how its nervous system would do it. It is hard to understand how something works, though you can build hypotheses and conduct experiments. Agile practices fit this domain.

The fourth type is Chaotic. For example, a situation of war or a tsunami or a sudden economic crisis. It is impossible to predict what and how it will happen, so we act, observe, and after we bring the Chaotic to the Complex domain, then react when some explanation appears. Agile and Classical work management do not work here, but crisis management works.

The fifth one is when we have an uncertain situation, so we need to break it down into pieces and then categorise each piece using four main domains. 

AGILE READINESS

Apart from understanding what type of work management might apply to your situation, it is worth also assessing the other factors in your organisation. For that, there are several self-assessments available. Please have a look here: [4]

Here are some primary considerations [5]: 

Agile values and principles.

The team and stakeholders are ready to accept the values and principles of the Agile approach. The most important is "the right to make a mistake". Indeed, in an uncertain situation, confusion and errors are expected. Agile is about self-correction, so we learn and move forward if there is an error. 

Agile team. 

It is possible to assemble an agile team. The Agile team has to combine several characteristics:

• It should be compact (7 +/- 2 people) - also called "2 pizza team". There are techniques for scaling Agile to large teams, but they are very, very non-trivial. 
•  Include people with all the competencies required for product development and represent all departments necessary for product development.
• Team members should have enough time to work in a team. They should devote all their time to working on the project.
• Everyone should sit together in the same room (not required, but highly recommended).
• And, very importantly, the team must be ready to take responsibility.

Product Owner (Customer):

• There is a Product Owner.
• The Product Owner is authorised to determine all product requirements and prioritise tasks single-handedly. 
• The Product Owner is available and ready to discuss everything and consider product issues simultaneously as the team works. If the team has completed a sprint (for example, two weeks) and then waits a month for an opportunity to talk with the Owner, the scheme will not work.
• The Product Owner trusts the team. The Product Owner defines "what to do", and the team determines "how to do it". Agile is not a synonym for chaos; you can't get into the team process in the middle of the sprint with the words "this is not how you work, I'll explain to you how it should be" or "let's postpone this and do it better". Agile does not accept micromanagement. These are conceptually incompatible things.

Supportive senior management.

Senior management, which stands above the team and the Product Owner, verified that they are ready to consider and make decisions on issues escalated to them quickly on those issues that the team will not be able to solve at its level. And there will undoubtedly be many such questions, especially at the beginning.

Project constraints.

The team and key stakeholders agreed on critical constraints: time, budget, resources, etc. Stakeholders documented their constraints and the team accepted them.

CONCLUSION

Any change should be a conscious decision: you must clearly understand why you want Agile. It is necessary to check how ready the team, including management. The checklist above can help you with that.

It is worth mentioning that the next wave of hybrid (a combination of classical and Agile) approaches is beginning to gain momentum. There are various options, and each can have its application. But this is for the other article. 

References: 

[1] - https://www.infoq.com/articles/standish-chaos-2015/

[2] - http://www.ambysoft.com/surveys/success2018.html

[3] - https://en.wikipedia.org/wiki/Cynefin_framework or if you like a video explanation, here is a video from the author of this framework: [YouTube](https://www.youtube.com/watch?v=N7oz366X0-8)

[4] - [Agile Self-assessments - Ben Linders](https://www.benlinders.com/agile-self-assessments/)

[5] - Agile Practice Guide by [Project Management Institute](https://www.amazon.com.au/Project-Management-Institute/e/B015AKN1D2/ref=dp_byline_cont_ebooks_1)  

[6] - Cynefin image is from  Berger & Johnston (2015), 237, n. 7. and https://en.wikipedia.org/wiki/Cynefin_framework

#agile #agilemindset #projectmanagers #processmanagement #pmp #pmi #pmiacp #organisationaldevelopment