Articles

Combining agile and SEMAT yields more advantages than either one alone. This paper discusses how two current popular movements complement one another to provide a powerful basis for software development.

What do we mean by Quality? The word Quality is commonly used in software development, but it isn’t always clear what is meant by it. Teams create Definitions of Done, configure thresholds in their CI/CD pipeline, write performance tests and agree service level agreements, but are these sufficient for the level of Quality the customer expects?

Industrial-­scale agile requires much more than just being able to scale agile. It also means taking a disciplined approach to ensuring that our IT investments are resulting in sustainable benefits for both the producing organization and its customers. This involves adopting a different approach to many aspects of agility. We need to look beyond small-­scale agile, beyond independent competitive islands of agile excellence, beyond individual craftsmanship and heroic teams, and beyond the short-­term, instant gratification that seems to be the focus of many well-­intentioned but self-­centered agile teams. It is this adoption of a more holistic approach that we call moving from craft to engineering. This paper is published at acm.org.

The Scaled Agile Framework's recommended approach for prioritisation within the Portfolio is to use Weighted Shortest Job First (WSJF), but there are some challenges when trying to run WSJF at the Portfolio level. This series of posts explores those challenges, with this post focusing on what happens when Total Epic Effort is used within WSJF.

Use Case Definition:  Use Cases have been around for almost 30 years as a requirements approach and have been part of the inspiration for more recent techniques such as user stories. Now the inspiration has flown in the other direction. Use-Case 2.0 is the new generation of use-case driven development - light, agile and lean - inspired by user stories, Scrum and Kanban.

Welcome to the amalgamation of a short series of articles on crafting effective, well-formed objectives as part of the SAFe® Program Increment (PI) / Big Room Planning activity. We have seen a lot of confusion surrounding the use of PI objectives; confusion that often results in: Resistance to their use and; The production of poorly formed team objectives that appear to be completely redundant as they just list the Features being addressed. The first step to creating well-formed, useful objectives is for everyone to understand why they are so important. Covered in this document: Why do we need PI Objectives when we have Features? Writing good PI Objectives PI Objectives and the PI Planning Process PI Objectives Beyond PI Planning: Reaffirming and Monitoring Your Commitments