What value do you think being agile will bring you?
- Jasper Bogers
- 30 okt 2021
- 3 minuten om te lezen
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.
Comments