I came across a post by Damian Synadinos, dating from August 2017, entitled Thinking about Beliefs. He explores the idea of belief systems; how they come to be, how people interpret them, how adopters implement them, various things that can go right or wrong when people apply them, and what can happen when we question our belief systems.
After presenting a general model of belief systems, Damian goes on to illustrate his ideas by describing how he set out to question his beliefs regarding software testing; that is, his belief system around his work. He discovered that some of his previously-held beliefs about software testing seemed sound while others had room for improvement, once he began to question them systematically.
Continue reading Scrum as a belief system
This tweet resonated with me:
The comment applies to the author’s area of focus, but the pattern she observes occurs broadly in our field. How is it possible circa 2019 that the majority of people in the software field are not routinely using:
- rolling-wave planning to avoid premature investment in undeveloped ideas and to enable business flexibility/agility?
- flexible funding models to avoid locking up funds in early, long-term budget allocations?
- product-oriented experiments to steer development work toward target capabilities, as opposed to a portfolio of projects with rigid, predefined objectives and timelines?
- collaboration with stakeholders, Specification by Example, Personas, Story Mapping, etc. to understand user needs?
- cross-disciplinary collaboration to build solutions, including cross-functional teams, sitting together, swarming, mobbing, pairing, etc.?
- development techniques that yield multiple forms of value for a single effort, such as test-driven development and test automation, both for infrastructure and for applications?
- general automation to reduce errors and ensure consistency, such as continuous integration, static code analysis, dynamic infrastructure management, etc.?
…and, of course…
- observability rather than monitoring?
Do people actually prefer
Continue reading For the love of stress
Throughout my career, people involved with software development and support have done their best to make software perfect; or at least to eliminate all the bugs from it. We’ve come up with more and more design principles, development techniques, testing methods, system monitoring and self-correction schemes, and tools aimed at avoiding, preventing, detecting, working around, recovering from, and removing bugs from software.
Continue reading A different wall to bang our heads against