Amr Elssamadisy

Hi guys,

There are many, many books on Ruby. What makes yours standout?

Thanks - Amr

[edited to add title so this thread makes sense after the promo is over]

First of all, thank you to everyone who participated. I hope that you enjoyed the conversations as much as I did.

So, if you do end up picking up the book and if you do find the book useful, I'd really appreciate that you spread the word. I'm a new author - certainly no Martin Fowler (yet) - and am doing my best to make sure that people know about the book and can use it in their day-to-day work. So anything you can do, a blog entry, recommend to friends and/or clients, or share with a local Agile group, an Amazon.com review, etc... would be terrific. This is, of course, only a request.

Thanks in advance and take care!

Thanks everyone, it was a pleasure.

If anyone would like to know anymore about the book drop me an email [email protected] .

Hello Rajesh,

The Chapter i would be interested is �smells� It is a very general heading under crafting and adopting strategy.

Well, the part of the book that contains smells, is basically a catalog of common smells in organizations. If you download chapter 5 you will see smells mapped to practices that help alleviate them. Furthermore, each pattern has a 'smells' section that has common mistakes that many teams make - for an example check out the Done State pattern available on the Agile Journal.

I would like to know what are the authors thought around �gearing up business/customer for agile development�. As in case of agile, business involvement is more as compared to traditional methodologies.

I'm not quite sure I know what you mean, but I what I understand is "how do you interact with the business when you are gearing up for Agile?" If that is so, then you speak their language - speak of business value and results that you will deliver for them. That is *the* main thread in the book.

Do documents really keep knowledge? No - they get stale.

There are ways to mitigate the damage and keep the knowledge:

1 - Automated test suite - especially around requirements.
2 - Pair programming
3 - Using workshops during requirements and design to spread the knowledge
4 - Evocative documents instead of representational documents.

I believe that, Agile is also about team behavior (change to be agile) as much as it is a methodology.

Agreed 100%.

How do we infuse Agile behavior into the team who have been doing non-Agile methodology for ages and make them appreciate the good things about Agile.

Umm... that fills a book. I think there is one by a guy named Amr Elssamadisy - Agile Adoption Patterns Also Christopher Avery's book - Teamwork is an individual skill - is a good foundation and so is Mann's and Rising's Fearless Change. (So it fills 3 books).

For a good number of team size, going Agile would it be good? are there any exercises to appreciate Agile methodology.?

Yes, Agile has been used successfully from teams of 1 to I believe 800.

The team members are, obviously, frustrated by this - it leaves them feeling like they are just taking blind stabs at trying to meet sprint objectives. The mantra is turning into: "I don't have any development tasks to work on". As the unofficial scrum master (not recognized, but doing that role), how do I get the team members to go beyond the roles that they feel they were hired for and work as scrum team members? How do I help them see that we all have to work on every/ any task on the backlog - whether it involves writing code or not? (maybe I just answered that question on my own... )

This one is simple but not easy. You can't change other's behaviors (sorry, don't we all wish we could?) But the very best reference I have for this is Avery's "Teamwork is an Individual Skill".

A good idea would be to run a reading circle around the book, or better yet, bring Avery in to teach Knowledge Team Leadership. Human dynamics are the basis for any high performance team.

Good luck Amr

Hi Clyde,

Both of your questions are great, I'll address them in different posts. The first on:

1. The product owner is absolutely unwilling to commit. The "assigned" scrum master (assigned, but not really a pig; more of a chicken) enables this by allowing the product owner to put user stories like "As a product owner, I need to have the best web site for my users." into our sprint backlog. This scrum master is a CSM; and the product owner has been to training. I am not sure how to try to help him get beyond this behavior - and really not sure he's amenable to it! Any suggestions?

As you're painfully seeing, training doesn't mean change of behavior or actual understanding and adoption of new beliefs and values.

To start off with, you have a very difficult problem and there are no guarenteed solutions. But here are some issues:

1) You cannot change anyone's behavior, so don't even try. You can only change your own.
2) What you can do is step back to business values and process smells that your agency has. Why did you start doing Scrum? Was there a reason other than 'it is the latest and greatest?' There probably was. So, you may be able to have a conversation around 'is Scrum as we are practicing it meeting our goals?' That is the starting point. If the people you want to affect can see the problem themselves, then you have a chance of change.

Some good resources are:

Manns and Rising's: Fearless change
Avery's: Teamwork is an individual skill
and a new guy - Amr what's-his-name's: Agile Adoption patterns

Do you think developers often get "blind" when using an agile method?
They tend to think that the process/method solves almost everything(?)

Unfortunately, many do, when their goal is to 'be Agile'. 'Being Agile' should never be the goal, producing results to help your organization build better software is.

Ones whose eyes are on the right goal use Agile as a means to an end and usually don't fall in that trap.

That sounds exactly like what I need for my situation.

I think that is why I wrote the book as patterns. None of it is made up - all of it is based on true stories, looking back over the past 9 years with scores of Agile practitioners (other than myself) sharing their knowledge and experience. If you take a look at the acknowledgments, they are very lengthy because so many people shared their experiences to bring this book to fruition.

Actually that was my query.that's fine.
but I got some what clear idea from your explanation.

Sorry Ganesh

Sure, check out my first book which is freely downloadable from InfoQ. Test Driven Requirements is defined.

It is also known as Story driven development. And is very related to Behaviour Driven Development (BDD).

How about:

Erich Gamma, the author of design patterns and the head of the eclipse project. In this 3 part series he discusses many things about how his team works and how they use many Agile principles and practices.

Or Martin Fowler, author of Refactoring and many other great books,

Or Microsoft, Google, Yahoo!, and other leading edge companies that use this development technique.

The list goes on and on. If you would like, check out the Cutter Consortium, as they have an independent practice and journal dedicated to Agile development.

Part 1: Thoughts about Software Development 1
Chapter 1: Learning Is the Bottleneck 3
Chapter 2: Personal Agility for Potent Agile Adoption 13

Part 2: Crafting an Agile Adoption Strategy 21
Chapter 3: Business Value 23
Chapter 4: Smells 29
Chapter 5: Adopting Agile Practices 37

Part 3: The Pattern Catalog 53
Chapter 6: The Patterns of Agile Practice Adoption 55
Chapter 7: Goal 61
Chapter 8: Cycle 65

Part 3.1: Feedback Practices 69
Chapter 9: Iteration 71
Chapter 10: Kickoff Meeting 77
Chapter 11: Backlog 81
Chapter 12: Planning Poker 87
Chapter 13: Stand-Up Meeting 93
Chapter 14: Done State 99
Chapter 15: Demo 103
Chapter 16: Retrospective 109
Chapter 17: Release Often 115
Chapter 18: Co-Located Team 119
Chapter 19: Self-Organizing Team 125
Chapter 20: Cross-Functional Team 131
Chapter 21: Customer Part of Team 137
Chapter 22: Evocative Document 143
Chapter 23: User Story 149
Chapter 24: Use Case 153
Chapter 25: Information Radiator 157

Part 3.2: Technical Practices 161
Chapter 26: Automated Developer Tests 163
Chapter 27: Test-Last Development 173
Chapter 28: Test-First Development 177
Chapter 29: Refactoring 183
Chapter 30: Continuous Integration 189
Chapter 31: Simple Design 197
Chapter 32: Functional Tests 203
Chapter 33: Collective Code Ownership 219
Chapter 34: Pair Programming 223

Part 3.3: Supporting Practices 229
Chapter 35: Coach 231
Chapter 36: Engage the Community 235
Chapter 37: Reading Circle 239
Chapter 38: Workshop 245
Chapter 39: Classroom Training 249

Part 3.4: The Clusters 255
Chapter 40: Agile Iteration 257
Chapter 41: Communication Cluster 263
Chapter 42: Evolutionary Design 269
Chapter 43: Test-Driven Development 277
Chapter 44: Test-Driven Requirements 285

Part 4: Case Studies 293
Chapter 45: BabyCenter 295
Chapter 46: Company X 305

Part 5: Appendices 321
Appendix A: Pattern to Business Value Mappings 323
Appendix B: Pattern-to-Smell Mappings 325
Appendix C: Getting the Most from Agile Practice Patterns 327
Appendix D: Further Reading 331

Bibliography 333

Index 339

Have you run into organizations that are so entrenched with their practices that they cannot successfully adopt agile practices thus are doomed to repeat their crisis driven deliveries?

Good and uncomfortable question. First of all, yes I have, there are many failed adoptions out there and I can't say I have *the* answer, but I've been forming a the beginnings of one over the past year or two.

Let me come at this from the side instead of directly:

1) I had an aha! moment (well maybe it took a few days) at Agile 2008 this year. And that is, that we really can't change anyone other than ourselves. A coach's job is to 'reveal the system to itself' and then let the system itself decide what it wants to do. Some systems/teams/organizations are in their slow decline towards death/change/rebirth and that maybe right for that team. Those teams, no matter what you show them will continue on their way.

But that doesn't mean that all teams are hopeless and you should just give up. The best way to do things is to show them what's wrong. And the best way to do that, is to guide them so that they see the problem and call it out themselves - it doesn't help for us to call out the problem. Once the problem is seen and called out, then we can have a constructive discussion about practices.

2) There is a foundation of human dynamics that all transformations - Agile or otherwise -are built upon. And if those foundations aren't there, no team will change to their benefit. In touchy-feely impediments to Agile adoption we consider/address just your question about what things can stand in the way of good adoption and how can we see it.

Hope this helps in some small way - Amr