The product owner role on agile projects is critical to the team and the project. The product owner's influence, performance, and behavior can set the stage for smooth sailing—or sink a project. In this article, Anupam Kundu shares two different product owner experiences to drive home the argument how their behaviors and practices can shape organizational culture—specifically for new product development and start-ups.
With all of agile's documented successes, the methodologies are being used in areas never before seen. Scott W. Ambler looks into why agile is as popular as it is, and why its popularity will only increase in the future.
Looking for an agile refresher? Here, Jurgen Appelo applies his seven dimensions of software projects—people, functionality, quality, tools, time, value, and process—to what he believes are the fundamentals of agile. And, for those who might disagree, he suggests an eighth dimension that brings its own value to agile: conflict.
The Blue Ocean Strategy gives important insights regarding how to create new market space in uncontested markets thereby making the competition irrelevant. This strategy can be adopted to explain the significance of agile methodologies as compared to the Waterfall method of software development.
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.
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.
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.
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.