I just read this interview article with Bob Martin and I have a few thoughts about it. Uncle Bob is extremely code-focused and always has been in his career. This isn’t a criticism, far from it, but one must take that into account when reading his opinions on such matters. He is heavily involved in the Software Craftsmanship movement, which he sees as a follow-on to the Agile Manifesto itself. Like any business practice, Agile
One of the most fascinating documents I’ve read to date is the memo from Roger Boisjoly on O-Ring Erosion. The original target audience for this memo he’d written were the management folks of Morton Thiokol back in 1985, about six months before the Challenger disaster. What I find so striking about this whole story is its resemblance to the field of software engineering. We software developers can relate to this story all too well. I’ve
There is a practice in many agile conversations known as having a “Definition of Ready” for a Product Backlog item. That is, a given User Story (or other PBI) must meet the Team’s “Definition of Ready” to be considered actionable or even worthy to estimate. This can be desirable from the team’s perspective when they are not getting enough information about the work they are being asked to do by the Product Owner. While I
I’ve had some great opportunities working with teams applying lean and agile techniques to domains beyond software development. Along with other areas, I’m having lots of conversations around applying Scrum in HR teams. This is fairly unique because the core usage model for Scrum is to apply it when the work is fairly unknown and complex, and the team is working together to create a shared product. Many knowledge worker teams simply aren’t like this.
Several teams I’ve worked with wonder why it is important to finish work within the Sprint timebox. “This is an artificial container for my work,” they explain. “Why can’t our work just take the time it takes? Why must it be get all the way done in one Sprint?” In my experience, these frustrated teams are likely looking to move away from poorly implemented Scrum toward what will be disastrously implemented Kanban and just-in-time work
Many software development teams, especially those creating or supporting a shared platform or infrastructure, find themselves overwhelmed by ad-hoc work requests. A frequent response to this situation is to move from an iterative, incremental practice to Kanban or some other flow-based model. In many situations, this is the exact opposite of what should happen. When a team finds itself foundering under the weight of system support or ad-hoc work requests, it may be time to
Back in 2008, Jeremy Miller introduced the Thunderdome Principle, a technique he used for building maintainable ASP.NET MVC applications which later led to the FubuMVC open-source project. The basic premise of the Thunderdome Principle is to have all controller methods take in one ViewModel object (or none in some cases), and also return a single ViewModel object. One object enters, one object leaves! What I like about F# is that the language designers took a