Here are my thoughts on some of the recent doubts I’ve had as someone who is usually a change agent and agile evangelist in some capacity or other.
These are questions you can ask yourself as an agile coach, as a sociotechnical delivery consultant, as an architect, as a developer, as a development manager, as an HR manager, and really as any person who plays a part in an organization’s efforts to deliver on its mission statement.
How people solve problems and what problems to solve
I mention Scrum several times in this article, only because it's a popular and easy to wield instrument to achieve agility. But it's not about Scrum. It's about the fact that its successful implementation rests on an important premise: When you do try to introduce thoughts and practices that can lead to agility, even just Scrum at team level, have you asked yourself what problems you expect agility will solve?
Any agile consultant can quote the Scrum guide and say “it allows you to inspect and adapt”, but the simplicity hides the important fact that adapt means a lot. Were you brave enough in questioning what variables are considered off-limits? Conway’s Law may be in effect when parts of an organization’s configuration are implicitly or explicitly considered to be exempt from change in an agile consultant’s evaluation assignment. Are you aware of any such confines? If they're the fibers of what makes your company what it is, if they're part of the comfortable way of working of your colleagues, then is your vision of the value of agility prevalent enough to counter that looming discomfort?
Scrum teams can be a good idea. But are people divided into sensible teams in the first place? Were they involved in the way the problem domain is identified and cut up? Are they equipped to explore and test solutions to complex problems or were they hired as subject matter experts to predefined solutions under the assumption your problems are simple? DDD and Cynefin may offer insights here that may preclude the team makeup, solution approach and even whether Scrum is the best way of working for a team and for them to become more agile.
If your problem is indeed simple and the solution and its planned implementation are set in stone, it may be better to invest in proper specs rather than in an iterative development process that seeks to uncover and meet new and unknown requirements.
How solutions affect people
When you did decide to deliver artifacts in increments, did you think about making sure stakeholders are able and available to inspect those, and what it might mean in terms of redesign and budget reallocation if their feedback suggests you need to pivot or abandon your plans?
When it turns out the major impediment people face is waiting for management approval for the sake of command and control, is management — are you — willing to let go or become more involved?
Asking an agile coach to “help my teams adopt Scrum” may turn out to mean “help me get out of the way of my agile teams”.
“Help my teams deliver more value” may translate to “stop me from forcing my staff to use cumbersome enterprise tooling just because its price seemed like a bargain for the features it offers”.
“Help my teams collaborate more effectively” may entail “renegotiate SLAs with external parties so their involvement aligns with that of your internal teams”.
As a reminder: here are the original agile manifesto and its underlying principles. Is any of that advice you’re prepared to follow up on? If so, why? If not, why not?
Based on my original article on Medium.