Agile 2008 Guide – Tuesday Evening

Agile 2008 is the premier conference of the Agile world. There are going to be almost 2000 participants and about 400 different sessions to attend. It means plenty of interesting conversations and a lot of activities to choose from. However, it also means that you have to make a choice between many different options. During the main part of the conference you have to choose between 40 to 50 different sessions.

This part of the guide covers Tuesday August 5, 1600 – 17:30 time slot. In the table below you can find links to the full description, author bio and the answer to the all important question "Why would you want to go there?" All the sessions with white background take 90 minutes, all the sessions with orange background take 180 minutes (and therefore continue from the previous slot), all the sessions with the light blue background take less, than 90 minutes.

If you feel that some summaries are inaccurate, please, comment – I will correct the mistakes.

You can find more information about the conference at http://AgileSoftwareDevelopment.com/Agile2008


Topic

Speakers

Why you would want to go there

Agile Estimating and Planning

Mike Cohn

Come to this tutorial if you want to learn how to use agile methods and still be able to plan months ahead.

Maven and Continuum – building an ecosystem for Agile builds and testing

Christian Gruber

Come to this tutorial if you are interested in getting or improving the build and continuous integration system for your Java projects. You will be able to follow the tutorial on your own laptop if you wish.

TDD Clinic: Ron & Chet

Chet Hendrickson
Ron Jeffries

Come to this tutorial if you want to see how test-driven-development works for XP gurus. They will develop a small program in front of you.

Clean Code Clinic: Ugly Tic Tac Toe

Patrick Wilson-Welsh 

Come to this tutorial if you want to feel the benefits and drawbacks of a good quality code on a real example.

The Agile Playground – Learning Games for the Agile Practitioner

Don McGreal
Michael McCullough

Come to this workshop if you are a coach who wants to learn how to efficiently convey concepts and principles of Agile with the help of games.

Beer Miles! The Product Owner Simulation

Robin Dymond
David Douglas

Come to this tutorial if you have to play a Product Owner role and would like to understand better how from a fluid business case to come up with a Product Backlog and continue to the first release.

Open Source Meets Agile – What can each teach the other?

Mary Poppendieck
Christian Reis

Come to this workshop if you feel like exploring the future. You will work on figuring out what open source methods might contribute to agile thinking.

Coaching self-organizing teams

Joseph Pelrine
Steve Freeman

Come to this tutorial if you are an Agile coach or a Scrum Master and want to let your teams self-organize, but they just don’t become self-organizing on their own.

Agile ?! ça ne marchera jamais chez nous !

François Bachmann

Come to this workshop if you speak French and understand the description.

Avatars of TDD: First Tests

Bill Wake
Naresh Jain

Come to this workshop if you are practicing TDD (or BDD) already and want to improve.

ET by Example: An exploratory testing experience

Erik Petersen 

Come to this tutorial if you are interested in how to apply exploratory testing effectively even in the presence of a large automated test suite.

Exposing the "devils" within – Agile taboos and other hurdles in a large organization

Jan-Erik Sandberg
Lars Arne Skår

Come to this workshop if in your large organization transition Agile suffers from the superficial approach and Agile principles are mostly ignored.

Storytelling Skills for Agile Teams

Rebecca Wirfs-Brock
Rachel Davies

Come to this tutorial if you would like to improve your conversation skills. You will learn how to apply story telling in your projects.

Diana and Esther’s Excellent Retrospective Adventures

Diana Larsen
Esther Derby

Come to this tutorial if you are running retrospectives and want to improve them.

Requirements-Driven Workshops for Large Agile Projects: Essentials for Product, Release and Iteration Planning

Ellen Gottesdiener

Come to this tutorial if you are struggling with starting the product, release or iteration. You will learn how to conduct the kick-off workshops so that they produced just enough requirements.

Agile and Paper Prototyping

Todd Zaki Warfel

Come to this tutorial if you want to learn how to avoid a lot of oversights in the product design with the help of efficient low cost tool – paper prototyping.

Agile by any other name does NOT smell as sweet!

Jennitta Andrea

Come to this talk if your organization is tempted to see agile as just a repackaging of old practices. You will learn how to see and to show the synergy of many subtle differences in Agile practices.

Trouble with component teams and an alternative

Bas Vodde

Come to this talk if your organization is big enough to make feature teams possible, but you don’t like the idea of component teams either. Bas has plenty of experience from huge organizations and will show you the third way.

Open jam

A chance to discuss what interests you most.

Scale Back: Small is Beautiful

Tobias Mayer

Come to this small workshop if you feel like the nowadays “scaling” hype is suspicious and would like to compare your point of view to the others’.

Agile is Groovy, Testing is Square

James Lyndsay

Come to this talk if you are a tester willing to understand how to work effectively in the Agile team.

Open source performance testing tools for the web

Paul King
Dalton Cranston

Come to this talk if you need to test your web applications for performance and not sure which tools are good for you.

Code Metrics & Analysis for Agile Projects

Neal Ford
Ram Singaram

Come to this talk if you want to measure your code effectively.

Live aid: participate in a real agile project at the conference

Come there if you want to feel the real agile team working. Note, that you might participate fully or drop for 10 minutes if you have a free time slot.

 

Handling Uncertainty in Agile Requirement Prioritization and Scheduling Using Statistical Simulation

Kevin Logue, Kevin McDaid

Wentworth

A Preliminary Roadmap for Research on Agile Software Development

Torgeir Dingsøyr, Tore Dybå, Pekka Abrahamsson

Wentworth

Panel: Issues and opportunities in research on agile methods

Frank Maurer, Robert Biddle, Torgeir Dingsøyr, Tore Dybå, Pekka Abrahamsson, Yael Dubinsky. Moderator: Philippe Kruchten

Wentworth

Fast & Predictable – So many Scrum Teams, So Little Time: Enterprise Release Management in an Agile World

Amy Farrow
Steve Greene

Come to this experience report if you are interested in integrating the work of many teams into frequent high quality releases.

Agile Deployment: Lean Configuration Management and Deployment Strategies for the Agile SaaS Enterprise

Robert Benefield 

Come to this talk if you want to implement agile method for Software as a Service. You will hear the Yahoo! experience.

Good Used Cars, Cheap Health Insurance, and Successful Consulting Engagements

Michael Nygard

Come to this talk if you engaged in the software consulting business either as a client or as a contractor. You will learn some theories behind the reasons of typical situations.

Agile Contracting

Rachel Weston
Chris Spagnuolo

Come to this workshop if you are involved into the business side of the organization. You will learn a toolbox for Agile contract design and will have a chance to discuss the experience of the other participants.

When Working Software Is Not Enough: A Story of Project Failure

Mitch Lacey 

Come to this talk if you are leading the company who works with the clients used to the fixed scope/price contracts. You will see how without a special care client may misunderstand pretty much everything in the approach even formally following it.

XP: My Greatest Misses 2000-2008

J. B. Rainsberger

Come to this talk if you want to know what is that difficult in being the agile coach.

Building High-Performance Agile Teams

Paul Hodgetts

Come to this tutorial if you are involved into building an effective team as a coach, manager or a team member. You will learn both concepts and techniques.

Business Value – Soup to Nuts

Andy Pols
Chris Matts

Come to this tutorial if you are on the customer side of a project (e.g. Product Owner) and struggle with identifying the real priorities and needs.

Money for Nothing and Your Change for Free: Agile Contracts

Jeff Sutherland 

Come to this talk by the Scrum co-author if you are involved into contracting and want see how how Agile can help earning radically more money both for you and your partners be it clients or contractors.

Postcard Patterns: An Agile Pattern Creation Process

Ian Swinson
Jason Winters

Come to this tutorial if you need to create patterns for whatever purpose, and would like to do it better.

How Did We Adapt Agile Processes to Our Distributed Development?

Cynick Young
Hiroki Terashima

Come to this experience report if you are going to apply Agile to distributed development. You will see what works and what doesn’t for the report authors.

Distributed Agile Outsourcing: Growing a Practice Together

Michael Vax
Stephen Michaud

Come to this experience report if you are going to apply Agile to outsourcing and would like to learn from successful companies.

Yahoo! Distributed Agile: Notes from the World Over

Brian Drummond
JF Unson

Come to this experience report if you would like to learn from huge internet company experience.

Working With Global and Distributed Agile Teams

Ken Pugh 

Come to this talk if you like learning from lectures. You’ll get a lecture about globally distributed team challenges.

Book Review: Fish!

Fish
I just finished reading a little book called Fish!. It’s subtitle is “A Remarkable Way to Boost Morale and Improve Results“. I’m always interested in management literature, and with a size of only 107 small pages, this booklet was simply too hard to ignore. There are quite a number of publications on the Top 100 list of Software Engineering Books that (more-or-less) deal with the same subject: how to improve job satisfaction (among software developers and other team members), and how to improve the quality of software delivered to customers.

Well, this is what Fish! has to say about it:

Choose Your Attitude
No matter what kind of work you do, your attitude towards it is your own choice. When you are working on some stupid project you have two choices: You can choose to be bored while doing mundane maintenance work on a 100-year old legacy application. Or… you can choose to become a World Famous Legacy Maintenance Superstar. Your attitude towards your project is your own choice.

Play
According to the book some people on a fish market had fun by throwing around the fish, and customers loved to watch. But everyone can choose to have a little fun while doing their job. Share positive energy with your co-workers, in a professional way, to make the work more enjoyable for everyone involved. Make the team that introduced the most bugs wear pink shirts for a week; have a monthly contest for the most beautiful single line of code; or steal the CIO’s business cards and use them for writing user stories.

Make Their Day
Engage your customers in your positive energy and goodwill. Make their day by letting them share in some of the fun. Don’t make fun of customers, have some fun with the customers! Make good on a bad release by sending your customer a picture of the team in pink shirts; let your users vote for the coolest feature ever devised; or ask them to contribute to your collection by giving you their CIO’s business cards.

Be Present
Make sure that you actually notice your customers and your co-workers. Be there for people by asking them what they need and how you might be able to help. Don’t wait for someone else to approach you with a question. Be the one that actively seeks out what needs to be done, and really listen to what people have to say.

These four principles are the core of Fish! (or at least my interpretation of it). Though the book is often described as a management book, the actual target audience is the team, not the manager. The team members are the ones to throw around the fish, and make the customers laugh.

How to ensure code quality?

I’m co-developing big Java project that does what it should do but lacks the style and conventions. The code is hard to read, understand and maintain – and it is Java! I’d like to write what I discovered in the code, project configuration and what are my recommendations on ensuring high(er) code quality.

In my previous post I mentioned tool called FindBugs that finds common Java problems that can occur during runtime and will be difficult to find and debug. One of the comments to this post opened my eyes to what I’m doing currently and how I can fix current status quo. And the comment was about PMD tool.

PMD
There is a tool called PMD which scans Java source code and looks for potential problems like: Possible bugs, Dead code, Suboptimal code, Overcomplicated expressions, Duplicate code.
PMD is configured in the project I currently contribute to but I was somewhat shocked that although the code is totally, absolutely crappy PMD doesn’t show any problems. Hmmmmmmm. I was shortsighted because I didn’t see the fragment invented probably by some kind of “genius”:

public class ... extends ... { // NOPMD

Well, the fragment in question is // NOPMD which tells PMD: “Don’t check this class”. It’s not funny!
Fortunately this was not the case for most of the classes. Nevertheless I still didn’t know why my PMD plugin is not alarming me about the problems. I checked whether it is enabled for my current project in Eclipse IDE. Voila! It was not! The guy who helped me configuring the project disabled it and when I asked why he said that if I enable it I will be probably unable to compile the project. It’s really not funny 🙂 Or…. is it?
Anyway – he was right! When I enabled the PMD for the project I was really unable to compile it…

No comments!

PMD problems
I’ve never used PMD before and I think that was a good choice. Why? I enabled it for some classes I worked on to see why people disable it – I hoped to find some clues. I didn’t wait long – actually I didn’t wait at all. Consider this snippet (class’ method – context is unimportant):

String value = (String) entry.getValue();

What warning could you get for this piece of code? I got this one: Local variable ‘value’ could be declared final. WTF?! OK – I added final keyword before value variable declaration to see what will happen. #$%&@! – I got another warning: Avoid using final local variables, turn them into fields. So, should I declare my local variables as final or not?!
Who configured this PMD? Or is it default configuration? I don’t care – with such warnings I really understand people who simply disable this tool – it’s insane!

Of course, everything is a matter of configuration but I’m already pissed off with PMD as a Eclipse plugin and am not going to use it anymore. On the other hand I’m always using PMD as a Maven2 plugin and it works fine – I used to get quite reasonable comments there (I’m not getting them anymore because they are already fixed 😉

Checkstyle
I’ve never used PMD before but I used Checkstyle instead (currently I’m using version 4.4.1). I was always very satisfied with this tool and it helped me keep many projects nice and clean (yep – I was the fascist in many projects kicking asses of other developers if they were writing ugly code :). I always used Checkstyle as a Eclipse plugin but recently I’ve also started generating Checkstyle Maven2 reports for our mavenized projects.
I’m attaching two XML files (I had to change their extensions to .txt) with Checkstyle configuration. One is for ordinary Java source files and the second one is more “liberal” for test classes. I worked on this configuration with couple of my colleagues from my previous company and we really think it’s the best you can get from Checkstyle (however de gustibus non est disputandum).
When you incorporate Checkstyle configuration in question in your projects be sure that your code will be beautiful – it can still do nothing 😉 but at least it will be well formatted and structured.

Recommendation
My very private recommendation and advice is to use…. both tools because they are complementary. Checkstyle only ensures the style of your Java code is standardized and “nice”. It checks white spaces, new lines, formatting, etc. (i.e. it looks on the code line by line). On the other hand there is PMD which not necessarily checks the style of your code but it checks the structure of the whole code i.e. it looks on the code from the “higher altitude”.
I would advise using Checkstyle as an Eclipse IDE as well as Maven2 plugin and PMD only as Maven2 plugin. In addition I would also advise using FindBugs as an Eclipse IDE plugin but I mentioned it already in the previous post.

Tools like PMD and Checkstyle will not ensure your code does what it should do (not even 0.1%) but they will help your team produce well structured quality code that will be much more easily understandable than before. Ensuring one code convention in your organization (whatever it will be) is always a good thing to do. And tools like PMD and Checkstyle help you make it agile way i.e. fully automated.
Belive me or not but in other companies I was able even to teach real Java-beginners how Java code should look like without spending with them any single minute. And they were producing pretty good Java code from day one. I was amazed!

PS. I’m using Eclipse 3.3.x IDE and some of the problems I encountered can be dead-issues on other IDEs.

10 Principles of Agile Project Time Management

Timemanagement
Project Time Management
is one of the nine knowledge areas of the Project Management Body of Knowledge (PMBOK). It deals with the definition of activities (what are we going to do), the sequencing of the activities (in what order are we going to do them), and the development and control of the schedule (when are we going to perform those activities).

Agile Time Management
Over the past couple of weeks I have been trying to find out what the main principles of time management are in the case of agile software development. I was able to distinguish 10 principles so far, and I will present them here for your convenience. With each principle I also include a reference to an online article that (as far as I can tell) nicely describes the ideas behind it. If you don’t agree with my list, or if you know some better reference material, feel free to add your thoughts!

1. Use a Definition of “Done”
How? Define what “Done” means and only count the activities that are Done.
Why? Prevent the build-up of hidden tasks (“technical debt”) that cost a lot of time to fix down the road.
See: The Definition of “Done”

2. Use Timeboxes to Manage Work
How? Set a start- and end date for a collection of activities, and don’t allow changes to those dates.
Why? Timeboxes keep people focused on what’s most important. Don’t lose time to perfectionism.
See: Time Boxing is an Effective Getting Things Done Strategy

3. Don’t Add Slack to Task Estimates
How? Don’t use scheduling and buffering of tasks. Add one buffer to the end of the timebox/project.
Why? All safety margins for tasks will be used (“Parkinson’s Law” and “Student’s Syndrom'”).
See: Critical Chain Scheduling and Buffer Management

4. Defer Decisions
How? Make decisions only at the latest responsible time. “No Decision” is also a decision.
Why? The environment may change, making earlier decisions a waste of time.
See: Real Options Underlie Agile Practices

5. Reduce Cycle Time
How? Iterative cycles should be as short as possible.
Why? Speed up the learning feedback loop, and decrease the time-to-market.
See: Lean Software Development: Why reduce cycle-time?

6. Keep the Pipeline Short and Thin
How? Limit the amount of work-in-progress, and the number of people working in sequence.
Why? Improve response times, speed up throughput.
See: Managing the Pipeline

7. Keep the Discipline
How? Prevent expensive rework by doing some processes well, right from the start
Why? Solving problems late in a project is more expensive than following proper rules early.
See: The Power of Process

8. Limit Task Switching
How? Prevent unnecessary task switching between projects, and prevent interruptions.
Why? Tasks get completed faster on average, and the human brain is bad at task switching.
See: Human Task Switches Considered Harmful

9. Prevent Sustained Overtime
How? Disregard (sustained) overtime as a way to accellerate progress.
Why? Lost productivity, poor quality and bad motivation among team members.
See: The Case Against Overtime

10. Separate Urgency from Importance
How? Urgent tasks and important tasks should not be done at the same time.
Why? The important stuff will usually not get done, costing you more time in the long run.
See: A 10 Second Guide to Smoother Projects: Urgent vs. Important

Agile 2008 Guide – Tuesday Afternoon

Agile 2008 is the premier conference of the Agile world. There are going to be almost 2000 participants and about 400 different sessions to attend. It means plenty of interesting conversations and a lot of activities to choose from. However, it also means that you have to make a choice between many different options. During the main part of the conference you have to choose between 40 to 50 different sessions.

This part of the guide covers Tuesday August 5, 14:00 – 15:30 time slot. In the table below you can find links to the full description, author bio and the answer to the all important question "Why would you want to go there?" All the sessions with white background take 90 minutes, all the sessions with orange background take 180 minutes (and therefore occupy the next time slot to be covered later), all the sessions with the light blue background take less, than 90 minutes.

If you feel that some summaries are inaccurate, please, comment – I will correct the mistakes.

You can find more information about the conference at http://AgileSoftwareDevelopment.com/Agile2008


Topic

Speakers

Why you would want to go there

Agile Estimating and Planning

Mike Cohn

Come to this tutorial if you want to learn how to use agile methods and still be able to plan months ahead.

Introduction to Lean Software Development

Alan Shalloway

Come to this tutorial if Agile adoption goes (or went) OK in your SW department, you feel that larger changes are needed in the whole organization and want to have some guidance.

Ten Terrific Transition Tips

Joshua Kerievsky

Come to this talk if you you are involved in guiding the agile adoption(s), especially if you are an Agile coach. You will learn “terrific transition tips” based on practice.

Open jam

A chance to discuss what interests you most.

Big Ball of Mud

Brian Foote

Come to this talk if you feel like listening to the reasons for the ugly architecture to exist despite all the books, Agile methods and design patterns.

Maven and Continuum – building an ecosystem for Agile builds and testing

Christian Gruber

Come to this tutorial if you are interested in getting or improving the build and continuous integration system for your Java projects. You will be able to follow the tutorial on your own laptop if you wish.

Mastering Selenium

John Tangney

Come to this tutorial if you are using Selenium and want to master it better.

TDD Clinic: Ron & Chet

Chet Hendrickson
Ron Jeffries

Come to this tutorial if you want to see how test-driven-development works for XP gurus. They will develop a small program in front of you.

Clean Code Clinic: Ugly Tic Tac Toe

Patrick Wilson-Welsh 

Come to this tutorial if you want to feel the benefits and drawbacks of a good quality code on a real example.

Advanced Test Patterns in C++

Bill Hanlon

Come to this tutorial if you would like to learn how to test drive C++.

Live aid: articipate in a real agile project at the conference

Come there if you want to feel the real agile team working. Note that you might participate fully or drop for 10 minutes if you have a free time slot.

Stories, Sketches, and Lists: Developers and Interaction Designers Interacting Through Artefacts

Judith Brown, Gitte Lindgaard, Robert Biddle

Research paper.

Utilizing Digital Tabletops in Collocated Agile Planning Meetings

Xin Wang, Yaser Ghanam, Frank Maurer

Research paper.

Agile Methods and User-Centered Design: How These Two Methodologies Are Being Successfully Integrated In Industry

David Fox, Frank Maurer, Jonathan Silito

Research paper.

Build Analysis: Questions Answered, Questions Raised

Adam Goucher

Come to this talk if you wonder what your automated build should really be for.

Software is a Princess, Another Mattress Won’t Help – Why Small Things Matter in Agile

Patrick Farley
Zak Tamsen

Come to this talk if you wonder why your Agile process adopted by the book doesn’t work as advertised.

The Agile Playground – Learning Games for the Agile Practitioner

Don McGreal
Michael McCullough

Come to this workshop if you are a coach who wants to learn how to efficiently convey concepts and principles of Agile with the help of games.

Beer Miles! The Product Owner Simulation

Robin Dymond
David Douglas

Come to this tutorial if you have to play a Product Owner role and would like to understand better how from a fluid business case to come up with a Product Backlog and continue to the first release.

Open Source Meets Agile – What can each teach the other?

Mary Poppendieck
Christian Reis

Come to this workshop if you feel like exploring the future. You will work on figuring out what open source methods might contribute to agile thinking.

Coaching self-organizing teams

Joseph Pelrine
Steve Freeman

Come to this tutorial if you are an Agile coach or a Scrum Master and want to let your teams self-organize, but they just don’t become self-organizing on their own.

The Pomodoro Technique: can you focus – really focus – for 25 minutes?

Staffan Noteberg 

Come to this tutorial if are into improving your team daily practices in the innovative ways.

Mirror, Mirror on the Wall… Why Me?

Portia Tung
Pascal Van Cauwenberghe

Come to this workshop if you want.. to know about yourself. Some kind of self-analysis session.

Agile ?! ça ne marchera jamais chez nous !

François Bachmann

Come to this workshop if you speak French and understand the description.

Avatars of TDD: First Tests

Bill Wake
Naresh Jain

Come to this workshop if you are practicing TDD (or BDD) already and want to improve.

ET by Example: An exploratory testing experience

Erik Petersen 

Come to this tutorial if you are interested in how to apply exploratory testing effectively even in the presence of a large automated test suite.

Exposing the "devils" within – Agile taboos and other hurdles in a large organization

Jan-Erik Sandberg
Lars Arne Skår

Come to this workshop if in your large organization transition Agile suffers from the superficial approach and Agile principles are mostly ignored.

Storytelling Skills for Agile Teams

Rebecca Wirfs-Brock
Rachel Davies

Come to this tutorial if you would like to improve your conversation skills. You will learn how to apply story telling in your projects.

Agile Communities in Japan

Tsutomu Yasui
Yukie Kushida

Come to this talk if you wonder what the Japanese Agile community is like.

An HR Perspective on Agile Careers in Corporations – Survey Results, Analysis and Forecast

Timothy Brown 

Come to this talk if you care about your Agile team careers and would like to know what kind of career ladder is possible in the Agile world.

"Un-assessments" using Agile Evaluation Framework – actions by the teams, for the teams

William Krebs
Per Kroll

Come to this experience report if you gather metrics, but they don’t really work for you.

Product management in an agile world

Steve Johnson 

Come to this talk if you are a product manager new to the Agile world and especially if you follow the Pragmatic Marketing framework.

Hiring For An Agile Team: Detecting Candidates Who Will Fit With the Team

Johanna Rothman

Come to this tutorial if you are the one who hires new members for your team. You will learn how hire people who fit to your team way of working.

Diana and Esther’s Excellent Retrospective Adventures

Diana Larsen
Esther Derby

Come to this tutorial if you are running retrospectives and want to improve them.

Business Value: Discovering what it is and what to do about it

Joseph Little 

Come to this workshop if you are on the business side of the project and want to make sure the investments produce what is actually needed.

Adventures in Agile Contracting: Evolving from Time and Materials to Fixed Price, Fixed Scope, Fixed Schedule Contracts

Teresa Franklin

Come to this experience report if you want to see how organization could make fixed price, fixed scope and fixed schedule contracts be compatible with Agile development.

Requirements-Driven Workshops for Large Agile Projects: Essentials for Product, Release and Iteration Planning

Ellen Gottesdiener

Come to this tutorial if you are struggling with starting the product, release or iteration. You will learn how to conduct the kick-off workshops so that they produced just enough requirements.

Agile and Paper Prototyping

Todd Zaki Warfel

Come to this tutorial if you want to learn how to avoid a lot of oversights in the product design with the help of efficient low cost tool – paper prototyping.

Secrets of a Sticky Note Ninja : Rapid Ideation and Problem-Solving with Post-It Notes

Kate Rutter

Come to this workshop if you are a facilitator willing to improve the way of conveying information with the help of the cheapest visual tools.

Ambassador Model for Effectively Distributed Agile Teams

Giora Morein
George Schlitz

Come to this talk if your distributed Agile teams don’t work as well as you’d like them to work. You will learn a success proven model for effective distributed Agile development.

What Makes Distributed Agile Projects Succeed (or Fail)?

Chris Sims 

Come to this workshop if you would like to collectively find out what could make your distributed teams better or if you would like to see whether the Nominal Group Technique is indeed better, than the traditional brainstorming.

Anticipation vs. Adaptation

Coins
In a recent talk on architecture vs. agile development, Philippe Kruchten presented a simple but compelling message:

Software Architecture is about anticipation of what is to come.
Agile Development is about adaptation in response to change.

These two often seem to be at odds, but they are not. Anticipation and adaptation are not simply two principles at opposite ends of a scale. I would rather think of them as two sides of the same coin. You can only look at one side at the same time. But they come together, as a pair. You cannot have one without the other, or you will have a bad coin. Or a bad project…

Anticipation and Adaptation
This week I had anticipated to drive to my partner in Brussels on Friday night. But he got sick (chickenpox) so I adapted by canceling some meetings and joining him two days earlier. I had anticipated to write this blog entry yesterday night in Rotterdam, but due to my new plans I adapted my schedule and wrote it a day later in Brussels. I anticipated that I am immune to chickenpox (I already had it as a child), but if I get sick again… oh well, I will simply have to adapt.

We would not be able to do anything if we couldn’t anticipate. We would not dare to sign a contract with a deadline in it; we would not be willing to choose a platform and programming language; and we would not be able to get the first version of the backlog on the wall.

Anticipation is what makes us move forward.

We would also not be able to be successful if we couldn’t adapt. We would not care to change features in order to make the deadline; we would not dare to refactor to better designs; and we would not be comfortable publishing that altered second version of the backlog on the wall.

Adaptation is what makes us change course.

In order to get where you need to be, whether in Rotterdam, in Brussels, or anywhere else in life, you have to anticipate and adapt. You must dare to make decisions and be ready to change them later. You have to make assumptions and be ready to face the consequences. You must join your sick partner and be willing to sleep on another floor.

When unit testing is not enough

I’d like to share my experiences about unit testing (using JUnit) Java servlets outside of the servlet container. Agile world tells us that we should automate as much tests as we can – it would be good if all aspects of the developed system are completely tested. We should test functional as well as non-functional requirements of our systems. But can all tests be automated? What is the REAL value of such tests? The reality brings us problems and pitfalls even experienced developers fall into. I will present such story regarding automated and manual testing of Java servlets.

The problem
Quite recently I had do develop some “proxy” servlets facilitating Ajax request from web browser to our middleware layer. We couldn’t directly send Ajax requests because JavaScript security model doesn’t allow to request data from other address than it was originally downloaded (similar restriction to Java Applet).

All right then, our servlets were not doing any amazing job (some input and output transformations were needed, however) but I made some bugs even having 100% test code coverage (used Cobertura 1.9).

What about automated tests?
Well some things can be automated, some not. Let’s start with unit testing servlets. The simplest (containerless) solution to unit test servlets is to use EasyMock in order to provide mocks for HttpServletRequest, HttpServletResponse, etc. Yes, I know you can use Jakarta Cactus but I did it quicker using easy mock 🙂

OK – I unit tested my servlets and was very happy that I saw the green light. I started the sevlet container accessed the web page and it seemed to be working. Unfortunately I didn’t see that the servlet set some instance variables after the first invocation and these variables couldn’t be changed afterwards. The effect was disastrous – servlet was sending the same request all the times not taking into account passed parameters. We could have checked this problem by invoking my doXXX method multiple times with different parameters – we didn’t.

Did we test our servlets manually?
Yes, non-automated tests were performed using JMeter. I used JMeter to check how our servlets behave under heavy load. The performance and load results were OK but I noticed in the logs many entries similar to this one:

Checkout date [2008-10-15] is earlier than or equals checkin date [2008-10-11]

Well the log message lies! And the implementation is well-coded (really). What’s wrong?
This is how I discovered problem with SimpleDateFormat – not to mention the help from FindBugs that showed me big red light in the affected lines 🙂

What was wrong?

  1. I forgot that using instance variables is not thread-safe (there is only one servlet instance created by the container)
  2. I forgot that java.text.SimpleDateFormat has synchronization problems and cannot be used as a static class field
  3. I took UTF-8 for granted – unfortunately default encoding was set to the server’s default one (this problem was not described above but it appeared during further manual UI testing)

Lesson learned
When you want to test your servlets:

  1. You should invoke all methods you test multiple times
  2. You should test your servlets using couple of simultaneous threads to see whether there is no shared data clash
  3. Be sure you set required content type and content encoding before you flush any response – DON’T take anything for granted
  4. You should use FindBugs to check any common Java problems (e.g. SimpleDateFormat) – either using Eclipse/NetBeans plugin or Maven report
  5. ALWAYS test your servlets under heavy load – what works for single user can stop working when many users try to use your application

Using load testing tools you can discover quite interesting and unexpected problems – without such test you cannot be sure your application will work under every circumstances.

After implementing all fixes our servlets seem to work very well even under heavy load. We don’t have any thread-safety issues and our dates are parsed correctly 😉

Conclusion
To conclude shortly I will say that testing servlets is not easy. You can write unit test, “inject” mock request, response, etc. objects but you still will not be sure how your system behaves inside servlet container under heavy load (you should also try using Jakarta Cactus framework).
Agilists say that you should automate as much tests as you can. I generally agree with it but sometimes it makes more sense to perform some manual testing which simply works. I probably would not discover all the issues I revealed using only automated tests.

If you have other experiences with testing Java servlets, please share them here.

Welcome Przemyslaw

Dear readers

We just got a new writer for AgileSoftwareDevelopment.com. His name is Przemyslaw Bielicki. He is originally from Poland and nowadays lives in France. Besides loving Agile he deals with the code on a daily basis and his writing should raise the “code awareness” of this site. Przemyslaw also writes to his own From Java to J2EE blog that is mostly about Java.

Przemyslaw is not exactly a permanent writer yet and whether he becomes a permanent one depends mostly on the readers’ feedback. Therefore, please, welcome him and comment on his writing.

Best regards,
Artem.

P.S.
By the way, if you are thinking about becoming a permanent contributor to AgileSoftwareDevelopment.com author, contact me directly.

Agile Risk Management

Danger Today’s evaluation of one of our projects was a tough one. It seemed like nothing had gone right. The customer had signed the contract far too late, which meant that resource management had to switch to another (inexperienced) team, because the original team was already booked for other projects; the platform to be used turned out to be much older than anticipated; the customer singlehandedly decided on a live release date, and forgot to inform anybody else on the team about it; half of the requirements turned out never to have reached the proper team members, due to some stupidly bad communication; and beta testing was a nightmare because the customer hired a third-party service organization, and the development team was not allowed access to the beta testing environment.


Needless to say, the first release of the project was bad. Really bad.


Could we have prevented our problems?
Of course!


Do the agile methods have anything to say about such problems?
(In our case) nothing useful!


Can we solve these problems by adding more processes?
Absolutely not!



Sometimes, unexpectedly, you have to work with a bad environment as it is handed to you. You can jump high and low, you can cry, you can shout, and you can kick the customer in the groin (I often do all of that, just to let off some steam), but it’s not going to change anything. You will simply have to work with what you got.


Processes (including best practices promoted by agile methods) can only deal with known environments. (In fact, agile methods usually define their boundary conditions, like “customer on site” and “colocated team members”.) But if you don’t know the environment for a process, then you cannot define the process! That’s why software development methods always tell you to A) change the environment to better fit the process; or B) change the process to better fit the environment. However, every problem we faced in our little-project-from-hell had its origin in unforeseen circumstances.


Standard processes, by definition, cannot deal with unforeseen circumstances.
Only intelligent people can.


That’s where the concept of Risk Management comes in. Risk Management is part of Prince2, part of PMBOK, and part of the CMMI, but you don’t often see it addressed explicitly in books on agile methods. I think that’s strange, because Risk Management is nothing more than a simple approach of managing potential problems that are not addressed by the standard processes, and that usually find their roots in unforeseen circumstances. Risk Management is a 100% human activity concerning problem-solving. It is self-organization on the supra-project level.


So, how do we implement Agile Risk Management?


Easy! Make somebody directly responsible for keeping track of projects, their deviations from their expected courses and environments, and any measures to be taken to avert uncommon pitfalls. Prince2, PMBOK and CMMI tell you that this is the project manager’s job. But in practice the project manager has often dug himself so deep into the project that he is unable take a “10,000 feet view” of the environment he’s working in. That’s why Risk Management is often forgotten. Project managers cannot do it themselves!


Do we rely on the bus driver to watch out for the thunderstorm?


I think most bus drivers already have enough on their mind simply to deliver their customers to the next stop. Likewise, project managers need to keep their eyes on the road. And they need other people and mechanisms to tell them that they might be approaching danger.


Well, these are just my thoughts. I think our industry needs to flesh this out some more…

How to create the next iPhone

[Apple is a] company that can make a mobile phone with no buttons, no picture messaging, slow Web access and no video capture into the most desirable phone on the planet © crave @ cnet

This Monday I was following the opening WWDC keynote. I find it remarkable how Apple manages to pump out one excellent product after another. In most of the areas they decide to touch they are able to rapidly become the makers of the most desirable product on the market. Their iPod redefined the music player market, MacBooks are becoming more beautiful faster, than Microsoft can copy even minor bits of Mac OS X, now iPhone with its MobileMe are going to get a decent part of the smartphone market piece. Even their relative failures would be considered a success for many other companies.

Winning with less features

What is especially interesting is that Apple usually enters the well established markets and often with the devices that lack features comparing to the competitors. MacBook Air is severely limited by its single USB port, iPhone went to sales with the lousy camera and being unable to send text messages to multiple recipients. It didn’t prevent these devices from becoming at least the very wanted products rapidly.

The Apple Secret

The Apple secret is simple. The typical Apple approach as I see it is to start with solving the most important user problems and nothing else. They don’t really care about the feature set, but concentrate on solving a few top problems of the user, ignore every secondary feature in order to focus on these top problems and add more functionality only after they get the live market response. They did just that with the iPhone: solved the top problems (complexity of the very basic operations and of the web connectivity) while ignoring all the secondary issues (such as ability to install 3rd party apps and even fast web browsing). Once they got market acceptance and feedback, they focused on the next level problems such as inability to locate good applications and multiple devices synchronization.

Creating the next iPhone

This strategy sounds straightforward, doesn’t it? It does until the moment, when yet another manager comes with the desire to put yet another useful feature into an already feature-bloated product and until you have to focus on the "whole product" instead of cruelly cutting out the secondary features.