Scrum is, by design, a “pull system” rather than a “push system”. The Scrum Team determines how much work they will pull in to each Sprint. The Product Owner determines what items are ready to be pulled in according to
Maintenance Patterns for Scrum Teams
Try as we might, software products are never perfect. Coding styles, legacy bugs, tight deadlines, changing frameworks and evolving languages all contribute to the error potential of complex systems. Scrum Teams are often faced with the choice of working on
Creating a Team of Experts
In the software world, there are principles that can be applied to make an architecture more agile. One of these is “design for change”. Because change is inevitable, a robust design will anticipate change in a way that minimizes impact
A Sprint is Not a 2-Week Waterfall!
One of the most frequent Scrum questions I get in my travels is this: “How can we improve our Sprints so that we don’t run out of time for testing?” The answer is simple. Stop treating your Sprints like a
Managing Technical Dependencies
A common question asked in large enterprises when they start transitioning to Agile is “What about dependencies?” When we talk about incremental development, evolutionary design and simple solutions some people get nervous. “But our system is huge and complicated!” we
Multitask at Your Own Risk
Here are some thoughts on multitasking in IT – assigning people to multiple projects at the same time. Multitasking Gets You There Later.