Agile! The Good, the Hype and the Ugly Book Review

Finally a book from an industry leader that has the guts to write about the real world of Agile software development. If I had to pick one word to describe this book, it would be 'truth'. This book is going to raise the blood pressure of some of the Agilists out there. If you think you may be one of those, do yourself a favor and keep at the forefront of your mind that the author points out all the good in Agile too. He is not telling a one sided story. When reading a strongly opinionated book like this, we tend to only see the things the author is pointing out as our flaws, or failures to understand, which blinds us to the gems we could have really benefited from. I have been guilty of that more than once over the years. I am an old man. I have been a consultant most of my 20 year career, so I have had the privilege of working in a lot of different environments, with a lot of different people. On most of those gigs I have had the responsibility of putting the software development process in place that the project would use. In real world development project's processes should be tailored for a given project. Allowing you to account for your team's skills and availability, your business's needs, the tools you have available, the environment you are working in, the difficulty of the solution, the working environment - team member locations, greenfield vs. brownfield development, and many more things that are usually not taken into consideration when a project is started. For a successful Agile project to actually run in an agile state, the process is the final thing that will help you, not the first. The first things you need are team members with enough experience to create an agile architecture, develop code with agile practices, requirement elicitors that understand how to collect, organize, and prioritize them in a way that harmoniously works with the architecture- including Quality Attributes, and complete support of the business unit, upper IT management/CIO, and customers. The business unit, upper IT management/CIO, and customer are the success-critical stakeholders. To gain complete support of the success-critical stakeholders, you need someone that can configure, implement, and manage a process for the environment the project will be executed in, and communicate all areas of the process to all stakeholders involved. This book is the best place to start if you hope to have anything that remotely resembles success running an Agile process. What about self-organizing teams? Read the book. I have listed the chapters below to give you a very high level of what is covered. 1 Overview 2 Deconstructing agile texts 3 The enemy: Big Upfront Anything 4 Agile principles 5 Agile roles 6 Agile practices: managerial 7 Agile practices: technical 8 Agile artifacts 9 Agile methods 10 Dealing with agile teams 11 The Ugly, the Hype and the Good: an assessment of the agile approach Chapter 1 is a summary of Agile ideas and introduces the following core characteristics of Agile. --- Values: general assumptions framing the agile view of the world. --- Principles: core agile rules, organizational and technical. --- Roles: responsibilities and privileges of the various actors in an agile process. --- Practices: specific activities practiced by agile teams. --- Artifacts: tools, both virtual and material, that support the practices. Chapters 2 and 3 are awesome. In chapter 2 the author takes a logical look some of the arguments for Agile, that the Agile authors use to sway us to accept the Agile way, and simply applies common sense to them. He shines a light on them allowing them to be seen for what they really are. Chapter 3, "The enemy: Big Upfront Anything" takes a look at plan-based approaches. I have had, and I currently have, a very difficult time reversing the damage Agile has done in this area. Advocating no planning on software projects the Agile community has done permanent damage to some organizations. There are people who have never seen a software process run correctly. They therefore have never seen software delivered that can actually run without a bigger maintenance crew than they had for development. My wife puts more energy into our plans for Sunday afternoons than some of the software projects I have seen put into planning the project. As a Software Process Engineer it has been a real battle keeping people grounded in reality when it comes to Agile. Have you ever sat in meetings of 2 to 40 people, and they were all agreeing on something that you thought sounded completely insane.  You think that you must be the crazy one, but in the end it turns out you weren't.  When it comes to some of the practices in Agile, I have felt that way, but it was the entire software industry that I thought must be nuts.  This book has given me back my sanity!!!! Chapter 4 covers the Agile principles. It takes the original raw principles and breaks them down into organizational and technical principles. In this chapter one of the things the author talks about is having a domain expert available to the team. I can tell you from experience his discussion is right on the money. The person you get that can be made the most available to your team, is the person the domain can afford to not have working full time on domain issues. Meaning they aren't that needed because they really aren't that valuable. Their knowledge is limited and they generally have a personal opinion on how things should work, rather than how they need to work. I have seen teams burnt badly by this single point of contact many, many times. The complete list of Organizational and Technical Principles discussed in the rest of chapter 4 are below: 1 Put the customer at the center. 2 Let the team self-organize. 3 Work at a sustainable pace. 4 Develop minimal software:   4.1 Produce minimal functionality.   4.2 Produce only the product requested.   4.3 Develop only code and tests. 5 Accept change. 6 Develop iteratively:   6.1 Produce frequent working iterations.   6.2 Freeze requirements during iterations. 7 Treat tests as a key resource:   7.1 Do not start any new development until all tests pass.   7.2 Test first. 8 Express requirements through scenarios. In the next chapter on Agile Roles, the author introduces manager, product owner, team, members and observers (pigs and chickens), customer, coach in Extreme Programming, and a Scrum Master in Scrum. He thoroughly covers these roles and the good and bad of each. What I would have liked to see is more on the roles eliminated from a normal SDLC. When the agile movement re-cast the roles of the SDLC they did so with small projects as the baseline of their experience. A typical minimal SDLC method includes subject matter experts (those who execute the current workflow activities), a Project Manager, a Business Analyst, a Software Architect, UX specialists, Developers, DBAs, and Testers. A Scrum Team consists of a Product Owner, the Development Team, and a Scrum Master. The typical SDLC method responsibilities for activities, and the skills needed to get them done, went from 8 roles down to 3. If you have a highly skilled team, for small projects that is great, but as the industry is learning the hard way, for bigger projects it just doesn't cut it. Although the author talks about it in some other sections of the book, I would have liked to hear the author's opinion on this. In the next chapter on management practices the author covers Sprint, Daily Meeting, Planning Game, Planning Poker, Onsite Customer, Open Space, Process Miniature, Iteration Planning, Review Meeting, Retrospective, Scrum of Scrums, and Collective Code Ownership. Every topic covered was great but I am only going to discuss one- Open Space. Since I left the electronic engineering field I have not had an office with a door except at my home office. I have sat at tables where all the printers were for the office. The printing noise wasn't bad, but the people standing around talking, waiting for the slow printers, was a problem. At work I am in a cube that is noisy 25% to 75% of a given day. I share it with one of the main application support guys on our team, and he often has a line waiting to see him. While they wait I am an open target for them to kill the wait time talking to me. To help a little bit I turn off my phone's ringer. Company policy is to always answer your phone, but 98% of the calls I get are salesmen calling about a product I needed to research. Another thing about the office is they keep it hot in the winter and hot in the summer. They keep it around 76-78F, but I have seen the temperature at a screaming 82F. I have to keep a fan blowing on me and by the end of every week my eyes are wind burnt and bloodshot. My chair I have at work has me going to the chiropractor. They were going to buy us new chairs, but discovered they were too expensive, and we aren't allowed to bring our own chair in. I work from home on Mondays. My home desk provides me twice the area I have at work. I have the room at a cool 68F. I have a great ergonomic chair. If I get a call I can put it on speaker phone, instead of having to hold it to my ear with my shoulder. On average I would estimate I get 20 - 80% more work done on Mondays than any other day of the week because I have the isolated environment I need to think. To get hold of me people IM, email, or call if needed, but I can queue them until I am done with what I am working on. At the office if you don't answer an email right away they come to your cube and interrupt your thoughts. The author highlights the fact that different people thrive in different environments, and that an open space environment is not a good environment for everyone. The author does another excellent job of pointing out the pros and cons of each topic in chapters 7 and 8. He covers a ton of topics in each chapter. In Chapter 7 he discusses Agile technical practices which include Agile Daily Build and Continuous Integration, Pair Programming, Coding Standards, Refactoring, Test-First, and Test-Driven Development. Chapter 8 covers Agile artifacts. They include Code, Tests, User Stories, Story Points, Velocity, Definition Of Done, Working Space, Product Backlog, Iteration Backlog, Story Card, Task Card, Task and Story Boards, Burndown and Burnup Charts, Impediment, Waste, Technical Debt, Dependency, and Dependency Charts. His discussion of User Stories is right on the money. He does a great job of highlighting the good in them, while also bringing to light their deficiencies. I have seen the exact issues he points out on every Agile project that used them. Chapter 9 is a review of some of the more popular Agile methods. The author takes a look at Lean Software, Kanban, XP, Scrum, and Crystal. I think this is a great chapter if you want a high level introduction to the methods, what the 'Big Idea', as the author puts it, is behind each method, and an honest assessment of each one. Chapter 10 discusses dealing with agile teams. It is very short and deals with two topics. The first topic is "Trust us, agile solves everything", which was the theme of a recently written IBM book author by the IBM agilists. I agree 100% with the author when he says "This is not very good advice to give to managers, who are entitled to more caution from such a venerable company." The second topic the author discusses is the either what or when fallacy. Agile teams will tell you when you can have it, or what you can have, but won't give you both at the same time. The author does a good job of arriving at the conclusion that it is possible to do both, when you can have it, and what it will do at that point in time. The last chapter is where the author lays it all out on the table. He lists the different agile practices under the headings of the bad and the ugly, the hyped, the good, and the brilliant. Do yourself a favor and read the book before turning to this chapter. There are a lot of good reasons presented throughout the book that leads the author to his conclusions. This book is mandatory reading for anyone involved with Agile processes. You are doing yourself and your team a huge disservice if you choose not to read this book.

Agile!: The Good, the Hype and the Ugly

Agile!: The Good, the Hype and the Ugly