Agile, but quality delivering organization?

I had the chance to work within a mammoth organization who is undertaking ambitious transformations in order to be more agile. I would like to talk about this subject with a focus on processes.

So why we need processes?  In a mammoth organization, processes guarantee quality. Indeed, when we have so many people doing different activities on many products in different locations... things get really complicated! thus we need to organize the interactions among people to minimize operational and financial risks, and provide fine KPIs for management. Moreover, processes reflect the learning curve of an industrialized organization and give an important guidance framework for employees to work conveniently.

Unfortunately, depending on their design and philosophy, processes can increase dramatically the inertia of the mammoth, thus its efficiency, and create a huge frustration among employees and customers. I noticed that when you design a process as taylored-style black boxes with inputs and outputs, well, the people inside these black boxes just get blinded!!! Indeed, the result is dilution syndrome:

• Dilution of information: precious information get lost through the process.
• Dilution of responsibility: In crisis, it becomes difficult to identify a clear responsible for resolving the problems, instead each actor hides behind its process! That doesn't help people develop sense of autonomy.
• Dilution of purpose: employees forget about the final purpose for which the process was made, and the process becomes the purpose itself!

Well, we are not in the Ice Age anymore, and Mammoths should evolve in order to survive. The winning DNA is agility in our age, the age of quick changes, real time information, incertitude and globalization.

   

So how can we get agile, but quality delivering organization? In my point view, a couple of aspects must be well considered:

• Is a process always the solution for a workflow? I don't think so. Project management can be better adapted in certain cases. The choice can be made according to the complexity and the stakes of the workflow. Hybrid paradigms can be thought of also, for example designing only high level processes and giving more flexibility to actors.
• Actors of the process must understand the process globally and especially it's final purpose. The management must develop a collaborative culture with transversal skills, and autonomy.
• Set up 2.0 participative mechanisms for improving processes rapidly by managers and users.
• Provide digital tools respecting the philosophy of the previous aspects: knowledge management, collaborative and communication tools, intelligent workflow tools...

 Mammoths, be aware of natural selection!!!

Scrum & Outsourcing

Agile development is a fashion nowadays. Anyone one who wants to shine in a professional discussion adds SCRUM keyword between his words. For making things short, Scrum is a very dynamic and flexible way of  work organization in order to conduct a project. In scrum we privilege persons and interaction over processes, working products over heavy documentation, client collaboration and trust over negotiation and contracts, and finally flexibility over planning.

In big companies, sometimes there is a need to reinforce scrum teams with external persons, which is known as technical assistance (outsourcing). This is a very risky strategy if it is not well managed and understood.

As said before, scrum is highly dependent on interaction among team members, and on their spirit of initiative and proposition. If the external members aren't motivated enough, scrum can be a nightmare for the project. Many reasons are possible of this lack of motivation: The external member intervene for a short period of time, he doesn't have a good vision of the project, the scrum master hides a lot of information considered important to his company... The problem with scrum is that documentation isn't present in abundance. It means that scopes and rules of work aren't well defined and in case of problems it is not easy to contractually repair the damage. When trust is not well present, hell of mutual accusations threatens the success of the project.

Scrum's name is inspired by Rugby. It is a team game. If you aren't sure about the external people you want to integrate in your team better not use them and work harder in the smaller team, or otherwise work in the standard V-model process.

Achraf