What makes the state of “agile” processes in modern software development so depressing is that actual agility is worthwhile and – if anybody were actually to adhere to actual agile project management principles – achievable. However, I’ve been through at least a dozen agile “transformations” over the past 20 years or so since XP kicked off this whole trend and they all end up going like this: management hires some “agile consultants” who don’t have much (or sometimes any) actual software development experience, so they see software development as sort of an assembly line process to optimize, Taylor style. Under that model, software developers are skilled (or semi-skilled) widget assemblers, and management creates tickets for the software developers to “assemble”. The agile consultant’s role, then, is to make that happen as fast as possible. Since it’s just a matter of assembling some “computer stuff”, every task is predictable: an experienced assembly line worker with one or two years of experience ought to be able to look at a widget/ticket and estimate +/- 5% exactly how many hours it should take to complete. Any widget/ticket that’s estimated > 1 day can be broken into multiple smaller tickets of < 1 day each. If this isn’t the case for any of the tickets, the whole model breaks down and, since we don’t want the model to break down, this must a priori be true: if one of the assembly line workers takes too long on a task, the fault must lie with the assembly line worker, because, the assumptions have already been established to be accurate.
Your reasons for why “Agile” isn’t working is the same for why “devops” isn’t working - the enterprise refuses to let go of fundamental practices and assumptions of Taylor work models where planning is centralized by a manager caste and concerns for individual contributors are mostly cast aside (Deming’s approach is the opposite and is what the Japanese auto makers used to improve quality and dominate the US auto market in a matter of a decade). Furthermore, a great deal of the places in a crisis (seriously, why go through an expensive transformation if you’re fine?) have lost most of their software craft and are culturally bankrupt to do much more than manage things and watch them fail. Execution on anything besides sales is missing completely while an offshore team or a bunch of engineers too tired / hungry / captive to protest their conditions are dragged through it all.
Most of the Agile coaches I think know this and just want their cash before these places sink (takes maybe 15 years, enough time for a decently long career), and if maybe one of these places is saved they can feel good. But really, I think the situation isn’t too different from what Mitt Romney’s private equity firm was accused of doing for decades (and anyone else in PE for that matter).
> Your reasons for why “Agile” isn’t working is the same for why “devops” isn’t working
Thank you. This brightens my day.
Far too many companies want to appear "up-to-date" with the "industry standard", so they rename their ops team as devops and call it a day. Maybe add some automation-focused reqs to justify the change.
Ops with some ansible and terraform sprinkled on top are still ops. Just call it ops.
Having tried to hire for a team that is focused on operations there’s a huge world out there full of engineers that have hid their head in the sand about configuration management, infrastructure as code, etc. They may have managed a lot of network devices, SANs, AD and Exchange clusters, etc. But devops really started within the software community fundamentally rather than the modern sysadmin one and there’s a lot of distinct differences in mentality that shows. This doesn’t mean one is better than another but if tou’re in the technology field it is imperative that you stay up to date on what’s going on even slightly adjacent to our respective fields. This has been lost on a lot of otherwise excellent sysadmins though, and for that reason alone I have to decline good engineers - attitude and perspective over a long career being unsuitable for the company I’m hiring for.
> But devops really started within the software community fundamentally rather than the modern sysadmin one and there’s a lot of distinct differences in mentality that shows.
That is true.
> and for that reason alone I have to decline good engineers
Ultimately, that's the right call. Once certain a way of thinking solidifies, it is very hard to change.
Indeed, it all breaks down because of the Taylorist approach. True agility would recognize that most of the time software is implementing a "business process", and that there are real benefits to being able to change the process outside of the software. There is also usually a chunk of "tacit knowledge" - how the workers actually implement the process differs from the official manual in ways that are not usually written down and that management don't know about (indeed usually insist that they are kept hidden, by punishing deviation from the written process while ignoring feedback).
Implementing a process in software overwrites the tacit knowledge that may have been keeping an unworkable process running.
One of the most spot-on comments I’ve read in a while.
I laughed out load when reading the part about talking to the actual / real users in the doc. We pretty much never do that, but by God, we’re doin’ agile, ya know.
Changing is hard. Pretending to change is much easier. And frequently the people in the organization high enough up to dole out rewards (promotions, bonuses, etc.) aren't sophisticated enough technically to tell the difference between real change and pretend change. So the incentives all run towards doing the pretend change, grabbing the rewards, and then leaving a mess behind for someone else to clean up later.
That's what makes documents like this useful -- they provide ways for those non-technical higher-ups to start distinguishing between the projects in their organization that are pretending to change, and those that are actually changing. Which (hopefully) will help them start pointing those incentives in the right direction.
You can become a "Certified ScrumMaster" after a few hours of training without active participation in developing software. That is a big part of the problem.
You make a good point about the consultants without experience and I think this document is working toward fixing it: make sure you ask the questions that ensure contractors (especially) demonstrate they have done this and know what they're doing, rather than relying 100% on the proposal.
Given the DoD's (and Government, FAR-governed) proposal process, it's exceptionally hard to get real proof that an organization knows what it is doing so language is really important. While not a guarantee, you can at least feel slightly better about a proposal that speaks the right language about these topics instead of parroting talking points that indicate less hands-on experience.
Agile vehicles at DHS and GSA have tried this but have yet to gain serious traction - I look forward to see how this evolves.
Ensuring you get the right folks on the ground / staffed AFTER the award is also part of the problem, but one step at a time!
Each time I hear something about breaking down tickets to things that can be done < 1 day you end up with an unorganized pile of tasks, that someone thought must be done in a short amount of time.
Usually this happens in stark contrast to the lack of a prioritized list of (meaningful, valuable) things to do.
I find estimation and size limits to be good QA. It kind of forces you to flesh out unanswered details. So I use it as a tool for that.
Not sure estimating tasks adds a lot of value though. But the act of listing them can refine the original estimation, so some value can be had by braking things into tasks before sprint planning I guess. Wouldn’t wast time on it for non-sprint candidates though.
But yeah, breaking a backlog down into meaningful, but minimal, issues takes some finesse.
I have seen the model break down while working in small, heterogenous teams. Work is assigned "automatically" to the person that will inevitably do the work, consequently team members refrain from judging work done by the specialist in the team, and so on until you can throw all the typical "scum tools" into the garbage bin. Turns out a kanban-style division of labor approach is sometimes preferrable... But is that agile? Depends on who you ask.
Currently working in a kanban/pair programming/tdd project and it is indeed the best that can happen to you. Plus pair programming spreads knowledge extremely well.
As someone who has had the fortune of working on real agile teams, this has the same relationship to that as the German Democratic Republic had to Democracy.
