After witnessing years of both large and small companies grappling with the challenges of implementing the Agile software development methodology—acknowledging its potential for improvement or even considering it a failure—the original creators of Agile have taken the initiative to revisit and enhance the methodology. In today’s exploration, we delve into the core values of Agile 2.0 to assess whether this evolved system addresses the inherent instabilities and shortcomings of the original Agile framework.
In the article Reflecting on Agile Manifesto Principles, we’ve looked at the original Agile values, and will not be repeating them. Generally speaking, the main flaws of the original Agile were, for the most part, rooted in ambiguity and a lack of a common and consistent understanding of its values. The values themselves weren’t flawed; rather, it was the way they were interpreted that proved inconsistent, incorrect, and sometimes completely different from their original meaning.
On the other hand, the values weren’t sufficient to cover the full spectrum of software development challenges, necessitating specific approaches to their processes. This gap led to creative but not always successful deviations from Agile as teams devised their own methods to enhance their workflows
Well, did Agile 2 learn the good old Agile (1) lessons? Is it ready to rock our world with a fresh perspective that works better? At least the Agile 2 creators feel that these values are a better foundation for true agility.
Let’s take a look.
1. Thoughtfulness and prescription.
Original Meaning: Thoughtfulness means considering context, and taking action only after one has attempted to understand the situation. Prescription means following predefined steps, as in a framework, unchanged and not tailored to the situation, without necessarily understanding or being thoughtful about those steps or what they are for.
Our Thoughts
The very first value and I am already confused. From the outset, while the part about thoughtfulness is relatively clear, it still leaves ample room for misguided action. What raises concerns is the phrase “taking action only after one has attempted to understand the situation“. An attempt is not a conclusive action; we can attempt many things in our minds, fail, and move on without further consideration. The value of thoughtfulness seems diminished if we merely “attempt” to understand the situation. What if we don’t? Should we blindly take action without clarity on our direction, purpose, and approach?
In situations that are costly from various perspectives—financially and in terms of timing for the right opportunity—this approach may lead to more uncertain and unverified actions where we “attempted but didn’t reach” a clear understanding of the situation.
The prescription aspect of this statement is equally confusing and doesn’t align with agile principles. It appears that we are expected to “follow predefined steps, …unchanged and not tailored to the situation, without …being thoughtful about those steps.” How is this prescription agile? How is it adaptable? Did the authors mean that we should be “aware” of the prescription without thoughtfulness? Do they still recommend prescription? Or did they intend to convey that there should be no prescription if there is no thoughtfulness? The last interpretation makes the most sense, but why is the prescription still a part of this particular value then?
How would we phrase it
Thoughtfulness and flexibility.
Thoughtfulness means considering context, and taking action only after clearly understanding the situation. Flexibility means following an agreed-upon framework that serves the particular team and product, clearly understanding and being thoughtful about specific steps or what they are for. Revisit the framework to adjust and tailor it to enhance the process.
2. Outcomes and outputs.
Original Meaning: Outcomes mean the direct and indirect end results that occur after one has taken action. Outputs refer to what is directly produced by an action: for example, working software is the output of a programming task. Outcomes require outputs, and both matter; but outcomes are what matter most.
Our Thoughts and How would we phrase it
It seems like there is some confusion in this statement as well. In our best understanding, the outputs are the result of the specific action, and the outcomes are shaped by the interplay of outputs and external factors. They represent the broader and longer-term impact of actions. So, this would be our explanation of the value:
Outcomes over outputs
The outputs are the immediate results of the specific actions, and the outcomes are shaped by the interplay of outputs and external factors, capturing the holistic consequences of those results over time. Outcomes require outputs, and both matter, but outcomes are what matter most.
Side note: why is this statement needed, isn’t it self explanatory that the outcome is always more important?
3. Individuals and teams.
Original Meaning: Individuals and their differences are important, and should never be forgotten: people are not the team that they belong to. Teams are important, and team spirit is important, and making agreements and compromises for the benefit of one’s team is important. But team interests and individual interests should be in balance: one is not more important than the other in an absolute sense.
Our Thoughts
I like that. It’s a valid and crucial statement, and I’m glad it’s part of Agile 2 in this form. I’m not sure I would change anything about it, except maybe add some guidance on how to implement its principles…
No need to rephrase.
4. Business understanding and technical understanding.
Original Meaning: Technology personnel need to take an interest in business issues, and business personnel need to take an interest in technology issues. Neither should say, “I don’t need to know that.” Today, a holistic understanding of technology and business is necessary.
Our Thoughts
Timely observation indeed! Unfortunately, for many products, this realization comes too late. However, merely showing interest in each other’s sphere of influence is far from sufficient. It underscores a crucial point in adopting a holistic conceptual approach to product development. This involves not only the collaborative development process where business and technology are united but also ensuring that both business and execution possess sufficient knowledge from their counterparts. This synergy allows for the best decisions to be made for the product’s future and the optimal realization of its value.
In our rapidly evolving, technology-driven world, Product development leaders have long been enhancing their business knowledge and skills. Now, it’s time for business leaders to acquire a necessary level of technological education. This ensures that both can be accountable for their decisions while having a shared understanding of what they are collectively creating and fostering effective communication by speaking the same language
How would we phrase it
Business and Technology Conceptual Collaboration
Technology and business must share a common high-level conceptual vision of both business tasks and technological solutions to achieve those tasks with working software. Today, a holistic understanding of both technology and business is essential.
5. Individual empowerment and good leadership.
Original Meaning: Individuals need to have agency: they need to be allowed to decide how to perform their own work, and they need to be given the opportunity to innovate and express new ideas and take chances to try those ideas. By so doing, they exercise personal leadership. Leaders of others need to empower those they lead, but they also need to assess how much freedom those can handle, and position them for growth.
Our Thoughts
We understand that this is more about leadership and clarifies the self-organization of the team and process that was emphasized in Agile 1. I am not buying it. Here’s why.
I disagree that each individual has to be allowed to decide how to perform their work. I am not sure if Agile 2 creators understand what they are saying here. If every single individual is allowed to decide how they perform their work, there would be anarchy. This statement is too broad. And the following passage about the innovation neither elaborates on it, nor helps.
Yes, everyone need to “be given the opportunity to innovate and express new ideas and take chances to try those ideas“. But autonomy in individual approaches to work may only possibly exist within the agreed-upon team processes and variables, established company framework, and guidelines. And innovation should also be properly processed and tested because too much or even just enough non-validated innovation will disrupt the process, sending teams back if the changes have enough impact.
And here comes the leadership. And I am kind of upset that it’s not accompanied with the word “servant.” There can not be “bad” leadership. Leadership is like the freshness of a fish. As Mikhail Bulgakov said about it, a fish can never be past its prime. It’s either fresh (in its prime) or it’s rotten. So is leadership. It’s either “good” or it’s nonexistent.
How would we phrase it
Individual empowerment and servant leadership
Individuals need to be allowed to decide how to perform their own work if it goes along with the established team agreements and company guidelines. Everyone needs to be given the opportunity to propose innovations, express new ideas, and take chances to validate those ideas. If successful, they can propose them for adoption. Servant leadership will facilitate effective processes, inspire collaboration and innovative thinking, and always remain a personal and professional example. Servant leaders always support growth – in the first place, of the people around them.
6. Adaptability and planning.
Original Meaning: Adaptability means expecting that plans need to change, and being prepared to revise plans. Planning is important because plans set direction for action, and they represent thought about what the best direction is.
Our Thoughts
True. But I would still add that there should be a validated reason for change. Because without this validity, there will be chaos. (We have described those scenarios in Stakeholder’s Guide: Navigating Changes in Product Scope Without Breaking the Camel’s Back).
How would we phrase
Planning and Adaptability
Planning is important because plans set direction for action, and they represent thought about what the best direction is. Adaptability means expecting that plans may need to change, and being prepared to revise plans with validated reasons.
So, here it is. The new Agile 2.0 Manifesto, as we in Backlogical see it. What do you think? Do you agree with our corrections and reinterpretations?
No responses yet