When Mary Gorman and Ellen Gottesdiener facilitated a game called The Backlog Is in the Eye of the Beholder for the Boston chapter of the International Institute of Business Analysis, both the players and the facilitators learned some important lessons in organizing a project requirements backlog. In this article, they describe the game and what it revealed, including the value of truly knowing your stakeholders.
Although many companies may have heard that the concepts of lean production would be of use to their organization, they do not see how something that sprang from manufacturing practices could apply to software development. This article presents a different way of looking at Lean Software Development—one that is independent of Lean’s manufacturing heritage.
Many times, Scrum Masters and agile coaches are confronted with the need to change a team that seems to be stuck in its own behavior. And though team members may be willing to change, they just can’t seem to get out of their current situation. The author sheds a new light on this difficult problem and proposes to change the environment instead of the team.
This article presents a different way of looking at lean software development; one that is independent of lean’s manufacturing heritage. It begins by presenting lean as a collection of a body of knowledge applying lean principles to software development.
Karl Scotland explains that viewing kanban as a systemic approach leads to systems thinking. Systems can be thought of as being made up of elements, which interact to meet a purpose. They are more than the sum of the parts, and the system’s purpose is crucial in determining the system’s behavior.
My team is in the middle of one of the hardest projects—we call them "themes"—we’ve ever tackled. We’re a high-functioning agile team that has helped our company grow and succeed over several years now—we “went agile” in 2003. Here’s one thing I know for sure: No matter how many problems you solve, new challenges will pop up.
A successful Scrum implementation requires proper understanding of Scrum processes within team and within all project stakeholders. Even after proper training and certification (CSM/CSPO) it’s really tough to achieve the success as intended. There is one common and important problem which has always been overlooked: the alignment of current team with Scrum the model. Because, vanilla-Scrum only describe what the role does in the process.
There continues to be a lot of debate on whether Agile is mainstream. According to a Forrester report published in early 2010, while widespread “Agile” use of the iterative software development processes is found, " teams are not adopting scrum, extreme programming, or another specific Agile approach, but are embracing agile as an ethos or philosophy and cherry-picking the best bits from many different process models to develop a formula unique to their own situation." However, the largest category in the survey – and the one that is the most telling is that 30.6% of the respondents said they do not use a formal process methodology. Add to this my own experience implementing Agile, reading the latest Agile literature (e.g., articles, research, books, etc.), and discussing Agile (and Agile implementations) with people across numerous companies in North America, Europe, and Asia, and what this indicates to me is that:
This two-part article explores branching strategies—development tactics that allow teams to work concurrently on different features and maintain the relationship between them. In part one, Steve Berczuk explains what branches are, common types of them, and the tradeoffs between branching styles.
In this article, Jennitta Andrea explains how a community of practice retrospective differs from a project retrospective. She also explores the motivation for a community to perform this type of retrospective.