Agile In Flash - Questions on coverage and pitfalls

[Raghavan Muthu]

Hello Tim and Jeff,

First of all, Congratulations for having come up with an idea of doing something different in the book design itself. I surely agree with your saying that 'it is not at all book but a set of 5X7 deck of cards!". Indeed a new way of design and it would attract the people's curiosity.

I have few questions.

1. Though most of the places you had told that it serves a quick reference (of course people rarely get time to dig the tomes to get what they want), it is just a quick reference alone. However, if at all anything needs to be understood further, for sure they would have to pick up another book on Agile. In that case, it will NOT be a one stop solution. Right? OR other way around, how good it is for a new comer without having any idea on Agile? Will your book serve the purpose? Did you give a thought on this? I am not talking in the tone of criticizing. Just a point to be clarified.

2. I am unable to get the Table of Contents to get to know the coverage of the book. What and all the book covers? Is it just the general Agile concepts or anything specific to the practice?

3. I am sure you would have covered some Best Practices. Likewise, do you alert the readers on the pitfalls (there would be some pitfalls of course) which you think the people may prone to have it during the course of development ?

4. Though agile has been in practice for about a decade, still it is not completely ruling the software industry (as what I know so far). Correct me If I am wrong or not up to date. If so, what do you think is lacking to adapt the agile methodology? Is it just the belief and the guts in the people to break the traditional waterfall/RUP models and to adapt the new methodology ? or are there any other aspects? I am just curious to know on a personal front.

Thanks in advance.

Cheers,
Raghavan alias Saravanan M

[Tim Ottinger]

This is a collection of questions, so answers will be interleaved.

Raghavan Muthu wrote:
1. [...] In that case, it will NOT be a one stop solution. Right? OR other way around, how good it is for a new comer without having any idea on Agile? Will your book serve the purpose? Did you give a thought on this? I am not talking in the tone of criticizing. Just a point to be clarified.

It is not a one-stop solution. If someone wanted to learn agile on their own, Agile In A Flash would make good supplementary material.
See: https://coderanch.com/t/528246/Agile/Agile-Flash-it-beginners

Raghavan Muthu wrote:
2. I am unable to get the Table of Contents to get to know the coverage of the book. What and all the book covers? Is it just the general Agile concepts or anything specific to the practice?

It has four sections:
* The Idea (what is agile about, what is behind it, what values does it espouse)
* The Plan (how to prepare and run an iteration + troubleshooting aids)
* The Team (the agile practices and how they work + troubleshooting aids)
* The Code (how to change how you program, and toward what)

Each section has 13 cards.

Raghavan Muthu wrote:
3. I am sure you would have covered some Best Practices. Likewise, do you alert the readers on the pitfalls (there would be some pitfalls of course) which you think the people may prone to have it during the course of development ?

We provide smells and antipatterns, but only a few since there is so much to cover in so little space. One card is titled "Is Your Team Circling The Drain?"

Raghavan Muthu wrote:
4. Though agile has been in practice for about a decade, still it is not completely ruling the software industry (as what I know so far). Correct me If I am wrong or not up to date. If so, what do you think is lacking to adapt the agile methodology? Is it just the belief and the guts in the people to break the traditional waterfall/RUP models and to adapt the new methodology ? or are there any other aspects? I am just curious to know on a personal front.

A few different ideas:
* Large companies are attractive because they are stable. Stable companies don't go changing their model, hence the term "stable." ;)
* I think that Agile methods (including Lean, XP, and systems thinking like ToC) are a bit counter-intuitive which makes them seem a little too "crackpot" for some.
* Some people don't find the practices remotely attractive, or even tolerable
* There are shops that consider themselves so pedestrian that adoption of any method seems hopelessly overboard.
* The agile success factors (http://agileinaflash.blogspot.com/2010/07/agile-success-factors.html) are too counter to their culture.
* Not everybody had to do it this way. It's for those who choose it.

We have cards on organizational and individual objections to agile methods, focused on those that are overcome-able. Here are the blog versions:
* http://agileinaflash.blogspot.com/2010/02/organizational-objections-to-agile.html
* http://agileinaflash.blogspot.com/2010/03/personal-objections-to-agile-process.html

There may be many other specific objections we have not categorized.

[Jeff Langr]

Tim Ottinger wrote:

Raghavan Muthu wrote:
3. I am sure you would have covered some Best Practices. Likewise, do you alert the readers on the pitfalls (there would be some pitfalls of course) which you think the people may prone to have it during the course of development ?

We provide smells and antipatterns, but only a few since there is so much to cover in so little space. One card is titled "Is Your Team Circling The Drain?"

In addition to that team smell and in addition to the organizational/individual obstinance cards, we have a few other cards specific to anti-patterns and pitfalls:

Don't Get Too Deep in Technical Debt

Pair Programming Smells

Stop the Bad Test Death Spiral

Refactoring Inhibitors (what are the factors, not all obvious, that can cause a team to refactor less than they should?)

Test Double Troubles

TDD Design Smells

Many cards are focused on not just how to do something, but on how to do it well; for example, Agile Success Factors. Plus, most of the cards include tips buried within the text on back about 'what not to do.'

Jeff

[Jeff Langr]

I also just published a new blog entry that provides an index for all the cards.

[Jeff Langr]

Raghavan Muthu wrote:how good it is for a new comer without having any idea on Agile? Will your book serve the purpose?

Hi Raghavan,

As Tim mentions, this should not be the first exposure a person has to agile. Why not? Because it's very easy to mis-interpret bullet points and deliberately concise explanations.

However, a modicum of introduction to agile is enough for the cards to be useful. As a coach, I would certainly hand some of the cards to agile newbies, day one on the job. And anyone who's gone through a couple iterations on a real agile project knows enough to make use of the cards.

Regards,
Jeff

[Jeff Langr]

Raghavan Muthu wrote:4. Though agile has been in practice for about a decade, still it is not completely ruling the software industry (as what I know so far). Correct me If I am wrong or not up to date. If so, what do you think is lacking to adapt the agile methodology? Is it just the belief and the guts in the people to break the traditional waterfall/RUP models and to adapt the new methodology ? or are there any other aspects? I am just curious to know on a personal front.

Thank you, by the way, Raghavan, for the very good questions and for the congratulations!

Agile is being attempted in increasing numbers in a large number of Fortune 500 companies and in many smaller companies. Change is hard, however: First, a team and its individuals must admit that they can do better. That's a tough pill to swallow.

Agile threatens the classic command-and-control hierarchy that exists in a typical organization. Tim wrote a cool story for his blog site about "the bad old days" of programming (see Grandpa Tim Tells a Scary Story). He's received at least one very angry, petulant response from a responder who thought Tim was saying all managers were bad and should just go away. That's not true; however, done well, agile will create change in an organization, something that many people will find threatening.

General backlash to agile certainly exists. Too many teams tackle agile and do it poorly, garnering poor results, and of course then spread the news that agile sucks. Enough people just go along with whatever they're being told, whether or not it's true (did you hear that practicing test-driven development causes cancer in lab rats?).

As far as traditional development: I think most shops are more haphazard than anything, often mixing waterfall and agile concepts. Most shops that tried RUP and highly-structured waterfall approaches have realized that those are too heavyweight.

I think the most important thing to understand, if you're to try agile, is to realize that it's not just this set of practices that can be easily summarized with bullet points (despite our cards!). Success requires a thorough understanding of the agile principles and belief in them, most importantly the idea that we don't sit still and rest on any levels of success--we seek to figure out what's messed up every few weeks, adapt, measure again, and keep correcting course.

Jeff

[Tim Ottinger]

Jeff Langr wrote:
I think the most important thing to understand, if you're to try agile, is to realize that it's not just this set of practices that can be easily summarized with bullet points (despite our cards!). Success requires a thorough understanding of the agile principles and belief in them, most importantly the idea that we don't sit still and rest on any levels of success--we seek to figure out what's messed up every few weeks, adapt, measure again, and keep correcting course.
Jeff

Further clarification: Jeff and I are not "believe first" kinds of guys. We try things. We are true believers in the agile values, but this is won through experience.

[Mohamed Sanaulla]

Jeff Langr wrote:

Raghavan Muthu wrote:how good it is for a new comer without having any idea on Agile? Will your book serve the purpose?

Hi Raghavan,

As Tim mentions, this should not be the first exposure a person has to agile. Why not? Because it's very easy to mis-interpret bullet points and deliberately concise explanations.

However, a modicum of introduction to agile is enough for the cards to be useful. As a coach, I would certainly hand some of the cards to agile newbies, day one on the job. And anyone who's gone through a couple iterations on a real agile project knows enough to make use of the cards.

Regards,
Jeff

How about mixing these- Practices of an Agile Developer by Venkat and Andy Hunt and Agile in a Flash? Shouldn't these together give a good start in Agile Development.

[Jeff Langr]

Thanks for the book tip. I think that book is largely focused at programmers, otherwise we'd likely recommend it as a general text. We've suggested a couple other good companion books in a few other postings. (There are *lots* of other agile books out there...)

[Raghavan Muthu]

Hello Tim and Jeff,

Thank you so very much for you patience and the beautiful explanations.

I felt really happy on hearing the explanations especially on my question "why agile has not really been adopted in the software world". I do agree with you and thats what I too thought. Lack of knowledge and lack of completion is what driving towards the conclusion saying Agile is bad or agile sucks! Moreover, people are not dare enough to take risks. Great !! Being the author's verdict and with your expertise, I can convince the people in a better way.

Fact not to be denied, Yes, we too had been following a mixture of RUP and Agile! .

Thanks for the URL with the index cards which says the TOC! It is what I had expected.

Also that was a nice response for the question whether this book is for a beginner or not. It is very convincing and honest.

I am much impressed on your diligence and the interest you had shown towards answering the queries.

Thanks again

[Raghavan Muthu]

Tim and Jeff,

Have one more query just to add on to the list.

What is your view point on the story cards? Do you cover it on your book?

In my view, some extent story cards are more of the RUP documentation only. The way it is written is what it differs. Right?

[Tim Ottinger]

Raghavan Muthu wrote:Tim and Jeff,
What is your view point on the story cards? Do you cover it on your book?
In my view, some extent story cards are more of the RUP documentation only. The way it is written is what it differs. Right?

Related to user stories in "The Plan" we have:
* Reach Consensus on Story Priority
* INVEST in your stories
* Sail on the Three Cs (Card, Conversation, Confirmation)

These address stories, and mention the cards (sometimes prominently). The big deal about the story _cards_ is that communication with the on-site customer/product-owner/analyst/whatever is the requirement, not the card. The card
is a placeholder, a reminder to have a conversation and to get confirmation. The documentation is the acceptance
test, which we talk a bit more about:

* Acceptable Acceptance Tests
* Acceptance Test Design Principles

I think stories are important, and having a card is important, but what is on the card doesn't matter so much as long as it reminds you of the requirement conversation and you move quickly to acceptance tests from that conversation. It's really
just a token to move from the left of the card wall to the right otherwise.

I still remember how puzzled I was years ago when I told Dave Chelimsky that I had trouble fitting my requirements on the card, and he told me to use a bigger marker. He then told me it's a common agile punchline, because the answer is to put less on the card. It is only a token, not a document.

I think once you use a card as a physical token and not as a document, it gets easier to work with them.

[Jeff Langr]

Greetings Raghavan,

As Tim mentions, the story cards are simply placeholders, or tools. The word "story" is the important thing here. A story is something we tell people; the card is simply a reminder, a summary of that oral storytelling.

Story cards are not artifacts! Once you complete work on building a feature, the card is meaningless. You might think you could use it to track what had been done in a given iteration, but a 5-word summary of a several-day conversation (between customer and developers and other folks) scribbled on a card will not likely be meaningful to anyone six months down the road.

Instead, we get rid of the conversation piece, and replace it with something that documents how the system behaves once that new feature is in place. The best form for that document is a series of well-designed (see our card on Acceptance Test Design Principles) acceptance tests that anyone can easily read and understand.

Acceptance tests are the closest analogs to use cases (a tool popularized almost 20 years ago now), but with slightly differing granularities. The name of an acceptance test can map to the goal, or name, of a use case; it can also map to a much smaller slide of functionality. This is because features in agile are intended to be very small, taking only a day or so to complete. So someone might tell a story: "allow users to filter sort results by age." That's likely not an entire use case, it's likely an alternate path on a larger use case.

Otherwise, the focus is the same: Jacobson said you could produce user guides and documentation from well-written use cases. The same can hold true for acceptance tests (with a little assembly work), which have the vastly superior quality of eternal accuracy: As long as all your acceptance tests pass, you know that they describe how the system works.

Stories, on the other hand, are just conversations, and the memory of all conversations eventually fades from memory. The cards act as great tools while the story is in progress--they help us track things and remind us what we were talking about, but other than that, we should just recycle the cards once we deliver the corresponding features.

[Tim Ottinger]

Jeff Langr wrote:
Story cards are not artifacts! Once you complete work on building a feature, the card is meaningless. You might think you could use it to track what had been done in a given iteration, but a 5-word summary of a several-day conversation (between customer and developers and other folks) scribbled on a card will not likely be meaningful to anyone six months down the road.

+1 on Jeff's observation.

I did recently read about a team clearing a large wall space, and moving the cards to that space when they are deployed. In time they end up having many, many cards posted as a reminder of how much they've done together.