Infoq interviews Jeff Sutherland. Even though Silicon Valley companies have adopted Scrum, what’s the biggest problem? Eighty percent of the teams do not have tested, working software at the end of the sprint. This is a gross violation of the Agile Manifesto’s second value:
Working software over comprehensive documentation
Here are three techniques I practice to deliver working software at the end of a sprint.
Limit Work in Progress — Limit the number of user stories in progress. For example, the team only works on three stories at a time. This constraint compels the team to complete a story before starting another. I also teach teams to swarm on the top priority story and focus on completing it. Stop starting, and start finishing.
Hire full-stack developers — For your team to effectively swarm on a story, people need to have multiple skills. Developers should know how to write code in all layers: UI, business and database layers.
Test-Driven Development (TDD) — In many cases, stories are not finished because the team is still testing. Solution? Test first. When a developer practices TDD, she writes the unit test first, then the code to pass the test. The unit tests can be run every time a new build runs, making the code self-testing.
Practice the three techniques and let me know how they worked. What challenges did you discover?
How does it work? Well, in it's basic form, you forecast the story points for the upcoming sprint based on the story points completed in the last sprint. By using this pattern, I've reduced the sprint planning meeting from an hour of chattering debate to five easy breezy minutes.
Instead of directing employees and managing their tasks, you create an environment where they can be successful. Ponder this paragraph.
The effective Agile Leader spends less time managing for results and more time designing environment that create results. They spend less time telling others what to do, and more time creating conditions that empower and enable others to know what they need to do, and to be in action doing it.
The authors refer to catalyzing leadership. If you wish to learn more about catalyst leadership, you may want to read Leadership Agility where a chapter is devoted to the qualities of a catalyst leader.
Modules: Information hiding, or behavior hiding, is the foundation of object-oriented approaches. Delay commitment to the internal design of the module until the requirements of the clients on the interfaces stabilize.
Interfaces: Separate interfaces from implementations. Clients should not depend on implementation decisions.
Abstractions: Abstraction and commitment are inverse processes. Defer commitment to specific representations as long as the abstract will serve immediate design needs.