Agile2014 - Day 1

Yesterday was the first full day of Agile2014. In general it was a pretty good day.

The original keynote speaker, Aneesh Chopra, apparently had to cancel. His replacement, Sam Guckenheimer, provided an overview of Microsoft's journey to agile. It was an ok case study with some interesting information, but it wasn't a motivational keynote to get us all charged up. Talking to some of the organizers later, I found out they made a conscious decision not to pay for a headliner keynote speaker.

One of the more interesting talks was with Ron Jeffries and Chet Hendrickson in which they took questions from the audience. Everything from is TDD dead? (it isn't) to budgeting around technical debt. Ron and Chet showed their extensive years of experience. One point they hit on is that agile is really about the team figuring it out. The team has to own the process and make it work for them. Using something like a formal Scrum approach should only be your starting point.

Mike Cottmeyer did a good presentation on why agile adoption fails. He has a nice write-up on his website here and posted the slides here.

The last presentation I attended was with Jesse Fewell and Dana Wright. They walked us through a more engaging way to prepare for meetings & events based on Dana's book.

On the exhibit floor was the usual group of vendors, mostly tool vendors. Automating testing and continuous integration were big...and DevOps was being thrown around alot. I was reminded that Agile is a software conference, not a project management conference like PMI's Global Congress so the focus was really on software development.

Agile Principles - Working Together

Business people and developers must work
together daily throughout the project.

One of the challenges I often face when I start working with a new client that has not been following agile is the amount of time expected from their business people. Their approach has always been that the business people meet with business analyst (BA), tell them what they want, and come back 9 months later to see what got built. 

I have to explain that agile doesn’t work this way and that in order to be successful, we want to have access to the business throughout the project. I find myself providing guidance on how much of business team's time we may need on a daily or weekly basis. 

The real problem with the first (waterfall) approach is that when asked, the business people may not know what they really want. They may be able to come up with a list of things they think they want, but if everything gets built, you will most likely have a lot of features that never get used.

Users will know what they want when they see it. So by starting out with what’s most important to the user, building something to show them, the users can target in on what they really need.

There’s another factor at work here. Studies have shown that a lot of knowledge is lost as it’s handed over from one group to another. So if a BA talks to an end user, creates a requirements document, and hands that to an architect, that architect is going to be missing some of the information the BA learned. When the architect hands it over to a developer, more information is lost. It’s only when all the silos are removed and the developer talks directly to the business person that they get the whole picture. They may hear something that a BA or architect didn’t think was important enough to document that is important. 

This all takes time, which is why a successful agile project follows the principle of the business and IT working together on a daily basis. It is through the interactions that happen on this frequency that help the team know what to really build.