There is a huge difference between using Agile practices and being Agile. Here, a chief engineer discusses his organization’s strides in creating an Agile mindset and a customized approach to producing high-quality work in short time frames. The journey offers practical advice and techniques to those getting started or struggling with Agile transformation.
When planning a sprint, many factors will influence what works best, particularly the experience of the team in self-organizing. Here are some guidelines that can help project leaders focus the planning effort — without taking it over — and a few techniques to engage everyone and establish a shared vision.
Adult children. Jumbo shrimp. Seriously funny. I’m sure you recognize these expressions as oxymorons — self-contradictory phrases, often with an ironic meaning. Should we add “agile requirements” to the list? Does agile development fit in with traditional requirements practices? And if so, how?
Agile practices are not intrinsically “value-adding” — they must be aligned to business needs and goals in order to provide true value. By measuring their agility based on compliance with a particular method, organizations may prevent their teams from adapting practices to suit projects with different characteristics and needs.
On many projects, work is planned months in advance and you might delay a milestone or implementation if it is not completed. In an Agile project, you plan for the current iteration and adjust workload, if necessary, for the next. Here is a primer on the fundamental Agile concepts of story points, velocity and team rhythm.
Velocity measures an agile team’s ability to execute, but it often gets misinterpreted or manipulated, which leads to hopeful hunches or downright bad decisions. Because a team's most recent sprint is most indicative of future performance, there's a way to calculate velocity that generates estimates you can use with confidence.
Technical debt describes the cumulative consequences of cutting corners in software development, but it escapes the attention of many project managers as they focus on scope and schedule. That’s a mistake because it impacts both. Here are questions to help you ascertain the real state of technical affairs.
The first step in scaling agile is to move from partial methods to a full-fledged, disciplined delivery process. The second step is to understand eight scaling factors and determine which are applicable to the range of complexities your project teams face. Here, agile thought leader Scott Ambler presents his scaling model.
Sometimes the true spirit of Agile gets lost in burndown charts, daily standups and endless debates of what it is and isn't. That the Agile Manifesto is uncomplicated and open to interpretation presents both challenges and opportunities. So do what makes sense and continually re-evaluate what that means.
You know that using Scrum to manage projects can make a positive difference in your organization, but the executives you need to help drive the change are lukewarm or resistant to the idea. Here are some tips for getting them to buy into and support a Scrum implementation.