Succeeding with Agile: Software Development Using Scrum Book Review

I have been implementing and improving development processes for a while now. Either directly when I am brought in as a Software Process Engineer, or indirectly when I am brought in as a Software Architect. I have not been involved with process improvement on all my engagements. The ones I was not involved with already had a decent development process in place, or they already had an initiative underway. I have never personally led a process improvement initiative to a Scrum implementation. I always implement a configurable process repository that allows for everything from OpenUP, to UP, to RUP. I have never had the request for Scrum nor have I tried to sell it as an option. The main reason for that is until recently I have found it to be incomplete when it came to enterprise scale. The Scaled Agile Framework has taken the initiative and filled in the gaps. The book Agile Software Requirements: Lean Requirements Practices for Teams, Programs, and the Enterprise does a great job of covering the Scaled Agile Framework. I have seen Scrum attempted multiple times. Depending on the perspective they all failed and they all succeeded. Watching from the sidelines, our consult team's view was they failed miserably, but according to the internal managers that made the choice to go with Scrum they were a huge success. Depending on who was asking the development team, us or the managers, they had completely different answers. The most important party, the end user, saw no change to the quality of software delivered or slightly worse quality. They were never the wiser that the team was attempting Scrum, so their opinion didn't matter. What? Yep, in every single attempt I have witnessed the end user's role didn't change. Neither did the upper management, sales, or marketing. It was a development level attempt to implement a bottom up change that requires change at every level of any decent size organization. I don't have to really go into any more detail explaining why the initiatives failed. By the way, if you are sitting there thinking, 'I must have missed something, why did they fail?', you absolutely must read this book!!! This book is down to earth does not just regurgitate Scrum practices, it provides tons of advice and examples from past experience. The book is for all levels of individuals and teams involved with or thinking about getting involved with Scrum. The book is broken down into five parts. Getting Started, Individuals, Teams, The Organization, and Next Steps. The chapter's titles are self explanatory. I have listed them by part below. Part I: Getting Started- Why Becoming Agile Is Hard (But Worth It), ADAPTing to Scrum, Patterns for Adopting Scrum, Iterating Toward Agility, Your First Projects Part II: Individuals- Overcoming Resistance, New Roles, Changed Roles, Technical Practices Part III: Teams- Team Structure, Teamwork, Leading a Self-Organizing Team, The Product Backlog, Sprints, Planning, Quality Part IV: The Organization- Scaling Scrum, Distributed Teams, Coexisting with Other Approaches, Human Resources, Facilities, and the PMO Part V: Next Steps- Seeing How Far You’ve Come, You’re Not Done Yet Every chapter gives in depth coverage of the topics included. What I like best about the book is all the examples the author includes from past experience. There is only two ways of gaining experience, gain by doing and learning yourself, or learning from others that are willing to share theirs with you. The author offers every ounce of his experience he has with both successes and failures. He does not pull punches. He gives accurate full accounts of the reasons for both. There wasn't a chapter I did not enjoy or did not find valuable, but I really liked part two, Individuals. The first chapter in part two is Overcoming Resistance. I have experienced everything the author highlights in this chapter when I am involved with process improvement. You will need the advice offered in this chapter to succeed. People do not like change even when it is for the better. There will be those that make it their mission to sabotage your efforts. Another really important chapter in part two is Changing Roles. Not only is it important to understand what is changing about the roles, but also understand the ones being eliminated, like the project manager. Although the project manager is being eliminated the responsibilities are not. In Scrum most of the responsibility is transferred to the team. This can be a major issue if the team can't handle them. You need to be careful to not just blindly axe the project manager. Every time I have seen Scrum attempted the project managers are simply give the role of ScrumMaster. The problem I have seen though, is that they don't change anything they are doing. You don't have to do away with project managers, but at a minimum a name change is recommend. The author includes a great explanation as to why in this chapter. The chapter discusses changes to Analysts, Project Managers, Architects, Functional Managers, Programmers, Database Administrators, Testers and User Experience Designers. Another thing I like about this book is that the author does not lose sight of the enterprise. He covers several topics throughout the book that enable scale and organization wide implementation. You may get lucky and Scrum may take off like wild fire after you have a small successful project, but odds are it will not. The author covers Enterprise Transition Community, scaling Scrum, distributed teams, epics, themes, and Scrum of Scrums. There is nothing I can think of that I would have liked to see included that wasn't. This is one of the most enjoyable reads I have read in a while. The author's writing style is great. All the stories from past experience really help you to put the subject being covered into context. The stories also keep it interesting. All in all I highly recommend this book to anyone getting involved with, or already involved with Scrum. It is an absolute must read!!!

Succeeding with Agile: Software Development Using Scrum