A Collection of Agile Resources by J. Sutherland, K. Schwaber, D. Star, M. Lacey, and D. J. Anderson
Microsoft has put together a number of resources for Visual Studio developers, containing principles, practices and guidelines for Agile development. These resources are condensed articles written by influential Agile leaders -Jeff Sutherland, Ken Schwaber, David Star, Mitch Lacey, David J. Anderson - containing the essence of several Agile methodologies and being usable by any software dev team.
The resources are divided in three sections: Agile Principles, Agile Practices, and Lean and CMMI.
Jeff Sutherland elaborates on four core values as defined by the Manifesto for Agile Software Development:
Individuals and their interactions
Delivering working software
Responding to change
He also distinguishes between Agile, its methodologies and practices, detailing the meaning and complementary role of Scrum and XP.
In this article, Jeff Sutherland recollects the 10 Year Agile Retrospective held at Snowbird, Utah, 2011, a meeting where some of the original Agile manifesto signatories met with Agile thought leaders to celebrate 10 years of Agile achievements and outlining four key factors for success during the following 10 years:
Demand technical excellence.
Promote individual change and lead organizational change.
Organize Knowledge and Improve Education.
Maximize value creation across the entire process.
After listing several impediments in the way of achieving success, Sutherland concludes:
It is essential that Agile teams improve their practices to resolve the largest problem facing the worldwide Agile community –technical excellence. Getting product backlog ready requires professional product managers that understand user needs and team capabilities with a passion for delivering excellence. Getting product backlog done in a sprint requires prioritizing work, continuously integrating work in progress, and intolerance of defects. Demanding technical excellence is the top priority for the next ten years.
Using real or imaginary case studies, Ken Schwaber and David Starr discuss the perceived Done and the real Done, explaining how to differentiate between the two and how these can influence the success of a project. They elaborate on transparency, technical debt, release plans, and two techniques for getting things done: Scrum of Scrums and Continuous Integration.
In this article, Mitch Lacey discusses the importance of a product backlog, providing practices for creating and maintaining a good one. He covers the topics: User Stories, Estimating, Prioritization and Grooming, concluding at the end:
A good product backlog helps ensure that the software you build has the most important features as identified in your conversations with customers and stakeholders, and defined in your user stories. In order to create and maintain a good product backlog, you need to stay actively engaged with both the stakeholder/customer group and the team on a regular basis—every sprint.
Building a good backlog does not ensure a good system, but the lack of a good backlog will almost ultimately ensure that you have a system that does not do what the customers asked for. In other words, not keeping the backlog up to date will almost always result in project failure.
The product owner is a full-time job, and the backlog is their responsibility. Take the role seriously. Keep the product backlog in a good state—your customers will thank you.
Mitch Lacey continues the previous article, Building and Managing the Product Backlog, with three methods for backlog prioritization:
Lacey sees the backlog as a “living thing”, one that needs constant attention and reprioritization in order to achieve success.
In this article, Mitch Lacey addresses the issue of project estimation, explaining why it is hard to make good estimations, talking about Story Points as Unit of Measure, and proposing two estimation techniques: Planning Poker, and Wall Estimation. Lacey concludes on this one:
Estimation is hard because there is so much uncertainty at the beginning of a project. Product Owners and agile project managers try to maximize value early learning by having conversations with their product owners and stakeholders, producing working software, and integrating feedback about that software to get to a releasable state. But even agile projects must provide some estimate of when a set of features will be ready for release.
Mitch Lacey ends his Agile practices series providing advice on Sprint planning. He starts by talking about Forecasting versus Committing, continuing with Planning and how to accomplish it, along with some common problems and solutions encountered during this process. Lacey thinks that Sprint Planning “does not need to be challenging. It is often fun and a time for the entire Scrum team to build camaraderie by working together”.
Lean and CMMI
In this article, David J. Anderson introduces Lean, its relationship with Agile, and the Lean Values, Principles and Practices. According to Anderson, the Lean Values are:
Accept the human condition
Accept that complexity & uncertainty are natural to knowledge work
Work towards a better Economic Outcome
While enabling a better Sociological Outcome
Seek, embrace & question ideas from a wide range of disciplines
A values-based community enhances the speed & depth of positive change
The Principles defining a Lean development process are:
Follow a Systems Thinking & Design Approach
Emergent Outcomes can be Influenced by Architecting the Context of a Complex Adaptive System
Respect People (as part of the system)
Use the Scientific Method (to drive improvements)
Generate Visibility (into work, workflow, and system operation)
Reduce Flow Time
Reduce Waste to Improve Efficiency
Anderson says that Lean Software Development “does not prescribe practices”, but the community has adopted a number of them, including: Cumulative Flow Diagrams, Visual Controls, Virtual Kanban Systems, Small Batch Sizes / Single-piece Flow, Automation, Kaizen Events, Daily standup meetings, Retrospectives, and Operations Reviews.
There is no such thing as a single Lean Software Development process. A process could be said to be Lean if it is clearly aligned with the values and principles of Lean Software Development. Lean Software Development does not prescribe any practices, but some activities have become common….
The organization using a Lean software development process could be said to be Lean if it exhibited only small amounts of waste in all three forms (“mura,” “muri,” and “muda”) and could be shown to be optimizing the delivery of value through effective management of risk. The pursuit of perfection in Lean is always a journey. There is no destination. True Lean organizations are always seeking further improvement.
Lean Software Development is still an emerging field, and we can expect it to continue to evolve over the next decade.
In this article concluding the series of Agile resources that we are covering, David J. Anderson affirms that managers, process engineers and stakeholders can get valuable insight into an organization by using the Capability Maturity Model Integration (CMMI). Anderson explains what organizational maturity is, the CMMI model, how an organization can progress through various maturity levels, and how CMMI maturity is rated.