Management 3.0 is a book (and a brand) by Jurgen Appelo which many points as the go-to guide for the Agile managers. It's true we have many instances of developer-oriented books that teach Agile practices and principles (from XP Explained to the most recent and specialized ones such as Continuous Delivery).
Agile has found in the Lean literature examples of system optimization, but needs to go beyond working on your own abilities or on the team practices. Management 3.0 tries to do the same with the single people involved in your team.
If every book has an overall message, the one of Management 3.0 is its leitmotif of Agile teams and organizations as complex systems (the term itself has its own definition in science, and it's not a synonym of complicated). There is no one true way of organizing a team or a project's code, and a complex system cannot be reduced to a board of cards that move forward: all models that we use for trying to make sense of the programming world around us are by design ignoring many aspects that come back to bite you (all models are wrong; some models are useful.)
One example is practice adoption. When introducing a new practice such as Continuous Integration in your team, consider:
- whether the context supports it (having a regulated environment like the development of Space Shuttle software, or a legacy SVN repository that takes forever to commit?)
- Its interaction with other practices, such as Test-Driven Development.
- The capability of developers and their maturity in applying it with discipline.
- The effect it will have on the energy of the team (seems fluffly, but most of us use this metric to choose where to work.)
Adoption of practices then should follow a probe-sense-respond cycle, where we try to guess which practice is most needed to fix the current problem, guide it in place, and measure the result to move into the direction of the next peak of efficiency (which could mean going back t square one). After one practice introduction, the topmost problems of the team may become different even if the practice was just targeted to one of them.
The book itself is fun to read and not heavy, despite being a non-technical topic at best.
Agilists believe that a process should be grown throughout a project, beginning with a bare minimum of a few practices. RUP tried the opposite approach, defining many practices and then suggesting that the unneeded ones can be removed. (I have often compared this approach to the purchase and subsequent dismantling of a Boeing 747 with the purpose to turn it into a bicycle for shopping.)
Scrum is not a methodology, a defined process, or set of procedures. It's an open development framework. The rules are constraints on behavior that cause a complex adaptive system to self-organize into an intelligent state.
To manage social complexity, they need to understand how things grow. Not how they are built.
One conclusion is becoming more and more evident: The primary focus of any manager should be to energize people, to make sure that they actually want to do all that stuff.
I have repeatedly claimed that excellence and self-discipline are wrongfully assumed by Agile and rarely made explicit.
Scott Berkun suggests theres one simple question that a manager can ask every person in a team: What can I do to help you do your best work?
Motivating your people is always more important than establishing your own favorite processes.
Nowhere on the Agile Manifesto does it say that you have to do automated testing, pair programming, or refactoring.
One nitpick with the book is its likelihood to be not as practical as technical books involving tools and code. Since the subject is people, not programs, it's difficult to produce the same self-contained and clearly solvable problems of Growing Object-Oriented Software or SICP.
Do not expect daily lessons that you can take a Pomodoro of your day to exercise on - the book involves lifelong experimentation with your team.
Management 3.0 recognizes lessons that zealot Agilists don't - by embracing the Manifesto but not individual methodologies, which are models always doomed to be incomplete (even XP has a Fix XP when it breaks maxim.)
Complex systems theory, a patchwork of different scientific bodies of knowledge, is the base for this book; if it leaves you with one concept, it would be: software development in anything else than single-member teams is primarily about people, and in growing a living system where they can do their best work and improve. That is not easy, but it will give you food for thought.