Anyone involved with Agile hears that Scrum is the most popular project management method within the umbrella of Agile practices. But Jim Coplien (one of the chief founders of the Design Pattern movement) argues that Scrum’s root is really not from Agile, but rather the Toyota Production System (TPS). I’ve heard him say this in various lectures, but in this interview he states this very directly:
For now I have hope that the TPS ideals, and particularly as they are manifested in Scrum, can show teams how to marry complexity with planning. I think it’s important to point out that agility and TPS often have opposing foci and, further, that Scrum is more about TPS principles than about agile principles. Agile was a software-specific manifesto penned in 2001; Scrum goes back to 1993 or 1994. We can say that agile came from Scrum, very late in the game — not vice-versa. More realistically, they both emerged from a growing realization in the 1990s of the need to support complex system development. Scrum emphasizes the systems thinking components of such changes and I hope those prevail in the intermediate term.
I actually agree with this and had actually written about this in one of my earliest articles for Gantthead. What do you think? Do you agree with this assessment or not?
As Agile practitioners, our focus is mainly on things like how to break chunks of work down to manageable pieces, optimize and guide the performance of the self-directed teams, etc., but those are all items related to the focus of the work, the teams and the methods and not much on the emotion involved to allow that work to be done right in the first place.
Like it or not, our emotions play a large if not largest part in the success of our projects. The central idea in Agile of facilitating a collaborative and learning environment is predicated on the emotional stability of the management and teams involved and if this emotional aspect is not stable, then it WILL drag down the performance of your project no matter how well people “do” Agile correctly.
So it was nice to read this article on the Harvard Business Review on the need for “Emotional Agility”, for as the article states:
In our people-strategy consulting practice advising companies around the world, we see leaders stumble not because they have undesirable thoughts and feelings—that’s inevitable—but because they get hooked by them, like fish caught on a line... We regularly see executives with recurring emotional challenges at work—anxiety about priorities, jealousy of others’ success, fear of rejection, distress over perceived slights—who have devised techniques to “fix” them: positive affirmations, prioritized to-do lists, immersion in certain tasks. But when we ask how long the challenges have persisted, the answer might be 10 years, 20 years, or since childhood.
Clearly, those techniques don’t work—in fact, ample research shows that attempting to minimize or ignore thoughts and emotions serves only to amplify them. In a famous study led by the late Daniel Wegner, a Harvard professor, participants who were told to avoid thinking about white bears had trouble doing so; later, when the ban was lifted, they thought about white bears much more than the control group did. Anyone who has dreamed of chocolate cake and french fries while following a strict diet understands this phenomenon.
Effective leaders don’t buy into or try to suppress their inner experiences. Instead they approach them in a mindful, values-driven, and productive way—developing what we call emotional agility. In our complex, fast-changing knowledge economy, this ability to manage one’s thoughts and feelings is essential to business success. Numerous studies, from the University of London professor Frank Bond and others, show that emotional agility can help people alleviate stress, reduce errors, become more innovative, and improve job performance.
The idea of “emotional agility” is a great one and one that should be discussed and articulated more in the Agile community. I know as hardcore software engineers who currently dominate the Agile industry that you will perceive such things as “touchy-feely” topics that have no real bearing on your Agile projects, but consider that this is the most essential component of who we are as human beings and if Agile is such a proponent of a more “human-centric” approach to managing projects than this topic must be addressed.
This may be a topic for which I write a more detailed article!
This article from GCN seems to indicate that its use (or misuse) was the cause of the deployment fiasco.
More than anything, reading the details in the article suggests that Agile was definitely not used effectively (obviously from the results!) or properly. The front-end system design and deployment was done in a incremental and iterative fashion, but in this instance there was so many complex dependencies that more rigorous analysis and upfront planning should have been done.
I've personally seen these type of situations happen where the adaptive, flexible processes most effective for an Agile deployment are not applied at the appropriate situation. For large, very complex systems, a more systematic use of planning is often necessary then during the deployment, utilize Agile's principles of "inspect and adapt". This is the most effective and optimal combination of traditional and Agile most suited for these kinds of projects.
It will be interesting to see how this all works out!
Looks like a brand spanking new Scrum standard has hit the scene and it is titled "A Guide to the SCRUM BODY OF KNOWLEDGE" (SBOK). I usually keep up with this stuff, but I had heard nothing about this and the only official ScrumBOK I know of is a short guide written by the two founders a few years back. If you go to the Amazon page where the book is being sold, you will see a whole lot of readers ripping on it and it seems it was neither sanctioned by anyone officially affiliated with Scrum. I dug around and found this blog that outlines a heated exchange between Ken Schwaber and the author of the so called "official" guide. Here's an excerpt:
A group called ScrumStudy has published a book, Scrum Body of Knowledge, also calling it a Scrum Guide. It is posted on Amazon. When it was first pointed out to me, all of the reviews were five star. I bought a copy to see what was so great. First, it had extended the Scrum Guide where Jeff and I define Scrum from 17 pages to the 340 in the book. Second, it simply threw together every known practice about agile around Scrum and created a methodology which (their words) is appropriate for any project of any size in any industry. Whew. Worse, the book was written by thirty or so people, none of whom are active in the Scrum or agile community.
I went in to look at the reviews, unsure how other people in the Scrum community could view this as useful, particularly with such glowing comments. I found that all of the people were from the same country where ScrumStudy is located (India) and that most had never reviewed anything on Amazon before. Amazon reviews were being gamed.
I emailed some friends and we entered what we thought of the book. The lead author of Scrum BOK, Tridibesh Satpathy did the following:
1. Objected to my review (see below for the review and his objection) and had it removed.
2. Had his friends write more positive reviews.
If anyone here knows amazon and can help, please do so. This is an absolute corruption of Scrum principles and values, and is an abuse of amazon. Also, if you want to flood the book with negative reviews, I won’t object.
Tridibesh Satpathy, whom I have never met or communicated with (nor any of his co-authors or reviewers), removes the heart, soul and values of Scrum with this book. Singlehandedly, he attempts to turn Scrum into a formulaic methodology that can be used without thought or empiricism. The Scrum Guide that defines Scrum (http://bit.ly/1ixDnJK) is 17 pages long. Tridibesh et al have added every known practice, technique, and defined gated process to it to create a 300+ page monument to the failures of predictive methodologies.??You can pick up this book, apply it, take the certifications, and feel comfortable that everything is in place. It isn’t. Tridibesh et al have never seen your organization, your projects, your context, or your goals. How can they possibly believe that they can formulate a solution for you???I might have once believed that arrogance prompted this effort, particularly since none of the authors or editors are known in the agile community. However, experience has taught me that this is purely driven by a need for money. Studied from all angles, the is a money making scheme that should be avoided by those who understand the basis of agility, empiricism, and lean thinking.??As the first step in lean thinking, to identify and eliminate waste, throw out this book and avoid its authors.??Ken Schwaber?co-developer of Scrum, signatory to the Agile Manifesto, founder of the Agile Alliance, Scrum Alliance, and Scrum.org??Scrum on!
How Tridibest got it removed:
Scrumstudy support says:
This review is completely inaccurate and unethical, and should be removed by Amazon for the following reasons: ?1) This review is inappropriate because he works for competition Scrum.org (http://www.linkedin.com/in/jessehouwing). He wants to promote books from people in his organization (i.e. Scrum.org) and to discredit the books written by Scrumstudy. So this should not be allowed by Amazon as per “Promotion of illegal or immoral conduct” – Objectionable Material.?2) He has not read the book (this is not an Amazon Verified Purchase); hence how can he comment that the book is not relevant and call it a `sham’??3)This person is only interested in selling books from his organization and from authors who work for his organization (and does not provide any specific reason why SBOK is not good except that the book discusses concepts which he is not familiar with). Here this person is a direct competitor with SCRUMstudy and is posting negative reviews about SCRUMstudy for his personal financial benefits. So, it contains inappropriate content. ?4) SCRUMstudy.com is a very reputed organization for teaching Scrum globally. The Scrum Body of Knowledge (SBOK) was written by 18 authors who are expert Scrum Practitioners and is being widely appreciated in the industry. The SBOK was reviewed by 25 experts and draws from the combined knowledge and insight gained from thousands of projects across a variety of organizations and industries. This whole review seems to discredit SCRUMstudy and the Scrum Body of Knowledge (SBOK) for the benefit a competitor (Scrum Alliance) for financial benefits. ?5) We will request interested students to do a free introductory course about Scrum from SCRUMstudy.com (which includes the first chapter of SBOK, instructional videos and a simple real-life Scrum case study) and judge for yourself about the quality of the courses offered by SCRUMstudy (instead of reading through negative reviews from vested interests and competitors). The first chapter of the SBOK is available for you to view in SCRUMstudy.com or in Amazon.
I wanted to post the whole exchange to place it all in context, and if anything, what this indicates to me is that due to the explosion of certifications and everyone wanting to jump on the standards bandwagon to make a quick buck that we are going to see more of this unfortunately.
Sadly it diminishes the legitimacy of our profession leaving people looking to get credentialed and those hiring based on them to be confused and worse, suspicious of the whole process.
As we get close to Halloween, it is fitting that we revisit one of the most famous software development articles by Frederick P. Brooks, Jr. titled “No Silver Bullet Essence and Accidents of Software Engineering” published back in 1987. It was an interesting and still relevant metaphor he used about the “werewolves” that can make your projects:
Transform unexpectedly from the familiar into horrors. For these, one seeks bullets of silver that can magically lay them to rest… The familiar software project, at least as seen by the nontechnical manager, has something of this character; it is usually innocent and straightforward, but is capable of becoming a monster of missed schedules, blown budgets, and flawed products. So we hear desperate cries for a silver bullet--something to make software costs drop as rapidly as computer hardware costs do. But, as we look to the horizon of a decade hence, we see no silver bullet. There is no single development, in either technology or in management technique, that by itself promises even one order-of-magnitude improvement in productivity, in reliability, in simplicity.
If we fast forward nearly 30 years after the article was written (which is equivalent to almost a hundred years in IT years), can we say that we are better off than the time Brooks wrote his article? Wasn’t Agile thought of (or often marketed) as the “silver bullet” that will wipe away all those software project werewolves?
I think we’ve made a lot of progress since then and Agile has been a great framework and method, but my honest opinion is that it is in no way a silver bullet and to be fair it was never created to be such. But like a lot of things that gets created to solve a problem and achieves a high level of success, people in their excitement with the results over hype it, with the evangelist and disciples trying to apply it everywhere and inappropriately.
But the most enlightening part of the article was section related to “the development of approaches and tools for rapid prototyping of systems as prototyping is part of the iterative specification of requirements.” This basically is the core tenant of Agile and Brooks takes it further by advocating software that grows organically, for “each added function and new provision for more complex data or circumstances grows organically out of what is already there.”
By using this ingenious metaphor, it makes us view software not just as some static system but one that grows organically which entails the need for nurturing and the right environment to promote and encourage that growth.
I couldn’t think of a better way to describe the Agile process then this article that was written well before Agile as we know it came into being.