As individual contributors ourselves (Tim and I move between coaching and doing often), we use the cards to help ourselves in our day-to-day development work. We'll use the cards as references and reminders, and stick them around in convenient places. We also will hand a card to someone else on our team and let it explain itself (so we don't have to repeat ourselves for, say, the fiftieth time on some of the pitfalls to watch out for when pairing).
Many of the cards are centered around basic practices in agile, including acceptance test design, unit testing (via TDD), mocking, refactoring, and so on--things that should provide some immediate benefit to individual contributors. Many of the other cards will give you information about how you can best contribute to an agile team, and what a better team might look like.
If it's agile... well, my view of agile done right is that it makes for a cool, kick*ss team where everyone works together, not off hiding in their cube and fearing the negative repercussions from a failing project. I'm not sitting in lots of meetings debating documents. I'm working on real, high-quality code most of the time, enjoying the continual feedback from getting green on my unit test run, and being proud of shipping software that provides what the customer is asking for. I'm learning something new every day, particularly in the area of good software design. I'm also building up my resume, not just pigeonholed into a small horizontal slice of the architecture.
I wouldn't talk about it and do it if it weren't both enjoyable and productive.
That, of course, applies only to the places where they "get it." That's one of the reasons we wrote the deck. There are far, far too many bastardizations of agile that can be just as painful as the alternatives.
visu nallamaru wrote:Well when i asked the question i was having Agile methodology in my mind , but now this discussion leads to different question how "Agile in A Flash " is different from Agile ?
As Tim indicates, the intent of the card deck is to capture a large number of concepts and techniques that are known to be associated with agile.
This also hints at another topic, which is the definition of agile itself. Far too commonly, a team will pick one of these practices, and proclaim themselves agile because they have adopted that practice. Unfortunately, they're missing a lot. Please read through our other posts (and blog) to get a sense of why.