Leadership 4.0: Agility Required

Industry 4.0 is about agility. Leadership 4.0 will require that same mindset.

I have come to the conclusion that Industry 4.0 is a reflection of the Agile model of software development. I can’t prove it. But so much of industry 4.0 is built on the Agile methodology that my gut tells me it permeates the organizations. In addition, over and over again in the literature of Industry 4.0, the term Agile pops up. As a side note, I also believe it to be a reflection of Chaos Theory and Complex Adaptive Systems, but that’s a whole other set of posts!

So let’s begin our look at Leadership 4.0 with a another primer. A primer on the methodology called Agile!

Agile History

In the 1990’s, software development faced a bit of a crisis. Referred to as ‘the application development crisis’ or ‘application delivery lag’, the industry realized that it couldn’t move fast enough to meet customer demands and requirements—the estimated time between a business need and actual application was about three years. See, traditional development models were based on a timeline approach, where development happened sequentially and the final product wasn’t revealed to customers until the very final step. This left little room for flexibility when it came to progress reviews and changes. So, by the time an actual application was finished, it was highly likely that requirements and systems of the project’s original objectives had changed.

With money and efforts wasted, and even some projects cancelled halfway through, professional leaders of the software community thought it was time for a new, refreshed approach. Then in 2001, in a snowy, ski lodge in Utah, 17 individuals gathered to see what they could come up with. Some of these leaders were already entertaining the idea of a new software development method. They wanted to develop a process that reflected and even legitimized what was being practiced. From that meeting came the Agile Manifesto.

What is the Agile Manifesto?

The Agile Manifesto is a declaration of the values and principles expressed in Agile methodology. Made up of four foundational values and 12 key principles, it aims to help uncover better ways of developing software by providing a clear and measurable structure that promotes iterative development, team collaboration, and change recognition. One thing that separates Agile from other approaches to software development is that the focus is on the people doing the work. There is also a focus on how they work together. In an Agile methodology, solutions evolve through collaboration between self-organizing, cross-functional teams utilizing the appropriate practices for their context.

Now, that doesn’t mean that there aren’t managers; there is still a place for the manager role. It just means that teams have the ability to figure out how they’re going to approach things on their own. The manager’s role in an agile framework is to make sure team members have and practice the right skill sets needed for the task. Managers also create the environment that allows the team to be successful. They mostly step back and let their team figure out how they are going to deliver products, but they step in when the teams try but are unable to resolve issues, when resources are needed, or when the environment is not conducive to effective solution creation.

The teams are cross-functional. Team members have differing skill sets that enhance the overall function of the team. Those teams don’t have to have specific roles involved so much as that when you get the team together, you make sure that you have all the right skill sets on the team.¹

Now, let’s take a look at the values, which is where we will build on in the next post.

Values

1. Individuals and interactions over processes and tools – The most valuable resource in agile methodology is people, and because of that, the primary value of the framework is to value people more highly than processes or tools. People respond to business needs and people drive the development process. When the development is driven by the process or tools, then the team is less responsive to changes and less likely to meet customer needs.²
2. Working software over comprehensive documentation – Historically, enormous amounts of time were spent on documenting the product for development and ultimate delivery. In my early days of software development, even when working for startups, where we were flying by the seat of our pants, documentation was primary. And it took a long time. It was minutiae work and I hated it. And it was the cause for the long delays in development. Agile does not eliminate documentation, but it streamlines it in a form that gives the developer what is needed to do the work without getting bogged down in minutiae. Agile documents requirements as user stories, which are sufficient for a software developer to begin the task of building a new function.³
3. Customer collaboration over contract negotiation – The agile philosophy dedicates a great deal of customer-centric product development practices over product-centric approaches. While contracts will always have their place in business, a list of the things you’re offering your customer is no replacement for actually communicating with them about what their needs are and where their challenges are. “Customer collaboration begins early in the development process and happens frequently throughout. This culture of close collaboration with real customers helps product people ensure they’re delivering effective, useful solutions to customers. When you talk to customers often and build feedback into your development process, you reduce risk and eliminate guesswork.”⁴
4. Responding to change over following a plan – “An important benefit of the agile methodology is that it encourages frequent reviewing and retooling of current plans based on new information that the team is continually gathering and analyzing.”⁵ (Hint: this is one reason I believe it is a reflection of Chaos Theory.) The product roadmap, for instance, no longer remains a static document, “but a dynamic strategy. Product managers in agile environments will need to learn to present their dynamic roadmaps to stakeholders in a transparent manner that reflects the likelihood of change based on new learnings.”⁶ At it’s core, the agile methodology “lets a product team adjust its priorities and plans whenever doing so makes strategic sense. These teams do not get stuck in an outdated plan simply because they have committed to seeing it through.”⁷

Principles

1. Customer satisfaction through early and continuous software delivery
2. Accommodate changing requirements throughout the development process
3. Frequent delivery of working software
4. Collaboration between the business stakeholders and developers throughout the project
5. Support, trust, and motivate the people involved
6. Enable face-to-face interactions
7. Working software is the primary measure of progress
8. Agile processes to support a consistent development pace
9. Attention to technical detail and design enhances agility
10. Simplicity
11. Self-organizing teams encourage great architectures, requirements, and designs
12. Regular reflections on how to become more effective

Now when you move this framework out of software development and into industry as a whole, you begin to see the need for a new type of leadership that supports the chaotic change that is occurring. This requires a leadership that is highly relational, has a high degree of trust (which requires a high-character team) , is responsive to change (and doesn’t let the anxiety of change hamper their ability to respond), is flexible, and allows for a bit of mystery.

Our next post will go deeper into the practices of Leadership 4.0.

NOTES:

1. Agile 101.  https://www.agilealliance.org/agile101/
2. 4 Values of the Agile Manifesto and 12 Agile Principles Easily Explained. https://medium.com/hygger-io/4-values-of-the-agile-manifesto-and-12-agile-principles-easily-explained-84cd429f69f
3. Comprehensive Guide to the Agile Manifesto. https://www.smartsheet.com/comprehensive-guide-values-principles-agile-manifesto
4. Agile Values. https://www.productplan.com/glossary/agile-values/
5. Ibid.
6. Ibid.
7. Ibid.