program selection system

Agile evangelists frequently skip the realities of the world. This is especially true when it comes to estimation. It often appears as if authors and presenters live in a world in which the customer is always a deep-pocketed in-house resource, with an abundance of confidence in the development team.

The realities, however, is that whether doing in-house development or contracting, the customer expects estimates for the development work. Potential benefits have to be weighed against estimated costs.

This talk deals with why estimation is crucial also in an Agile world.

In the playground world of software development, Agility has cool shoes and the latest gadgets. Testing has asthma and sticking plaster on his glasses.

Does testing have anything desirable at all to bring to the party? This discussion-based track proposes that testers bring something at odds with Agile approaches; disbelief, cynicism, pessimism. It is by defeating these that the software shows that it is genuinely ready to meet the real world.

Can one truly be an ‘agile tester’? Would that be a good thing?

** End of 90-word summary **

When do you choose to do Agile software development? Why do you think you’ll be more successful using Agile than other methodologies? We believe the IT industry is in the middle of a midlife crisis and Agile is its symptom. Strangely enough, the IT community is operating on a very limited set of historic information which may lead us to solving the wrong problems. Perhaps it’s time to admit that Agile is similar to a 45 year olds’ brand new red convertible that proves he is still alive.

After three and a half years of using Scrum and still providing inconsistent quality and not getting better, we are embarking on an attempt to improve by using Lean ideas and modifying our Scrum implementation. For some time now, our attempts to make Scrum work for us have mostly failed. Scrum out of the box, in a company with over 100 developers and testers, was not working as expected. This presentation is a report of our efforts to improve our Agile approach by using Lean and other ideas.

Over ten years ago, Joe Yoder and I opined that, while much attention had been focused on high-level software architectural patterns, what was effect, the de-facto standard software architecture had seldom been discussed: the Big Ball of Mud (http://www.laputan.org/mud/mud.html).

It has become, God help us, our best known work. And, somewhat to our amazement, since then, no one has ever undertaken to dispute this premise.

Most discussions about Agile begin and end with debates over whether it’s the best way to build software. The bedrock principles of Agile explicitly subsume all other priorities to the production of working code.

Tired of the misperceptions and misconceptions of Agile? Let’s do something about it! This session will discuss the commonly held misperceptions and misconceptions of Agile along with some suggestions for enhancing our message to minimize this issue and stop the continued propogation of misinformation.

Since I’m a tester, things to do with questioning appeal to me. As one of Jerry’s (Weinberg) Kids, I’m remind myself frequently that no matter how much it looks like a technology problem, it’s always a people problem.

Not convinced about Agile? Attending because you were sent? Do you feel like a fish out of water? Curious, but it just doesn’t make any sense at all? Does it feel like Agile goes against everything your experience tells you is the right thing to do? Convinced of some aspects but skeptical of others? This session will be a facilitated open forum to discuss your objections, doubts, counter-examples and horror-stories.

Also, if you are interested in helping to answer the objections, then bring your answers, conviction, and positive examples.

There is so much focus these days, and at Agile2008 especially, on “scaling Agile”, and it bothers me. There is something about that term that leaves a bad taste in my mouth. Why does everything always have to get bigger? Isn’t the giant distributed team phenomena (and adding more and more people) the thing that caused the need for Agile approaches in the first place?