Agile Development and Business Goals: The Six Week Solution

This book presents what the authors believe is an improved variant of agile software development, based on what they have been practicing.While the authors clearly understand the fundamental principles of agile, and apparently have used their variation successfully, I recommend that readers approach this version with caution.I'm not quite sure who this book is for, despite an introductory section that attempts to answer that question. If you are new to agile, this book doesn't provide a primer on the subject but assumes you have at least some familiarity with it. Thus it appears that the book is intended for people who have basic familiarity with agile but who have not perfected it and thus are looking for ideas to improve their game. However, if that is correct, the authors spend far too much time justifying agile and going over things that the reader would already be very familiar with.Having managed large software development groups myself for several decades, I share the authors' belief that agile development is the best known way to develop software. Even though my development groups consistently produce great results with agile, I am constantly looking for ways to improve, and thus was interested in this book. While I agree with the authors about agile in general, I am not convinced of the key elements of the variant of agile presented here, specifically:* A centerpiece of the authors' method is to pay developers a bonus at the end of each iteration if successful. C'mon, that is a method that works with pets but is demeaning to humans. The authors even tell us (correctly) that pay is not at the top of the list of developer motivations, so why put SO much emphasis on this? And with money riding on each iteration, it is human nature to game the system. Developers are powerfully motivated by pride (as this book points out), so why not make that goal of each iteration?* This book is pretty adamant about 6 weeks as the iteration length, yet that is generally thought to be at the very long end of what most successfully agile practitioner think is useful. I have found shorter cycles (2 - 4 weeks) to be much better, ironically for reasons that the authors feel are important: faster feedback, quicker discovery of whether you are on the right path, less distance to backtrack if wrong. The closer people are to their goal, the greater the sense of urgency people have, thus I think 6 weeks is too long.* While not a core tenet of this method, the authors discuss team size and seating arrangements. Co-location of teams is clearly a good practice, but they suggest that teams should contain roughly 12 people seated in a bullpen, which I think is far too large for cohesion and not necessarily the best layout, even if it were available. Even Baden-Powell (whom they quote) recommends "six to eight". And it's not made clear who is on the team, e.g. just engineers, probably QA and writers, but what about architects, etc? What is the job of the leader - head programmer, business leader, project manager, or HR manager? This whole area is pretty vague.One way I judge the return on investment for the time I spent reading a book is whether it contained any idea or insight that I will be likely to remember a year from now. In that regard, this book DID provide some value. The highlight for me was their assertion that "Software reflects the group the produced the software; if the company is dyfunctional, then the software is dysfunctional." While the rest of the book was generally a disappointment, this idea is a gem. I just wished the authors had followed up and elaborated on it, instead of making this statement at the end of a section and leaving it hanging.My advice:- If you are new to agile, don't use this as your introduction. Be sure to read something that gives you a firm understanding of agile principles first, then read this book - and THEN read some others.- If you are already practicing agile, you might find some food for thought here, but the key ideas of this variant of agile are not ones that I would recommend or adopt myself.

As a proponent of Agile software development, I acquired this book and read it with keen interest.In my opinion, agile methodology is the strongest method for managing software development today - applications are much more complex, and waterfall development simply takes too long to produce marketable software.The strengths of this book are numerous, but there is a strong focus on theory and convincing people who haven't really used Agile of the benefits of this methodology. Naturally, there are skeptics, and they would benefit tremendously from this book. Agile isn't for everyone (super small shops may not benefit from this approach, for example), but I believe that it is helpful in managing larger software projects.This book will help someone understand how to combine development & business goals using the agile methodology. The one weakness I found was from a product/project manager perspective - how does one prioritize a large feature backlog? That's always been a big challenge within the Agile methodology, and this book only tangentially touches on it.Regardless, it is a valuable & worthwhile book - I would recommend it for anyone thinking about converting over an agile methodology.

I guess the biggest compliment I can give a book like this is that I'm now a total believer in their system. The authors present a very compelling case for agile development using a 6 week development cycle. They do an excellent job of showing how their proposal will create high quality software, continuous improvement, improved visibility, and, most importantly, a strong alignment with business needs. This last one gets the most attention in the book, and is a goal that the authors have clearly identified as the highest priority.The six week cycle is an iterative process where a new version of the software is ready for deployment every 6 weeks. At the beginning of the cycle the various stakeholders and management negotiate on what features, bug fixes, and improvements will be included in that cycle's effort. This forces the stakeholders to figure out what's really important, and the developers can then focus on that. The developers have a significant percentage of their pay tied to completing all of the goals for each 6 week cycle, so they are incentivized to complete it. The business gets a constantly improving product every 6 weeks, and the marketers, sales people, and customers are all aware of the regular release schedule in advance. No feature or bug fix is ever more than 11 weeks away, and the most important things are always prioritized. Changes in requirements, scope, or any of the other myriad of changes that are part of life in software development can be easily worked into this process.The target audience for this book are the managers and business leaders, not the developers themselves. The authors try to cover everything you'll need to build this type of development group - hiring, hierarchy, managing change, compensation, automation, testing, scheduling, meetings, transition advice, and workspace layout.

I work as a tester for a CIS department that does a lot of homegrown applications. We don't really do software for the public to use so our focus is different from what is described in this book.That said, the way that the authors frame their 6-week solution is something that we are working towards in order to make software (and hardware for that matter) development and deployment much smoother.I enjoyed this book because it described Agile in a way that I could understand by breaking it down to a 6-week period. Not only could I understand where the developers and managers were coming from, but I could also see my role in the process.For more feedback on this book, I gave it to a friend who is an IT manager. He too liked the layout of the subject matter. He could see how it could be useful for software developers. He also found it easy to understand.Overall, I would recommend this book for anyone who is interested in Agile and even if one doesn't go to Agile, it was still very interesting in how to develop a plan for any hardware or software deployment.

This is a book that can't decide what message to deliver. The title would lead you to believe that it intent is to present a new software process called 'The 6 week solution'. However, the material in the book seems to be a combination of a bloated consultant marketing brochure, an overview of problems with software development, an overview of development tools, and finally the 6 week solution. Those that have been involved in software for any length of time should already understand the problems with developing and delivering software, and they should understand the tools at hand to assist in delivering. Those interested in quickly understanding the 6 week solution should read chapters 4, 5, and 12. Those 3 chapters contain all of the detais necessary to understand the 6 week solution. If you are brand new to softare development, then this may be an interesting read. But you will need to filter the bloated consultant hype from the real details. For those who have been involved with software development for several years, you may consider spending your money on a book that has a clear focus on the message that it intents to deliver.