Customer Reviews

Becoming Agile: ...in an imperfect world

5 star:		(11)
4 star:		(0)
3 star:		(1)
2 star:		(1)
1 star:		(0)

 

 

I will be honest and say that this is the first "work related" book that actually captured my attention to the point that I would sit and read whilst my loved ones were enjoying their sweet slumber (and obviously blog about it).

This book is highly informative; being neither condescending, nor pushy and over-bearing on the way that agile adoption should be approached. Without intending to be a partisan; I would even go as far as saying that it is more than recommended reading, it should be required reading for anyone thinking of migrating to agile; recent adoptees of agile or anyone in between.

From the first chapters that guide us through the principles (I loved the annotated 12 principles of the Manifesto for Agile Software Development - section 1.1.2) and the descriptive text on the "paradigm shift from a plan-driven mentality"; to the readiness assessments and the importance of obtaining executive support; through to the population of the product backlog and on to the first iterations of an example company adopting Agility in their software development process.

There is no substitute for actually reading the book, which is a must; however various chapters and sections drew my attention more than others.

Section 1.1.2 - The agile principles:

Although the manifesto has been analyzed and described on various blogs and books; the descriptive text for each principle was really handy when evangelizing on agile and is a good primer for anyone new to the subject (and possibly even for those of us who have been practicing agile).

Section 1.2 - A paradigm shift from a plan-driven mentality:

This is a must read for those of us who have come from years of waterfall and attempts at changes to "traditional" methodologies or processes. The section highlights the change in mentality that is needed to move from more traditional ways of software development to a leaner, more agile way.

Section 2.4 - What does it look like when a team "becomes agile":

With comparative plan related diagrams of how the change is made from waterfall to agile and the breakdown of how that transition was made; is comforting for those that have made the change as well as those that are thinking about/planning the change.

Section 3.2 - The different flavors of agile:

This section has a really good breakdown of strengths and weaknesses of the two foremost agile methods; Scrum and XP.

Section 3.3 - Create your own flavor to become agile within your constraints:

When I first started in agile there seemed to be a common mantra that permeated throughout the meetings and blogs that effectively stated if you weren't doing it exactly by the book, you weren't being agile. It is completely preposterous.
How can the same agile development methods used by a web advertising company be cookie-cut for a software company writing client server applications in a strong regulatory environment? The answer is - it can't. There will need to be some adaptation. After all isn't that one of the principle concepts of agile; what is the point of having Sprint Retrospectives to adjust and tweak a process in a constant attempt to improve? This section is a must read for those that are constantly being belittled or set-upon by "those in the know".

Chapter 4 - The fitness test: all about readiness assessments:

Although I have not had the opportunity of actually performing this exercise; having read through the chapter it is very informative and goes in to great detail on how a company can be measured for it's fitness to adopt agile development.

Section 6.3.1 - Tough questions:

I liked this section because of the example of typical questions asked by the team that will be adopting agile development and the possible answers to give about the migration process.

Section 7.1.1 - Attributes of a good coach:

This section contains a very good breakdown of the attributes that should be sought when selecting an agile coach. The following sections go into further detail about training and coaching; as well as details on the interaction with managers and stakeholders.

Section 7.3 - Creating a team with an agile mindset:

This section explains what ingredients are needed to create a sound agile team; from "Culture and roles" through to "Characteristics that influence individual performance".

Chapter 8 - Injecting agility into your current process:

Just the title alone gives the idea of the maturity of mind that the authors have when confronting a company wanting to adopt agile development methods. From documenting the existing process (not everyone has it written in stone and perhaps not all aspects of the company are actually doing what it says in the process hand-book); to deciding what to keep and what to change.

Chapters 9, 10 and 11

Discuss the selection of a pilot project and the team that will be on the pilot project. This is very informative for those companies that have made up their mind to move to agile and are looking around for the best project to guinea pig.

Section 12.3 - Feature cards compared to...:

As a Scrum practitioner it was interesting to read the comparisons between feature cards, user stories, use cases and functional specifications.
Section 12.5 - Hard-copy vs. electronic cards:

I found this section particularly useful as it highlighted the benefits of both, using SharePoint as an example of the electronic format. Although the idea is to keep it as simple as possible I am an advocate of using technology where possible - more than anything to cut down on the waste generated by so much paper; but also for the fact that you can view the information at any time (this is effective when trying to explain PBI or SBI to persons not located in the same area).

Chapter 13 - Prioritizing the backlog:

This is a subject that I find is the least covered in discussions with peers (both at work and outside) and it is really helpful to see the suggestions posed throughout the chapter. Peppered with examples of a product backlog and how to handle various items; this chapter is a good starting point for broadening the discussion.

Chapter 14 - Estimating at the right level with the right people:

I still remember being asked to estimate for a particular requirement when I still felt that I did not have enough information to do a sound enough job of it. How different it is when you are doing it as a team and everyone can voice their thoughts on the matter. This chapter is particularly useful for those still in "traditional" methods or recent adopters of agile methods. Of particular interest is section 14.1 - Contrasting traditional and agile estimation techniques and section 14.2 - The importance of whole-team estimation; both of which ease the reader into the subject that is quite explanatory with regards to the estimation process in agile.

Section 16.3 - Identifying and estimating tasks:

This section has a nice "call-out" titled "Task assignments aren't permanent" that describes how the early stages, specialist people will be suited to certain tasks and how with the passage of time and acquired experience in an agile environment team members will become more capable of taking on varied tasks that perhaps were out of their realm in the beginning.

The latter chapters of the book, starting with chapter 20, describe the process of adapting to change and learning as we go. Section 20.1 - Common reasons for adapting (i.e. make those tweaks mentioned earlier); describes common issues that crop up and some ways that teams adapt to the situation described.
Chapter 22 is particularly interesting with a detailed explanation on how to prepare and manage the retrospective.
Chapter 23 is a must read for companies that have successfully started a pilot project and are now looking at how to push across the divide and bring about change at an enterprise level.

Becoming Agile by Greg Smith and Ahmed Sidky describes how to start your journey to start agile development. The target audience for this book are people who are just starting to look at Agile development and currently have issues. However, personally, I would not recommend this book. The book contains recommendations that I would personally not follow (I'm not that they wouldn't work) and a better alternative might be Mike Cohns new book "Succeeding with Agile" which will be published later this year.

The book contains eight parts and it follows one case study of "Acme Media" throughout the book. Acme media is implementing a small pilot project using agile development. The first chapter of the book describes agile development, the agile manifesto and introduces the background of the case study. The second chapter in the book covers the start, that is the preparation work that the authors recommend. Chapter 4 in this part discusses a assessment test for assessing your agility. The authors recommend to use the test and based on that decide what practices to start with. Chapter 6 describes one of the their key recommendations, which is to form a "core team" which defines the agile process to be used by the organization.

Part three describes the real kick-off of the development. Chapter 10 covers a feasibility phase where the a smaller team will assess if the project is even feasible and after that will be a "gate" or a go/no-go moment so that the project can be killed early. It suggests creating a feasibility study guide to do your feasibility and the authors provide some examples. Chapter 11 talks about creating the initial agile pilot team.

Part four is called "populating the product backlog" where the authors start describing their variant on user stories called "feature cards." It wasn't clear to me why the authors decided to re-invent or rename other agile practices. The chapter describes creating the feature cards and putting them in the product backlog. Chapter 13 discusses the prioritization and chapter 14 the estimation of the features (which seems to be the wrong order to me, but the authors insist on not wasting estimation time). The chapter explains planning poker and story point (wonder why they are not called feature points...)

Part five then discusses the planning (or scheduling) of the project and fills all the requirements to the iterations. Chapter sixteen then starts with the iteration planning of the first iteration. The authors suggest first some modeling and than task breakdown and already doing task assignments. They not that people often recommend differently, but then they assume that it because in these teams "everyone can do everything." It feels like the authors think it is either pre-assigning all tasks OR everyone can do everything... and there is no middle way.

Part six discusses the iteration itself and covers some of the agile engineering practices, but only on a somewhat shallow level. The part starts with chapter 17 which still recommends to run an iteration 0 (even though their project has only 2 iterations!!) Part seven discusses change and adaptation. Chapter 20 describes the adaptations of Acme and why they did it. Interestingly enough, the authors suggest a "adapt week" between their iterations. Then chapter 21 describes the final delivery.

Part eight, the final part, describes how the core group can take the result of the pilot and try to roll out agile in the whole company.

Why I wouldn't recommend the book? There are two main reasons for this. The first is that the book doesn't feel well researched at all and the language is somewhat too 'popular.' For example: page 6 about the Agile manifesto talks about "a group of authors writing a document." Unless you interpret 'authors' very broadly, this is just not true. On page 33 the authors describe weaknesses of Scrum. I'm probably not the most neutral person about this, but still the sentence "Scrum doesn't want specialists" seems like a really odd conclusion and seems to me simply untrue. Another example, on page 248 the authors equate exploratory testing to "company-wide bug stomp." They claim "exploratory testing tries to make sure the software doesn't accidentally do things it isn't supposed to do." If I simply google the internet, then the definitions of exploratory testing are quite different. As a final example, in chapter 22 on retrospectives, the authors do not at all refer to any of the retrospectives techniques described in other places (like the popular "Agile Retrospectives" book).

The second reason why I wouldn't recommend the book is because I personally disagree with a lot of the recommendations done by the authors. These are too numerous to all mention, but to just pick a couple. Having a separate team define the 'process' for the Agile team seems odd to me. Doing a pilot project with only 2 iterations is somewhat short from my perspective. Especially as things like velocity aren't that useful on projects like that. The iteration 0 and the adapt week are things I wouldn't recommend and certainly not on a 2 iteration project. The description of retrospectives are certainly not how I would do them myself. The focus on engineering practices is somewhat shallow. And the list goes on and on. Fair enough, this might be just my opinion against their opinion, but because of this, I would personally not recommend this book.

I decided to go for two stars. Three stars would mean the book does what it is suppose to do, and I don't think it does. One star would be too low as the idea of the book is good. Also, I like the way the authors have build up their case study and the way they describe a project based on their own experiences. The book is not all bad or useless, just not the book I would recommend. Therefore decided to go for two stars.

The book has a nice high level overview of what is required to become agile. I was hoping for more details on the different tools, but I still enjoyed the book.

I've read many a Project Management books and have also complimented my skills by taking courses in the local Universities. And, invariably what's taught and/or written about is the "ideal world" in regards to working on a project and delivering a given solution...

-- Ideally the analysts will capture the requirements -- 100%
-- Ideally the requirements will drive the time/effort to develop
-- Ideally the solution is delivered on time and...Hopefully...
-- "Ideally" the customers are 100% percent satisfied

Never...ever in my 15 years working in the professional, technical environment...has the ideal world ever existed.

If only more of my customers and technical counterparts adopted the concepts detailed within this book -- and basically rethink how projects should be approached and retool their own methods -- If this had happened more projects would have finished successfully and the team would've been better prepared to deal with issues as they were identified.

Great book...It's a must read!!

I was fortunate to get access to an early version of this book, and as I write this I'm actually going through the book jotting down some key points as our development and project management teams will be meeting to talk about how we can adopt a more agile approach to software development.

We've borrowed a few agile concepts from back in the day, but we're looking to take our game to the next level. And the problem with a lot of the old school agile material is that it is very theoretical from the perspective of agile purists.

Well I don't know about you guys... but it's not that simple. Change takes time, and there are business realities to factor in. You can't take a 5000 ton cargo ship moving at maximum speed to suddenly turn because you want it to.

Businesses have a momentum to them, and to introduce change requires shifting that momentum. This is where the book Becoming Agile is a critical asset to folks like me (technical management), because it addresses these realities head on and provides a practical and viable approach from a business process perspective on how to get your teams developing in an agile manner.

I really can't praise this book enough, and I'm aiming to get everyone in our project management and software development teams a copy of this book, and make it our guide.

Becoming Agile in an Imperfect World by Greg Smith and Ahmed Sidky is an excellent reference for those looking to become Agile. Like most development shops, my company's projects were constantly being pushed back by late-breaking changes in requirements, and like most companies, we didn't respond well to these moving targets. We weren't agile enough in our development. Hearing that that one of the tenets of Agile development was embracing change, I picked up this guide.

I have tried looking at several articles and online papers on the Agile methodology, but never finished the reads with a sense of where to start - what's my first step? Becoming Agile doesn't let you down in that sense. The authors provide a thorough explanation of Agile values, principles and practices to put the reader on a solid foundation. Then they walk you all of the planning you should go through before you undertake your first project - something I feel is overlooked in most of the other discussions I've read.

When it's time to have that kick-off meeting and start development, the authors are once again ready to take you step by step through the process. Smith and Sidky have helped countless companies become Agile, and their experience shows through throughout this book. One of the most valuable pieces of information in this book was the idea that Agile is not an all-or-nothing proposition. Some things may not work for me, or my team, but that won't prevent us from becoming more Agile.

Becoming Agile in an Imperfect world has provided me with all the information and tools necessary to lead my company to a more Agile development environment. I would highly recommend this to anyone who is thinking about becoming Agile. My only complaint (almost enough to remove a star from my review) is that it's a bit too much information. This is a long read - you won't feel very agile trudging through this long text. But ultimately it's worth it, and worth 5-stars.

If you are considering moving to agile read this book first. It will provide you with a well tested and reasoned approach which will minimize the risk and prepare you for the changes that are required. However, if you are already agile and looking for the technical details of how to implement TDD or other agile practices you will want to look elsewhere.

I read this book because I run a one man consultancy, where agility is a job requirement not an option. However, in the next 6-12 months I plan on hiring two additional staff members, including a developer. How do I maintain that agility as my team grows? Can we be agile if we don't work in the same location, or even state? Will we need to adopt an entirely new process to become agile? What do I need to document, organize, or create to support a more formal agile process?

Several things set this book apart from the crowd:

its focus on the process of becoming agile rather than he use of a specific tool or practice (e.g. TDD or scrum),
the case study which shows how to move the theory into practice and
the forms and worksheets shown throughout the book (I wish these were available as a download).

This book not only helped me answer the questions I started with, but forced me to ask and answer many more along the way. I now have a more agile practice and would highly recommend this book to anyone looking for the same.

This book is a much needed addition to the body of literature advocating agile / lean methodologies. As a developer, I've read lots of books that describe agile practices in detail but give only cursory treatment to how to bring agile into a workplace. In my experience, it's way too common to see organizations laboring under heavy waterfall methodologies because they're afraid or mistrustful of agile, or they describe their process as "agile", but it's poorly structured, lacks discipline, and periodically devolves into total chaos come release time (hence the fear among the waterfall set). I wish they all would read this book and give serious consideration to its recommendations.

What sets this book apart is that it doesn't pretend that just by reading a book or two you'll be ready to Scrum your way to process nirvana. Instead, it is very realistic in its presentation of the challenges of implementing an agile methodology successfully. It describes the need to obtain buy-in from key stakeholders (esp. the people who control the purse strings), managers, developers, analysts, QA. It describes migrating to a new methodology as a process in itself and advises beginning with an evaluation of your current methodology to determine what to throw away, improve, or keep. And it advises retaining the services of an agile coach who is a skilled consultant / practitioner of agile methodologies who can teach your team how to function within a successful agile implementation.

But before you start doing any of that, the book helps you build a clear understanding of what a successful agile practice looks like by presenting a case study. The level of detail in the description of the methodology is outstanding. It's comprehensive without being legalistic or dictatorial. A key principle of the book is adapting the methodology to the culture of the organization and the needs of a typical project. It presents a Scrum-centric methodology but includes coverage of agile concepts and practices from other methodologies as well (especially XP).

The organization of the book is strong with the first two parts laying the groundwork and preparing for challenges of adopting agile and the remaining parts being the description of the methodology and its implementation. The chapters are brief and tightly focused. The book's attention to real-world issues is perhaps better than any other technical book I've read, and the authors definitely come across sounding more like experienced practitioners than academics.

The only thing that would make the book better is if the agile assessment in the appendix came in a smaller version that I could take to job interviews and ask prospective employers to fill it out. Any company wanting to attract and retain good talent should work to build the kind of teams and processes described in this book.

If you are in any way responsible for becoming Agile in an organization, read this account from the front lines. It will help you understand what is needed in terms of people, motivations, buy in and selecting a 'quick win' problem. For me, this book is largely about leadership and winning the kind of ongoing consensus that forshadows continuing success.

I read through this book after accumulating bruises in moving an organization to Agile. Both the author's description of what to do and what will happen if you do not resolve key issues are right on. Chapters 4 (assessment) and 7 (mindset) are particularly interesting. Chapter 4 could be more extensive but it covers so much that the principle weakness is that there is a lot of information jammed into a short chapter. There are external links provided to understand the depth of the how to assess readiness for Agile and I found that I needed that information. The topic is covered in chapter 4 and I may have just wanted more. Chapter 7 is excellent because it helps to focus on what (in my case) needs to happen in the leader's head to be successful. I found that these attitudes were essential to building effective, competent teams that consistently accept ownership of results. These attitudes are the keys, not the full list of what is required. What is important to me is that the chapter provides the short list, the ruler against which others are measured.

I am pleased if I learn one or two immediately applicable things from a book because I read a lot of books. The author has provided many of these nuggets and has shown why they are valuable based on his experience. You get the feeling that he has done this before and is providing his experience in the best spirit of lessons learned as frankly discussed in a retrospective.

I will re-read this book. I know I can extract and apply more from this account. The book is an excellent value and I hope there is a followup to help with how to change attitudes that do not measure up on the assessment.

In the foreword, Mary Poppendieck declare trumps: agility is not only a developers thing, it's not a magical recipe to apply in a normalization manner without taking into consideration enterprise and people's culture and knowledges.
Despite that, it's reminded that a fixed core is essential to the setup of an agile environment, summarized by the agile manifesto.

That's exactly what the authors try to cover in this book, very concrete and holding a lot of recommendations to help you setup "an" agile process which fits to your enterprise/project.
Becoming Agile is not another book to be classified in the existing ones handling agile practices, it's one of the rare writings which will go with you in the adoption and setup / migration to an agile process.
As a consequence, don't expect an exhaustive content on some particular agile practices (TDD, continuous integration, etc.) : plenty existing books already handle these topics very well.

What can you find ?
- some advices and tools to analyse your current situation
- a companion guide to build your dedicated agile process, and migration without fully challenging your legacy

After having introduced the agile thinking and projected on different economic and strategic angles a company has, the authors introduce the study case of a pilot project which will help to illustrate the talk all along the book during 9 steps of agile process adoption.

Although the book appears as theoretical, this fear is widely attenuated thanks to this study case which can be read very easily, like a story.
Moreover, the authors don't forgent to introduce a few tools, in particular a complete methodological guide to evaluate your potential to do the transition to an agile process.
We can also mention the Tradeoff Matrix (which illustrate well the necessity to identify and put an order on the constraints, so that only one will define the guidelines of your project organisation when you will face some hazards), the Feature Cards (and their computerized counterpart which would be manageable thanks to tools like SharePoint, VersionOne, or Rally), the Planning Poker, the Burndown Chart, and also the Progress Matrix.
By the way, I'm not forgetting the "CMMI" like model built for agile practices: the SAMI (Sidky Agile Measurement Index), an initiative of one of the authors.

This publication handles at once the problematic from an organisational point of view and from a practical one.
Thereby, while bringing some input to the reflection on difficulites in companies to have people adopt agile practices (the authors emphasize a chasm between the Early Adopters and the Early Majority), they suggest some solutions and a methodology (which begin by an analysis of a one's "potential" and a first contact through a pilot project).
This real Must Have, agilist's bedside book, reads very well and will companion you in your migration to agile practices, but well beyond in your daily working (or not only) life.