Decoding Agile?Mindset

How do agile minds take key business decisions??

Yes, it started in the Software development industry; but it did not stop there.

Software developments are unique projects which are full of uncertainty and ambiguity. In such a situation, following the traditional approach of project management, i.e. initiation, planning, execution, monitoring and controlling, and closing, often results in downward spiraling negotiation between customers and suppliers, which concludes with bitter experiences for both parties.

Unfortunately, I was at the forefront of one such accident.

We are in a business of doing business. At the core of any business endeavor is an ongoing pursuit to create and apportion value. The stakeholders are working together so that they generate a valuable pie for everybody, which can then be shared amongst themselves. What can be more disheartening than to see these stakeholders fighting to grab a bigger pie without first being able to create the pie itself? Can there be a better way to fizzle out such chaos in the ever-expanding software development industry? This challenge attracted many thought leaders from the industry and academia to research and design better approaches to manage these unique projects. Agile Alliance summarizes the timeline of efforts by some of the prominent thought leaders here.

A significant step forward in this direction was the sign-off on the Agile Manifesto in 2001. Seventeen eminent thought leaders concluded the two-day long deliberation on better ways to execute software development with a sign-off on a brief document popularly known as “The Manifesto for Agile Software Development”.

This manifesto serves as a fertile ground for further research and a basis for modern-day Agile Project Management. In the ensuing years, this agile manifesto attracted the attention of global business leaders not only in the IT industry but also from other industries.

What is an Agile?Mindset?

Managers make business decisions at many levels. More than anything else, it’s the mindset, beliefs, and conviction of managers that set the vibes for the organization. It makes a difference when the decision-makers have agile mindset.

This is where the agile mindset comes into action. Agile manifesto helps decision-makers across all levels take key strategic and operational decisions.?

Let us see this in action below.

#1 Should we pay more emphasis on individuals and interactions or develop rock-solid systems and processes to guide decision-making in the organization??

This is an important strategic problem that has a far-reaching cultural impact. But before I share my experience, tell me one thing. Suppose you have no constraints on capital in a project, which one of the two would you bet on for success??

a. Best people who can figure out the nitty-gritty of the project and can steer it towards success.

b. Best processes and tools that have worked well across multiple projects and are regarded as the best in terms of reliability.

In my decade-long career in the operations and maintenance of large industrial plants, I have seen a lot of emphasis on systems, processes, and tools. In fact, they were a matter of pride and a key differentiator for one of my previous organization.

The same was the case in a fast pace garment manufacturing business. During most of my tenure, I focused on efforts to set systems to drive superior business results. In the hindsight, I see a mixed result of all those efforts. Ironically, proponents of processes and tools often take it too far. And I was no exception.

When my sampling output was falling apart, I introduced systems on paper and took detailed multi-layer briefings to align everyone from the shop floor to customer representatives. “We all are in this at the same time and suffering together because of poor output”, I would insist in these meetings. I allocated physical space and assigned designated persons to specific parts of the entire flow of work. Further, I introduced colored tags and sample bins for the movement and segregation of physical samples.

While I introduced these processes, I set up a parallel system to monitor its reliability and capture relevant data. After a couple of months of meticulous planning and iterative changes towards perfection, we could improve the sampling output. But six months down the line, when the focus shifted from sampling unit to a new production line dedicated to designing molds, slowly the attention feathered away.

When I try to evaluate this with an agile mindset, I realized that processes and tools need inherent show-stopping features. Processes on-air are often not binding. People bypass it intentionally or accidentally. Unfortunately, when one such incident happens, entropy overpowers the entire system. Then we lean back to the custodians of the system to keep it running. And who are these custodians — the managers, right?

I could have built-in such show-stopping features but it would have cost thousands of dollars. For example, an IT infrastructure to track the movement of goods in real-time would make it more robust. This system would capture the details of each sample at each step of manufacturing so that I could get end-to-end visibility.

But, would this system help the management gain better control of the process?

Probably not, for the variability and unpredictability of the samples in terms of types, processes and timings would remain intact. And such a complex operation would require a people-centric approach to handle it better.

How people-centric approach can improve the situation?

Years later, I realized that the variability is too much to handle. I pivoted towards the people to solve it. It is not a simple thing, though. (Rather harder and that’s why traditional decision-making thought processes keep it in a back seat.)

First, let us understand the variability of samples. What was so unique in this situation was that no two samples were alike. Unless the team sees and discusses, it is difficult to zero in on a process with certainty. Worse, the process reliability was inherently very low. i.e. samples prepared from a process, when made again with the same process, would have some variance, which is often unacceptable to the customer.

I tried to reduce this variability with people’s intervention at all levels. I trained the customer-facing team to identify the complexity of the sample and take a call without wasting much time. It was always better to be truthful with the customers and collaborate with them in finding the best solution at minimum cost so that value is created for both parties. But it was not so easy. There are functional priorities that need to be handled to ride over the tide of pushbacks. Again the agile thinking helps.

I motivated the team to upskill to manage complex samples. Learning and development and onboarding external talent helped in this. I started a parallel line of talent development for dedicated R&D on sampling. Slowly, we were accepting samples that were deemed implausible a year ago.

Third, I empowered the team to make prioritization decisions. Neither first in first out (FIFO) nor last in first out (LIFO) rather a complex mix of these two was the need of the business. Each sample bears a price tag for potential business, which is the hidden driver of priority. The catch here was how to agree upon a real price tag? Functional departments may inflate these numbers anytime, for they are the source of this truth. Verification could only be possible in the hindsight. So when I empowered the team, they developed mutual trust, and over time, the backend team could assess the “truthfulness” of price tags on a case-to-case basis.

The result of the people-centric approach was much better for many reasons. By taking this route to solve the problem, I trusted the people involved (end to end) to work together to create value. In effect, it helped them see the limitations of any system and processes and take genuine effort to keep it running.

Why are we so obsessed with Processes and?Tools??

First, I do not see any fault in this thinking except that often managers trespass on its utility.

At the subconscious level, managers think that what we cannot measure, we cannot improve. So, in our pursuit to measure everything, we subconsciously lean upon (or prefer) all those which are measurable. We can measure systems and processes for their capability and reliability so, why not prefer them over their human counterpart?

This industrial thinking worked well for centuries because the intended tasks were simpler. Processes could have been developed with great reliability to perform the same task repeatedly. Think about the line production system, where each substation needs to do a specific task on a specific workpiece. The complexity and the challenges are limited. It is much easier to work in such a bounded environment.

But are our modern industrial systems so simplistic as these? Probably not.

The agile mindset pushes us to question our thought processes. Can we rely on people and their interpersonal interactions for better results? Can we trust the team and empower them to self-organize and act in the best interest of the organization? And maturing a notch higher, can we decide upon our preferences based on organizational specific needs and strike a balance?

#2 Should we follow the plan or respond to?changes?

Leave apart the question of willingness, responding to change may not always be technically workable. True, but who is best positioned to decide this feasibility — the customer or the developer? Undoubtedly, it is the developers.

There are two ways to think about this deadlock. The traditional way and the agile way. While the former would take a retrospective view and focus on the additional effort required to fulfill the request, the latter would take a collaborative view and evaluate the possibilities of creating a win-win.

Agile minds would not simply accept anything and everything. But they will not outrightly reject the requests either. The essence is in working collaboratively and figuring out a solution that leads to value creation. Once there is a scope of creation of a bigger pie, why not make it together?

#3 Should we negotiate hard on terms and conditions or collaborate with customers to create a bigger?pie?

Negotiation is the hallmark of certain relationships. Amongst such relations is the one between a supplier and a customer. How can there be an iota of collaboration ever?

Not so in the traditional setting, but the rules of the game changes as soon as we navigate out of the paradigm of industrial works and deal with knowledge works. In the new paradigm, it is in the best interest of both the party to collaborate — Game Theory kicks in!

Ambiguity and flexibility of the intended objectives characterize knowledge work. Often the stakeholders themselves have a difference of understanding about the desired goals.

It would not be an exaggeration to say that the exact requirements of a knowledge work project remain unknown until much of the project is over. The stakeholders operate with a “gulf of evaluation” in their mind and they trust each other and collaborate to move ahead and bridge that gulf.

In such a situation, both parties have high stakes and neither can escape. Success would add distinctions to their caps and failure would be equally painful. So, let’s collaborate.

In operations, it happens all the time. When a customer mistakenly orders something that its end-user did not require, then the customer seeks help. Rarely, the supplier would refuse to collaborate, for the future of business is at stake. Therefore, in such cases, they discuss the case in greater detail (from end to end) to make sure that they (customer and supplier pair) do not commit the same mistake again.

Wouldn’t it have been better for the parties— end-users, the customer, and the supplier— to collaborate by default to create better solutions?

#4 Should we care more about the working software (business outcomes) rather than on the reports and documentation?

Reports and documentation are great. They help fill the database for future reference. Some organizations care about such repositories of knowledge. However, in most others, the execution models — artifacts that helped in producing the desired results — are short-lived.

In a Knowledge work project, ideas need to be conveyed from one person to another, often to the entire team, so that it gets refined for better outcomes. But while doing so, the team remains focused on the desired result, i.e. to create working software, to launch a marketing campaign, or to create a killing improvement in the recent design project.

In operations, often we invest in sophisticated tools and capture data at the minutest detailed level. It is as if we try to create a black box for the organization where anything and everything gets recorded for a diagnosis in case something goes wrong.

But does this diagnosis help in offsetting the damage already committed? Agile teams, therefore, keep the documentation to a bare minimum with an eye on the evolving business needs. If something is essential for business continuity, keep it. Rest all the time, focus on delivering the key result.

?Conclusion

In a world, where the customer’s requirements are increasingly complex and dynamic, embracing an agile mindset helps. The key is to develop an instinct of trusting a capable team and empowering them to discover ways to collaborate not only amongst themselves but also with the customers to create lasting value.?

At Edzest, we help our clients identify ways to inherit an agile mindset for real tangible business impact. For details reach out to us at [email protected].