Len Whitmore writes on using agile practices for the development of software. In the ten years since the Agile Manifesto, the agile development domain evolved, as evidenced by such things as the six levels of planning: strategy, release, iteration, daily, and continuous, with strategy appearing to be the least evolved of the planning levels.
CMMI and Scrum are two commonly used frameworks we have seen groups struggle with when using them together. This article describes how these frameworks aren't really at odds with each other and explains how implementation is the key to using them together.
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.
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.
Tired of guesstimating your estimation process just to create a completion date management will accept? Jonathan Kohl takes the guess work out of estimations by focusing on uncertainties. It may sound counterintuitive, but the idea is to focus on the fact that all projects face unforeseen delays. The rigorous estimation process Jonathan describes here provides your team a way that ensures enough time is scheduled for development and a date for completion management can agree upon.
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.
On the surface, a Broadway musical, a newspaper, and software may not seem to have much—if anything—in common, but they have one common thread. All are delivered on a fixed schedule. But of the three, software tends to stray the most from the fixed schedule. In this week's column, Jeff Patton says that by focusing on the readiness of the entire product—as done in theatrical performances and when publishing a newspaper—and not just on the completion of the planned bits of work, you can produce software on a fixed schedule that you know is ready to ship.
Life used to be simpler. In the early 2000s, if you wanted to go "agile," XP was the route of choice. And then Scrum became popular. And it was not too long before organizations began to hit the limits of these approaches due to their focus on teams. And then it became apparent that lean principles could be applied to software and Lean Software Development and later Kanban were added to the mix. Now, you have a great many choices: Not just about which method to use, but where to start, whether to go top-down or bottom-up, and what should be the scope of your effort.
Many flavors of Agile have emerged: Scrum, Lean, Feature Driven Development (FDD), and Extreme Programming just to name a few. These methods have numerous complementary and distinguishing features, but the gamut of choices can be confusing and disorienting - as if being told to choose the best from 31 flavors of ice cream. Return on Investment (ROI) is important to me, so Lean must be the answer. But wait, I also want to be agile with my business priorities so I’ll choose Scrum. We are left wanting a simple question answered: “Which Agile method should I choose for my organization?”
Product portfolio management has become an essential discipline for all development organizations that want to achieve enterprise agility. The repeated process of selecting, sizing, and prioritizing the work to be done ensures that their development teams are delivering the most valuable products and enhancements for the business’ clients. This is required for both external clients in the case of product companies and for internal clients in the case of IT organizations. However, the subject of this paper is another, possibly even more important, reason: avoiding the overloading of the organization’s development teams which greatly lowers their efficiency.