As my company has grown over the last few years, I’ve had to hire (and let/seen go) a fair number of people. We’ve interviewed dozens of candidates. One of the most challenging things we find is in hiring people with the right culture fit. Agile is one of those cultures that unfortunately comes with many hidden implications I’d like to discuss in this post.
Why do we do agile?
Most software development professionals, whether it’s developers or managers (PO’s) these days use what they think is “agile methodology”. They know about working in sprints, Scrum, backlogs, stories, sprint goals, retros, etc. In a practical sense, they use agile but when asked, they don’t actually understand why.
In interviews I’ve asked people, “Why do we use agile?”
I’ve yet to get a satisfactory response. Some say “Because it’s not waterfall, waterfall is bad.” Or, “Agile is just better.” (Ok, but why do we use it?)
The reason for using agile is that creating software is so complex that there are more unknowns than there are knowns. Agile shortens the product development cycle into small increments that can be used so that real requirements emerge. The project evolves over time.
What is agile then?
At the core of agile is embracing that everything is ambiguous (and that your hypotheses and assumptions potentially aren’t correct). In product development, there are more unknowns than there are known.
The main idea of agile is in working iteratively, incrementally and continuously. Each feedback loop enables you to check if you are delivering value.
While the term “agile” is most popular in software development, it is becoming more commonplace among organizations (see this and this). ArtStation is considered an agile organization with our own structure called Organiq (will write about it in another post).
Interestingly while reading Ray Dalio’s Principles, he illustrates the looping ascent in one’s career/life. One sets audacious goals, fails, learns from them, improves, then sets higher goals. I found that illustration apt to describing agile philosophy. Product development, companies, careers can all take this iterative, compounding philosophy.
What are the implications of agile for people?
The “experts” are actually those with an open mind who are willing to test assumptions
The main implication of agile is that you accept that there are more unknowns than known, and that your assumptions (perhaps based on your expertise & experience) might not be correct.
For staffing, this presents a landmine. We’ve hired people who get frustrated and leave because they’ve brought assumptions under the broad banner of “expertise & experience” that they are unwilling to yield on. In agile, that expertise & experience is a great starting point but the assumptions must be tested, validated, observed and measured. Some people just can’t take that kind of examination (and it’s ok, agile isn’t for everyone).
You might hire someone who has decades of industry experience. This person brings a wealth of knowledge and experience but is unwilling to have those assumptions tested. And when they are and the results are questioned, they get offended and ask “Why did you hire me for my expertise if you’re going to allow other non-experts in the organization to scrutinize it?” It’s a great question, and it’s why agile is not for everyone. From my experience, the real experts are the ones who balance their expertise with the mindset that their assumptions (based on their experience) might not be completely correct under the present circumstances and are willing to test that.
If you have key people in your organization who are not willing to test and challenge their own assumptions, it is a sign that they haven’t embraced agile or maybe they just aren’t of that mindset. Agile is very challenging in this respect. You can have very experienced, senior people who have a title and position, and if they are trying to assert authority with those things, it creates tension in what is otherwise supposed to be a fluid, learning environment.
Titles & positions become tenuous – this is a problem
Therefore, because agile is a learning environment where you’re constantly testing hypotheses & assumptions, it becomes challenging to hide behind titles, positions and broad expressions of expertise and experience. Especially if you assert authority with those things.
The issue is that common assumptions hold that the title or position of a person commands authority. For example, if you’re a designer, common wisdom dictates that you should not be challenged on design unless it’s by another designer, preferably more senior than you. If you’re a marketer, common wisdom dictates that you should not be challenged on marketing unless it’s by another marketer, preferably more senior than you. It’s exacerbated by the mistaken belief that agile is something that only engineers use, and is not something that should be applied to other disciplines. Scrum (at least the V1 of the Guide in 2013 and removed in newer versions) adds insult to injury by stating that “Scrum recognizes no titles” — a big problem for people who have worked hard in their chosen profession and earned their position & title, only to be challenged by others on the team who aren’t from that profession. How dare they!
This is a constant struggle. I find myself educating, and now being smart enough to not hire people who are after the title/position. Instead, I look for people who are open minded, humble and have a learning mindset. Even with experience, expertise and a good title, being able to say “This is what I think, but let’s test it and see what happens” is great. The whole organization benefits from having an agile mindset where everyone can learn.
I want to point out that generally having people who throw their weight around based on their title/position isn’t great anyway. Having someone say “I’m the [insert position/title] and you should do what I say” leads to tension in the team regardless of whether it’s agile or not. The point is that you want people who are humble enough to engage in healthy discourse and have an open mind. In Ray Dalio’s Principles, he puts forward the “idea meritocracy”, which is an environment where the best ideas win. The best ideas are determined by the quantity and quality of empirical data, not by positional power or title. In any case, this is challenging for many.
Scrum: You are delivering small increments to test in the market instead of a blockbuster release (though you can marry the two)
When working in Scrum, each sprint is essentially a timeboxed feedback loop. That’s why it’s important to try to deliver a working increment and get feedback from users and stakeholders.
More often, I see people’s understanding of Scrum to mean that they are phasing delivery in sprints but essentially it is still a big waterfall. E.g. having a UI design sprint, technical design sprint, implementation sprint, testing sprint, deployment sprint. This misses the opportunity for each sprint to be a feedback loop. This is just a phased waterfall.
The main benefit of agile is to be able to deliver small increments to users and stakeholders, get feedback, and keep iterating until you have something that is generally accepted (and delivering value). It is said to be iterative, incremental and evolutionary.
This does have implications for marketing and “when do you actually release?” What we try to do is to have features tested with subsets of users, get feedback and iterate quickly sprint to sprint until we get to a general availability. When everyone has access to the feature, that is the blockbuster release where we do the announcement and fanfare.
The pace is quite fast – too fast for some
When working with agile, the pace of release is intentionally quick. You’re getting increments in front of stakeholders quickly to get feedback and continuing to iterate. This can feel unnatural for people who are used to bundling releases over months and doing a big drop to users.
It is challenging to get the team’s mindset into the rhythm of just getting an increment in front of stakeholders to get feedback quickly. The natural tendency is to polish the feature until it feels “ready”. To our above point about actually releasing though – it’s not necessary to release the feature to everyone on production. The point is to get something in front of users so that they can test it, and get the feedback to continue iterating. For some features that we’ve done, that’s meant bringing users/customers to sprint reviews to get feedback directly, even though the feature is only on a review/dev server.
Is Waterfall Bad?
You know, it’s funny. When I chat with people, the understanding is that “Waterfall is bad”, but when you dig in, they are using waterfall themselves by phasing Scrum. They don’t understand the real reason behind taking an iterative, agile approach to product development.
I personally don’t think that a waterfall or phased approach to a project is inherently bad. Especially if it’s a short timeframe. In some cases waterfall is just the most appropriate way to do something.
In software product development, waterfall is problematic when the release cycle takes so long and has so much effort exerted that it risks missing the mark. The longer you spend without releasing to users, the more risk you layer on. You could spend months working on a release and get it out only to find that it does not completely solve the problem. The whole point of agile is to slice it up into smaller increments, deliver early, and with each delivery discover the real requirements based on actual usage of the product.
Closing thoughts
That’s some thoughts on agile, why (when it’s appropriate) to use agile, and its effects on people in an agile organization. I think that most people want to be agile, but in practice, the mindset change and its implications are too much to handle. I don’t believe that agile is for everyone. The problem I feel is that many organizations pay lip service to agile. They want to advertise themselves as agile, but when it comes to it, are still running fairly rigid phased processes with traditional power structures based on title & position.
Leo
