Best of TechBeacon 2016: Agile shows age but no less transformational
Fifteen years is a long time in the technology industry, so it should come as no surprise that agile development practices today bear little resemblance to the values and the principles expressed by the group of visionary developers who created the Agile Manifesto back in 2001. There’s little doubt, however, that agile has radically transformed software development practices in good, and sometimes unexpected, ways.
Here's TechBeacon’s list of the top 10, must-read agile stories from 2016.
More than 16 years ago a group of software development engineers met at a ski resort in Utah and drafted what would become the basis of the agile process for software development. Robert (“Uncle Bob”) Martin, one of 17 developers behind the Agile Manifesto, talks with HPE senior researcher Malcolm Isaacs about the impact and the legacy of that meeting.
If your organization is like the many that have moved from scrum to the Kanban model of agile software development, you probably know that Kanban makes a better fit for teams than does scrum. Where scrum is somewhat overly prescriptive in nature, Kanban is not so at all, and is only bound by three broad rules. But that lack of structure can be a problem, as agile consultant Yvette Francino explains.
DevOps can be truly transformative, but it's not a silver bullet. Environments that emphasize centralized application deployment, such as the cloud, can benefit from continuous delivery. But there are some situations where the CD model just doesn’t work at all, such as in ISAM and COBOL environments, as well as projects that involve system design and planning. David Linthicum explains why.
Much as DevOps teams like to believe otherwise, there’s no such thing as a blameless postmortem. Humans are simply hardwired in such a way that we give voice to uncomfortable and painful feelings by blaming others. So instead of being fixated on blamelessness, try adopting more blame-aware postmortems. The goal should be to have actionable outcomes, says J. Paul Reed.
Agile development practices tend to work well for smaller projects, but are less suitable for large-scale projects that involve multiple distributed teams. The Scaled Agile Framework (SAFe) and Disciplined Agile Delivery (DAD) are two of the most popular frameworks available for large-scale development projects. They offer guidance on coordinating all of the different moving parts in a big development project, especially in the early phases. Here are a few tips for choosing between the two, from Yvette Francino.
In theory, the Weighted Shortest Job First (WSJF) technique makes it relatively easy to prioritize projects that need to be completed. The idea is you assign a value, based on importance, to all of the projects that need approval, and then do some math involving the expected length of each job to arrive at a relative ranking for each. Confused? Excelon Development's Matthew Heusser offers these tips on how best to use the technique to figure out which tasks will give you the biggest bang for the buck.
The Scaled Agile Framework (SAFe) provides useful guidance for large-scale agile projects that involve between 50 and 125 developers. But as with anything that's relatively new, adopting SAFe can be a challenge. Agile transformation specialist Anthony Crain walks you through the biggest challenges: identifying the initial epics and value streams, ensuring code quality, and executing a release planning session.
One of the most common misconceptions surrounding agile is that your team is ready for it and can handle the multi-functional and self-organizing requirements demanded by the practice. These and several other similar fallacies often cause agile projects to fall short of their promise. Comcast’s director of software engineering, Stephen Frein, gives you the low-down on five of the deadliest ones.
Behavior-driven development (BDD) offers a way for product teams to test and validate application performance by keeping the user experience front and center all of the time. Many developers thinks that BDD is pure agile. But while it has been around for 10 years, few have adopted it. One of the biggest problems, says ArcTouch's Eric Shapiro, has simply been getting developers to understand what BDD is all about.
Agile teams often struggle to go faster, or even maintain velocity, because of a failure to incorporate design in their projects. Many assume that the focus agile places on developing working code somehow eliminates the need for all design and modeling activities. That's not true says ThoughtWorks' Steven Lowe, who lists the five design practices that absolutely must be incorporated into any agile project.