I have been having a lot of discussions lately with Mike Cottmeyer over at www.leadingagile.com about scaling Agile to the Enterprise. Today he has a great post, Teams are the Building Blocks of Agile. Mike is exactly right. In fact, teams are the building blocks of organizations. And promises are the glue between the teams. In realms of uncertainty such as knowledge work and software development, Donald Sull would say to focus on Promises over Process.
Managing the promises in an organization is called Promise-based Management. The primary idea in Promise-based management is that work moves through organizations based on a network of promises. And that the better the promising is, the faster the work will move. The whole business is a network of “if you can do this”, then “I can do this” promises. When this network works well, the business improves its ability to profitably create value for the customer. We can improve the performance of the network by improving the reliability of the promises made between teams in the organization.
If you read Mike’s post from a certain perspective, it sounds like Mike is saying the purpose of the organization is to make life easier for the developer’s. That isn’t what he is saying, though. He is saying that for an Agile team to keep its promise, you have to set the Agile team up to be successful by providing the appropriate context and coordination.
The promise the agile development team makes is to rapidly produce high quality software for use by the business. This is probably so the business can keep the promises it makes to its customers and stakeholders. The Agile development team is willing and able to make these promises when the <Product Owner>Product Manager, Project Manager, Designer, Subject Matter Expert, Business Stakeholder, Business Analyst</Product Owner> is able to set the table for the team by getting the proper context and coordination in place. Mike defines this part of the promise on his blog. This context and coordination effort is the “If you can do this” part of the promise that the Product Owner and Agile development team make.
Once we set the Agile development team up for success, they will be able to much more rapidly produce high quality software for use by the business. The new capability to keep this promise opens up a whole new set of promises we can make to the customer. Exploiting this new capability is not just about software development, it requires us understand impact on the other processes, promises and teams in the organization. Scaling Agile to the organization isn’t about software development. It is about fundamentally changing the promises we can make to our customers.
Check out “Promise-based Management: The Essence of Execution” in Harvard Business Review. Glen Alleman talks about the HBR article. Hal Macomber’s site is a rich resource practical application of promises and promising and making work ready. Clarke Ching’s site is an excellent source of the application of promised based management to software development.