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.
People are creatures of habit, particularly programmers: We seek consistency, whether it is the tried-and-true waterfall/SDLC method or our morning routine of reading the newspaper with a hot cup of coffee. Companies or projects looking to adopt an agile process neglect the fundamental concern of an individual developer: "What will my day to day look like working in an agile environment?"
Anupam Kundu describes an agile-enabled framework for product managers, project portfolio managers, and IT executives to develop and maintain a dynamic and flexible product roadmap. The product wing of the digital division of a publishing house adopted this collaborative framework to to charter their product roadmap and simultaneously enable their project team to see and understand the “big picture.”
Burn down charts help agile development teams track sprint and release progress. The basic idea of a burn down chart is that the team starts with estimates for all of the tasks in the sprint, and then on daily (or more frequent) basis re-estimates the amount of work remaining.
One of the new roles introduced by agile software development is that of the team coach. Until agile came along, coaches were confined to the executive suite or the sports field. As with any new role, it will take awhile before it is fully understood and scoped. Agile teams can—and do—exist without the coach role, but such teams do not necessarily achieve peak performance.
How do companies face the challenge of setting up their infrastructure when they've just started agile development? One option is to move your infrastructure to the cloud. In this article, we help you decide what's the best fit for your team and project by addressing this issue head on.
There are no best practices for creating a productive, global development organization, just a few good ideas to think about and tailor around your particular objectives. Consider three universal issues every organization must grapple with to make a global agile team successful: data considerations, communications needs, and a company's agile readiness. How you handle each of these issues will vary widely, and there is no one-size-fits-all solution for every organization.
Usually, when Jean Tabaka lists practices, techniques, ideas, or recommendations about software development, she sticks with the number ten. It's nice and neat and has a fine history of enumeration cleanliness dating back to the Old Testament. But for agile adoption failures, Jean thinks it is time to invoke some Spinal Tap and go to eleven. Here are her top eleven signs that your agile adoption is headed down a slippery slope to failure.
This article discusses the highlights of a distributed Scrum project run by SirsiDynix (Provo, UT) and StarSoft Development Labs (Cambridge, MA and St. Petersburg, Russia). The project focused on the new implementation of platform and system architecture for a complex Integrated Library System, which is best compared to a vertical market ERP system with a public portal interface used by more than 200 million people.