As I read through Tom Grant’s article on Agile Frameworks, one word kept jumping out at me: structure! People like frameworks because they provide a structure that is repeatable.
As I think back to all the Agile deployments I have dealt with, there were many misconceptions about Agile but the one that was consistent was that Agile did not have structure. Many managers who asked for Agile to be implemented had the idea that being Agile meant that you didn’t have to do many of the things that they were doing with the other software development process they were using. Managers focused on the literal meaning of the word Agile and had misconceptions that Agile would magically help them deliver software faster. The 3 most common Agile misconceptions and illusions I encountered were:
- Documentation is optional because it gets in the way of writing the code.
- You are allowed to change your mind frequently when doing Agile, so you really don’t care about technical debt. Change your mind as frequently as you want, and throw caution to the wind when it comes to the code.
- Efficiency will magically happen by just being Agile. Figuring out what needs to be built is instantly clearer; writing a line of code will be easier; executing a test just happens faster.
Of course these misconceptions and illusions about Agile were the farthest thing from the truth. The people on The Team understood this, but once you got beyond the team into other departments, this is what they thought. These other departments tolerated Agile when it was just one team that was doing Agile. However, as Agile spread across the entire organization, the question of Agile not being structured was now at the forefront of other departments like finance, PMO, and accounting.
Agile was now mainstream and these other departments required structure. They required controls, measurements, and definable deliverables. The auditors of the organization struggled to understand how they could audit an Agile project. There didn’t seem to be structure and it was just too “loosey goosey”.
One question that other departments, like the PMO and the auditors ask is, “How do you manage risk in Agile?” The idea that a self-organized team can manage risk runs against their core assumptions. People outside the team, who studied and worried about risk full-time, required the team to comply with risk-reducing measures, such as sticking to pre-defined milestones, and cleaving to well-documented deliverables. They had a hard time seeing and understanding that Agile was actually managing risk on a daily basis through scrums, acceptance criteria, and on a sprint basis through planning, estimating, reviews and retrospectives.
Why Agile Frameworks?
Agile frameworks are an attempt at trying to define a standard recipe that can be followed by each team in an organization. This recipe comes pre-defined with controls and deliverables. This will help put a structure around Agile that other departments can understand. Since we have a pre-defined recipe, it can be replicated across all the teams in the organization because they will all work the same way.
At least this is what some people hope…
While using an Agile Framework will appease the people in Finance, PMO and Accounting, it will do little to ensure that everyone works in exactly the same way. Anybody that has tried to follow a recipe to cook a dish knows that having a list of ingredients and instructions is great but it is all in the execution of that recipe that determines if the dish is amazing or a disaster. What adds even more unknown to a recipe is the tools people have and how they use them.
As Tom Grant hinted in his article, the problem with the word “framework” is that people will interpret the word as it suits them. While we can say that a framework is not a methodology, inevitably these terms will get used interchangeably along with other terms like ALM. To a manager trying to solve a delivery problem, all these terms are just semantics. They want to implement a way of working that will be predictable, and deliver good quality code that delivers business value. Nothing more, nothing less!
Whether we call them frameworks, methodologies, or ALM, a predictable and structured approach to software development is not a new concept and has been around for decades. The software development landscape is littered with examples that supposedly had the magic recipe on how to deliver software predictably and with good quality.
Does everyone remember RUP, ISO, and CMM just to mention a few?
So why the push for an Agile Framework? Why would an Agile Framework do any better than what came before it?
The truth is, there is no framework that can guarantee the successful delivery of quality software. You can have the best framework but in the end, it will come down to the team that is executing the work.
And this is what Agile is all about, The Team!
In our rush to find the ideal Agile framework, let’s not forget the team. Take care of the team and the team will ensure that the right software is delivered at the right time to bring business value to your organization.
2016 Will Be the Year of the Agile Framework
The trends are clear, 2016 will be the year of the Agile Framework. As organizations have rushed into becoming Agile and started to hit the wall when it comes to fusing Agile into the corporate mentality, the need for a framework has arisen.
Some of the most talked about frameworks out there are SAFe, Nexus and DAD. There are others but these are the ones that are top of mind these days.
Will SAFe, Nexus or DAD answer the need of bringing a “perceived” structure to Agile that can be accepted by the other departments in an organization? Like all frameworks, for some organizations it will and for others it won’t because in the end it will depend on the teams executing the work. My advice to organizations is to put your faith in hiring talented people and supporting them to be successful. This is what makes any software process successful.
2016 Will Also Be the Year of Contradiction
As we debate Agile frameworks, there is another trend that seems to be counter intuitive to what Agile has been preaching during the last 15 years.
Some of the larger organizations have started talking about moving back to the days of using Centers of Excellence (CoE). When I hear about CoEs, it takes me back to the days of waterfall development where you had your centers of expertise (Development, Testing, BA) and these centers worked as separate units on delivering the software.
Why are these companies moving back to CoEs? The simple explanation I have come across so far is that these companies tried to implement Agile and it either failed or was only partially successful. Therefore, managers making the decisions are reverting back to what they understand best, which is using CoEs.
Has someone stopped to ask, “Why did we move away from CoEs in the first place?” Remember one of the reasons was that we wanted to avoid the working in silos and try to build team collaboration so that we can deliver quality software.
It seems that this original question is being ignored and these organizations are reverting back to something they know, even with the known limitations of CoEs.
Stop! — You Can Have Your CoE within Agile
What many organizations don’t realize is that you can have CoEs within Agile.
Why not have an Agile Testing Center of Excellence or an Agile Development Center of Excellence? This is especially true if an organization is planning to deploy Agile at scale, regardless of whether you use one of the frameworks (SAFe, Nexus, DAD, etc…) or not.
While Agile has called for the cross functional team to be at the core of Agile, I have seen in many teams that people still retain their core competency at heart. Sure the developer can and should help with testing, but at the end of the day, development is what he/she loves doing.
Therefore, you have the opportunity to establish a CoE within an Agile organization.
In my last engagement we established a QA Guild based on the concepts of the Spotify model. The concept was simple: you create cross functional teams but the various competencies retain a connection to their area of expertise (ex: QA). This connection to their area of competence provides a forum for the exchange of best practices, the usage of tools for test automation, the discussion of challenges faced by a particular team, and other important activities. We called this connection to their area of competence the guild, and people within the guild exchange information constantly but also meet once a month to discuss topics of interest in the area of competence. Just as in the days of guilds of master craftsmen who perfected their craft by exchanging ideas but worked separately.
To my mind the guild is the equivalent of your Center of Excellence. However, you are now getting the benefit of both worlds, Agile and CoE.
So Where Do We Go from Here?
Agile Frameworks may be necessary in various organizations so that other departments get what they demand in terms of controls and structure. Some organizations have started to explore using CoEs again to establish some of these controls and structure. However, you don’t have to give up Agile to get what organizations expect in terms of controls and structure.
You can get these controls and structure by establishing a guild within an Agile framework. By doing so you are also establishing what is called for in a CoE: sharing of best practices, tools, and ways of working.
My hope is that in our rush to add this extra Agile Framework layer on top of Agile teams, we don’t stop or detract teams from the original principles of Agile as laid out in the Agile Manifesto. These basic principles are the foundation of Agile, and we shouldn’t forget them.