I keep running into software developers on teams that are jaded and disillusioned about how their company has set themselves up to be "agile".
But is agile development really the problem, or is it more how the industry has sold it to us?
John Cutler joins me as a guest on my YouTube channel where we discuss the current skepticism around agile development in the software industry.
He writes many popular articles on Medium as part of the Hacker Noon publication, and helps companies with Product Management and improving software development outcomes.
John brings up the fact that there is an agile/devops industrial complex of sorts with its own agenda that might not always provide the best solution for your unique situation.
It can be easy to get caught up in this complex, and forget to ask the important question:
"What's really working today"?
📺 Watch the full interview on YouTube
Or listen as a podcast:
🎧 Soundcloud
🔔 Subscribe for 90+ videos on healthy software development
Top comments (6)
John, you are right, it really depends on who's in driving seat and for what reasons.
Last 7-8 years I've personally only experienced "agile" when implemented to benefit management only and it's been really more vehicle for them to get easy reports on progress.
We ran with agile-like process starting around two years ago, and we really got to this extremely well oiled factory setup, I was happy and proud, because my team was getting things done, on time, with testing and fixes all baked into the process, making managers happy.
Unfortunately it was all designed around no-one wanting to spend "quality time" with developers and answer all these annoying questions about what suppose to be built exactly in all these corner cases, and instead hoping to have 1-2 quick meetings every 5-6 weeks and makes sure there's paper-trail of developers "doing something... anything" for the time they were paid for.
It really takes transparency, understanding and involvement of all levels and aspects of any company to make the most these principles.
Totally agree and see this happen too often.
First people incorrectly equate agility (the ability to change) to scrum, kanban, or some other small batch method for building software.
Someone told them they’ll get work done faster.
They notice scrum (or kanban) has more frequent checkpoints (stage transitions) than waterfall because of the small batches.
Finally they make the critical mistake here and think small batches are something that primarily benefits measuring and forecasting.
Accountability every release? Yay!
In reality using small batches makes it harder to forecast which is why that’s not the point of it!
The point of small batches is to make changing direction easier.
As soon as the focus is on measuring, the team is actually dissuaded from changing.
People become motivated to make the actual time reported to complete work follow their predictions.
They are also motivated to build what was forecasted for future sprints and not to modify the backlog based on feedback (don’t upset prior commitments to scope!).
If they’re going to do that they’re better off with waterfall.
Just my opinions ;)
How is what working defined? I’ve seen companies where they say, well the feature shipped so our agile is working. But how the feature released was such a mess
Well I’d say if you are calling it a mess it’s probably not working. Can you think of a single practice, or aspect of the last time you released software that didn’t go well? Maybe figuring out what you would do differently and then identifying who needs to approve that change or be impacted by it. Then get to know those people, and figure out what about your change will make their life easier. Get everyone on board and make that small change. When it’s successful - repeat. The improvements will go faster as you gain reputation for each incremental improvement.
Just one way that’s working for me, YMMV.
Well the devs know it’s not working but upper mgmt thinks it is because thinks are shipping
Were there any times where you were pressured to not follow a process or maybe compromise something with the code?
If so, is there anything you can teach some of the managers before your next project or sprint to get you support for doing it right going forward?