| What's DIB? Just trying to understand who is the target audience of this guide. It's a practical set of traits to spot. But inevitably a question comes up "what to do next?" Re-educate, enforce, hire/fire, disband? One needs to remember how the Agile processes were being "installed" back in the day in organisations/teams of various degree of dysfunction. Lots of those teams went through trials of "templates", including waterfall, just with the same outcomes. Too often, the failure is not at the team but on org-level. The base tenet of Agile success is buy-in on all levels. Yet it's easier for the management to "buy-into" a structure and attributes, not into actually empowering and trusting the teams. So, this detection approach may find all right attributes, tools, lingo, roles... but not the actual practices. A beaten down example is a morning stand-up, which disguises the dreaded subordinate reports - best indicator of such theater is a presence of a "clip-board" or note-taker person. I'd think for such guide to be of better practical value, there should be a section which would outline ways to detect the constraints and obstacles for adoption of a proccess which would be effective in a given team's case. It does not have to be Agile-or-wrong. |
Made up of various tech industry leaders (mainly CEOs, it seems). The purpose was to try and modernize the way, or present a path to modernization, defense software systems are developed and maintained. Because it's presently a cluster fuck.