In many of our recent engagements we have been working with our corporate members on their Agile Architecture @ Scale practice. This includes many of their developers and product owners. And while I expect all sorts of grumbling during such change, a few things have really stood out for me.
Teams have neither the skill nor time for proper agile finance methods
For agile to succeed it must include the financing portion. And yet I worry that the adoption of financing and value management methods in agile teams and budgeting are not fast enough. Organizations are struggling with workload and too few skilled people with deep technical and deep business skills, which are needed for this type of task.
“Which is more valuable? The left front wheel or the right front wheel of a car?” Mike Cohn
This may be one of the biggest areas where agile needs to get better for it to truly work and become the de facto business method that it needs to be. The problems I am hearing depend on the following possible reasons/opportunities:
- Prioritization methods require the use of value methods for both business and technical epics/themes, but we focus on the functionality only;
- Finance, HR and shared functions do not fit as easily in an agile team setting as IT services do;
- Cross team structural elements in technology (the roadmap) do not get prioritized at the point where they need to be; and
- The technology team does not have a technical product owner to match the business product owners reducing their effectiveness across teams (teams become order takers).
The skill levels for working agile at scale are out of reach for organizations
The elephant in every room is the lack of the truly qualified technology staff necessary to make agile truly work, or IT in general for that matter. Recently, Satya Nadella said that by 2030 there would be a million open development jobs. And I don’t see training budgets scaling to meet the demand. We have a hard time finding people who are qualified to write code. How do we find people who can truly reason about the business impact of that code? I have been training and working with architects for many years and I find it ludicrous that we are still trying to fix things with process and technology. The IT sector is going to have to grow new ways of getting the people it needs to succeed.
Add to this the difficulty in trying to create more and more multi-skilled people who must know a little of everything, which is an inherently flawed model for human learning and skill deployment in a complex ecosystem. Humans take an extremely long time to form the skills necessary to do complex things like algorithms and technology. Requiring each of them to become multi-disciplinary would be like asking a nurse to do surgery after reading a short book on it. Even if he has been assisting surgeries for years, they mind doesn’t learn that way. We need instead to be more rigorous in our understanding of role interactions, consults and specializations before things will get better.
To be a little more incendiary, I find it ludicrous that we have such a hard time making something reasonably simple like a new methodology like agile work in our field. If we ran construction and medicine this way, we would have crumbling buildings and would be extremely scared to go to the hospital.
As an aside, this possibly leads to ‘citizen developers’, which if you ask me sounds a lot like MS Access at scale. This scares the hell out of me as an architect.
The focus on velocity as the primary business outcome is misguided
Move fast and break things is all well and good when you are trying to motivate people to break out of the mold and be innovative. We need more of that. But velocity in delivery has become the new idol we all worship. I give the following as an example of why it isn’t that important in my classes.
“Your company has $100,000 to invest in a marketing campaign. They go through a solid analysis of marketing firms. The firms come back with prototypes and proposals and one is finally selected. The firm proposes different approaches and the executive team picks the one they like the most. The CEO dresses up like a lizard for a commercial and has a great time and everyone agrees it is great. What is more the vendor coming in both underbudget and early! The campaign goes live and 1 mo later the results are tallied, and the company saw negligible impact on net new leads or renewals. Was it successful?”
The clear outcome of this question is no, it was a horrible failure and a waste of money. But in IT we would say that we were successful because we beat the timeline and launched without failure. This lasting remnant of technology, as order takers with no “skin in the game,” is where most of agile is failing. We are not focused on outcomes still but on velocity. In addition, structural issues like quality attributes are not getting the kind of focus they need across teams. I fear this combination will lead to the organization pushing back on Agile as a concept.
The inability and unwillingness to prioritize architecturally relevant themes and epics
Much of Iasa’s research and my own fascination lies in what makes something valuable. Is this epic important and how important and how do we know that? Is security more important in this area or that? Does this feature impact our customers and how? What we collectively call value methods in the ITABoK constitute one of the key skills of an architect and is one of the big differentiators in my mind between an architect and a purely technical role like developer. I, laughingly, tell my students and my teams, “if you don’t love excel and survey analysis, you might not like being an architect.” But the truth is we in technology have only the beginning of an understanding of how to value technology contribution to value. We have a huge body of knowledge to build here. One of my favorite tools for this is the Business Dependency Network from Cranfield. Here is the Iasa canvas for doing a BDN.
https://itabok.iasaglobal.org/itabok3_0/valuation/
This tool allows you to connect architecturally relevant user stories and epics to business outcomes with measures. You can find more about how to use this tool in our Core, Solution and Business Architecture classes.
No matter the method, human nature isn’t changing anytime soon
We have a tendency to try to make people fit methods instead of making methods fit people. All humans have cognitive biases, have some reticence toward change, and take time to learn new concepts. Some humans are greedy and power hungry and sadly they are the ones that seek power most often. So how does a method that promotes transparency in decisions, distributed decision making, and reduced power focuses succeed? The answer is you must counterbalance people with working methods and environments that are very difficult to combat. But that process takes time and many other factors must be in place to make it work. This is a topic for another blog post. However, it is one that Iasa and I am deeply committed to battling.
“Much of Agile @ Scale (SAFe and others) is looking a lot like waterfall with new names”
I included this quote from the chief architect of a major healthcare company because it captures the sentiment I am discussing. Notably, this person is a huge agile fan and has helped many organizations move to more innovative and team-based environments. But I worry that this sentiment is growing and will result in a significant pushback to centralization and hierarchical methods. What are your thoughts?
