Tim Ottinger

Thanks to everyone.

Be sure to check out the free samples at the pragprog site and the prototypes at the blog.

Enjoy the cards and thanks for the opportunity to converse here.

Best wishes.
Tim Ottinger
http://agileotter.blogspot.com/

Thanks for having us. We had a good time chatting about the book with everyone. Remember that we can still be followed at AgileInAFlash.com, and individually at our own blogs (mine is agileotter.blogspot.com).

Congrats to the winners! We hope you find your copy useful.
Tim

s mangal wrote: Unit testing is critical for all projects, agile and non-agile. Lack of formal QA makes it all the way more crucial for agile projects. In my experience, UT is one of the hardest things to enforce upon a team specially when there are lot of junior people who may not equal appreciation for UT as their senior counterparts. And than there are those who may agree in principle but fail in day today implementation. Business pressure to squeeze last minute feature also hurt this. Are there better ways(tools/processes) to keep team motivated to keep writing good quality/coverage UT.

-Shailesh

I think that the key is between "keep team motivated" on one side v. "to enforce upon a team."

Typically the practice is self-sustaining and self-propagating once it's started ad people are pairing, because it makes the code so much better and saves you from making big mistakes several times a day (or at least several times a week). People start to expect it from their teammates, and they get grumpy when new code doesn't have tests.

That being said, some people won't do it. They either won't test first, won't test after, won't automate tests, or won't test at all. Often it's a matter of knowing how, but sometimes it's just stubborn refusal to learn or practice the techniques. Often people feel that testing their code is beneath them, or not worth the time to invest in doing it. They should be given a little time and exposure to the benefits of testing, but eventually they need to either get on board or find a different team to ride with.

The last-minute-feature syndrome is a different problem, but it does highlight that if you don't have good support for your team then you can get squashed. See my "platitudes of doom" write-up: http://agileotter.blogspot.com/2009/08/platitudes-of-doom.html Really short iterations are helpful if your product owners are getting "buyers remorse" and wanting to swap some hot feature in instead of waiting. That's what agile is about. Keep the iterations short enough that they don't have to wait very long to change their minds, only a week or two.

Jeff Langr wrote:Here are a couple blog posts on the topic:

http://langrsoft.com/jeff/2011/02/is-tdd-faster-than-tad/
http://langrsoft.com/blog/2008/07/realities-of-test-after-development-aka.html

Not to forget http://agileinaflash.blogspot.com/2009/02/why-pout-aka-tad-sucks.html

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.

Mohamed Sanaulla wrote:On a lighter note: I have seen Tim and Jeff providing in depth replies to the queries here. And they yet managed to put their ideas in a concise form on the Flash cards

Yes. It was HARD WORK. Worthy work, really.

Mohamed Sanaulla wrote:

Jimmy Clark wrote:No, it is not dependent upon technology. Agile is a methodology for creating technology, i.e. software.

By technologies I meant- Programming language/ technology using which the software is built.

No, it's not dependent on a stack. Values, principles, planning, iterating, teamwork, etc (most of what constitutes Agile) is completely independent. You could be agile in Assembly or Basic or Prolog or Whitespace if you wanted.

When it comes to the technical practices there are biases. Some languages have been built up to make agile work easier than others, though I've seen it done in languages you might not choose for the purpose.

There are advantages to using languages which already have acceptance test and unit test frameworks, but you can always build your own. I've seen them for C, C++, Python, Smalltalk, Java, C#, PHP, and even SQL.

There is additional advantage if refactoring editors are available (smalltalk, java, C#, others).

If the languages run quick build/test cycles it's easier to get the rhythm going, so php, smalltalk, java, python, ruby have advantages there.

People are doing TDD in functional programming languages these days. It's different there, but that's not too surprising.

Finally, there are frameworks and libraries that can complicate testing. If you have an ORM (as most of us do) then you might have trouble keeping the tests fast because of dependency on the database. It's troubling, but we do it all the time. I've seen rails programmers do a lot of work in cucumber without unit tests when their work is really configuring some rails component instead of writing new code. Django expects to stand up a blank database for running tests, instead of testing quickly without a database.

samarthya saurabh wrote:
Probably it is not just about the ONE - team working one project but when knowledge is the key and a resource expertise might prove valuable to some other projects, his time needs to be borrowed and that is when the resource is reluctant may be because he is thinking of the task and the sprint. This is not always the case but yes I have certainly seen that.

Oh, well then no problem after all. Since you go by velocity and yesterday's weather, then your people should help anyone who asks. We used to have a rule, "If someone asks for help you cannot say no." Since developers are always being pulled out to help other people, it is "normal" and the velocity adjusts for it. Provided you don't have individual assignments you're responsible for (a smell), velocity absorbs all the normal jitter in the system. It's a pretty simple, smart system.

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.

Sai Hegde wrote:I have been using Agile programming methodologies for a while, and more recently switched to a newer organization.
As you say this is one of those 'stable' companies very reluctant of any change... How would you go present a cost benefit effectively using agile through the product lifecycle.

I tend not to. Mind you, I'm usually called after the decision is made. I'm not primarily a salesman by nature.

But maybe this is one of those martial arts moments. Maybe look at the problems they actually have, and start bringing in the practices and values that will help them address those problems. Quality low? More pairing, TDD, automated testing. Hard to get releases out? Continuous Integration, whole team practices. Predictability of releases? Iterations and velocity tracking w/ burn-up (or burn-down). Specification? Collocated customer, ATDD, iteration demos. Stressed out and nothing getting done? Reduced WIP and the kanban board.

I can't say too much about how to sell them, but I suspect that meeting their needs might earn you more political coin than presenting an argument to the PTB.

OTOH, Esther Schindler and others have done this very thing and written about it. http://www.softwarequalityconnection.com/2011/01/selling-agile-to-the-cfo-a-guide-for-development-teams/

Best Wishes,
Tim Ottinger

Mohamed Sanaulla wrote:Did Jeff and Tim mention the advantage of Flash cards? One can circulate it among friends easily, and carry along to read while waiting in queues.

A disadvantage? People might loose the cards which they borrow

Yes, which is another reason we pushed the price so low. You shouldn't have to buy new decks every other week, but when you do it is good to know that it's $15.00 or less (depending on quantity and retailer).

Mind you, it would not make me up$et if you purcha$e $everal deck$ every week.

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.

samarthya saurabh wrote:
Assuming there are a set of tasks and they are not completely related but, eventually when the feature goes live these tasks will have to interact. So considering an individual developing a task with relative independence has to interact at times with peers just to ensure the requirement or expectations are laid out for the members who will interact with his coded module. He has to interact with Test teams to make sure information is well conveyed. This is all because of lack of documentation (Zero documentation about design) and parallel development. A developers shoulders a responsibility of completing a task on time and in all probability might be reluctant to give the time required. If he does he cannot account it in any specific task, because these discussions takes time, sometimes too much. (I hope I am able to clarify)

So you mean that the developers' time is not accounted for in the estimates? That's a different problem than I thought.

1) Agile does not require us to have zero documentation about design, it only reminds us that it is not the best way to share information.
Typically the whole team will talk through the story before estimating, so there is a meeting about a feature where everyone gets
on the same page. Then if something changes, any team member in the bullpen can stand up and discuss the change.
We might still have whiteboard sketches, mockups, and the like. It's there if it helps everyone in the room understand how
the change works. I remember one successful agile team who had a meter-wide mockup of the screen in the room with
sticky notes on it. It helped them stay focused on the work.

2) Does the whole team make the estimates? It almost sounds as if you are bound to someone else's time expectations.
If you are underestimating as a team, try rounding up. Development should not be leisurely, but it should not
impoverish developers or writers or QA team members. At the end of the iteration, everything has to be done
and shippable (whether shipped or not) so the process has to work for everyone.

3) Do you track velocity? If you measure how much is totally shippable in an iteration, and plan by "yesterday's
weather", underestimation smooths out quickly. When the iteration is a near thing, the team will have a tendency
to start rounding their estimates up a bit. They hit their stride in a few iterations.

4) Is there some tracking and reward system that punishes (or fails to reward) the individual if they help others?
Anything that pushes against teamwork is non-agile, since agile values teamwork (interactions) so highly.

Some of these things are mentioned in our teamwork cards. In the card titled "is your team circling the drain?"
we mention:
* Individual work assignments
* Piles of unfinished work
* Work assignments given under the table
* Empty ceremonies
* Neglect of quality practices
* Guarded speech

Of those, your initial question had me questioning the first two.

Regardless, a few questions to bring up in your next retrospective:
> Do you have enough teamwork to thrive (not just survive) without documentation?
> Are you swarming tasks so that each is finished as early in the iteration as possible?
> Is the estimation working for everyone, or does it pit one against another?

samarthya saurabh wrote:
Tasks are assigned to teams? I am not sure I understood it correctly. As in practice we as a team take up stories and tasks are assigned to individuals on voluntary basis, is it not the proper way?

If team members are each working alone on a task, then it's not the right way. The idea is to be "swarming" the tasks to get them done as well and quickly as possible. If each team member takes on a task and is solving it solo, then it's probably not what is intended. It's hard for a team to do if each is responsible for a different part of the work, because then stories tend to be completed in the last day of a sprint, and that's really hard to deal with.

Actually, I prefer if all the stories are _not_ assigned to individuals at the start of the sprint. I like the task cards to be placed on the wall, and picked up voluntarily. Developers should choose how to tackle each of them. I prefer them to be in priority order if there is a clear priority to them. This way, the team has the most flexibility to self-organize instead of racing one developer against another. It also leaves more room for non-programming team members to be involved.

samarthya saurabh wrote:

Tim Ottinger wrote:
1) It sounds like your stories are too large. We have a card or two on breaking them down.

The story usually is cut down to almost a feature requirement, but with a defines set of tasks, sometime related and sometimes un-related or by-products. How to decide if the story is too large? We just put down T-Shirt sizes to it and yes we do have Large, Medium and small as the sizes. What should be an optimum sprint size? Is it decided before hand or should it be based on the stories we tend to include or number of spill overs we have?

A story should be small enough to be completed within a few days of a sprint. It should be a slice of a Minimal Marketable Feature. One goal is to have almost half the sprint finished (shippable) by the midpoint of the sprint, and all stories completely shippable by the end. That's not 'coded' but coded, integrated, tested, etc since an agile team is everybody who works to make it happen (product owners, QA, developers, QC, sysadmins, tech writers, page stylists, DBAs, etc).

The ideal sprint size is "as much as you can deliver in every iteration for the rest of your life, sustainably." The best way to find that number is to measure your velocity and plan for no more than you did last week. We use "yesterday's weather" and "velocity tracking" to determine optimal size. If a story isn't completely ready to ship, we don't count it. So if we finished 8 points out of ten, the next sprint is an 8-point sprint. If we planned 8 and did 9, the next sprint is a nine-point sprint. Things tend to even out in a relatively short time.

This jump is to see 'velocity' in a new light. You're not measuring sprint speed, you are measuring capability. The whole team can only truly complete so much work per iteration, so you are trying to find out how much that is. Increasing the velocity isn't a matter of stepping on the gas harder, it's a matter of improving the efficiency of the team so that they are capable of more. It's a mental shift.

The analogy is optimizing by looking for better algorithms, instead of overclocking the cpu.


I hope I didn't take your question too far in this direction, it was just an observation.