Notes taken while reading Developers Should Abandon Agile by Ron Jeffries.
I believe that developers should detach their thinking from any particular named “Agile” method. Instead, they should turn their attention and learning to ways of doing software development that will work within any of those “Agile” methods. Those development approaches, to me, involve use of practices such as, but not limited to, those of Extreme Programming.
More generally, developers’ work should adhere to the foundational principles that support Agile Software Development, as we had in mind when we wrote the Manifesto.
No matter what framework or method your management thinks they are applying, learn to work this way:
-
Produce running, tested, working, integrated software every two weeks, every week. Build your skills until you can create a new fully operational version every day, twice a day, multiple times a day.
-
Keep the design of that software clean. As it grows, the design will tend to become complex and crufty. Resist and reverse this tendency consciously, refactoring in tiny continuous steps, all the time, so that your rate of progress is as steady and consistent as possible.
-
Use the current increment of software as the foundation for all your conversations with your product leadership and management. Speak in terms of what’s ready to go, and in terms of what they’d like you to do next.
By keeping the software always ready to go, we can hit any deadline with the best possible result. The running software in our hands lets us keep the conversation focused on the next, most important thing to do, rather than the near-infinite list of things they think they want.
It’s not easy to change the focus from “do all this” to “do this next”
But if you can reliably select work to do over the course of a “Sprint”, and accomplish that work, packaging it up in a running, tested, integrated, ready-to-go new version of the system, you’ll be equipped to do the best it’s possible to do.
Under pressure to sign up for more than you can do, I’d suggest that you work on one or two of the items, complete those entirely — fully packaged, tested, and working — and then do another, so that at the end of the boxcar you have something that you can absolutely call completed.
Try to drive planning and expectations from reality, not the fantasy of what was demanded, that you never had a chance to do.
Having a completed running product slice is the best way I know to possibly turn the situation around.
In a bad situation, all we can do is our best, and try to help things to get better.
I’d make it clear that every two weeks at most, I would like to review their running tested product slice. We’d talk about what they should do over the next interval.
I’d provide someone with a solid connection to the business needs to be met by the product, who would help them decide what slice of work to do next.