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.

Eliminate Death Marches

This is part 2 of a 12 part series on the Principles of Agile

Welcome changing requirements, even late in
development. Agile processes harness change for
the customer's competitive advantage.

Another challenge for people new to agile is this idea about welcoming change late in the project. It's not that they don't expect changes, it's the approach taken to deal with it. Usually there is a Byzantine approach that involves change review boards, change request forms and impact assessments. 

But there's more than this. The other difference as I see with some organizations trapped in a traditional approach it is they don't want to deselect some less important feature just because some change came along...and usually they don't want the date to change either. I've seen organizations where it's a badge of honor to be on the project that had to add a lot of resources and work ridiculous hours at the end to deliver the project because they had to deal with new requirements but didn’t take anything out of scope.

It comes down to education on backlog management and time boxing. Anything can be added to the backlog but it has to be prioritized. Then you pick the release date. With this and your estimates, you can draw a line and say everything below the line is in the next release. As changes come in, you prioritize them, estimate the new work, and take an equal amount of work out of your list for the first release.

Even though I’m writing about these principles one at a time, they are meant to be taken together and when an organization has one of these death march projects, they burn their people out; they ignore the principle of working at a sustainable pace. If they took a smarter approach to dealing with change and avoided the death march, they would find their teams are more productive in the long run. It comes down to making a hard decision and saying "no" to some requirement that may have originally been in scope.

Principles of Agile, Part 1

This is part 1 of a 12 part series on the Principles of agile

I've been working on a big project and as the project has grown, I've been thinking about how Agile is supposed to work and how my project is following (or in some cases not following) the principles that are part of agile. For this first article, I'm going to talk about

Our highest priority is to satisfy the customer
through early and continuous delivery
of valuable software.

One thing I notice when I first start working with clients that are new to agile is their Big Bang mindset. When they start a project, they try to think of every possible requirement because they figure they have one chance to ask. This leads to large projects that take a long time to deliver. They have trouble saying no to features that they think they might need.

To counter this, I try to get the client thinking about multiple releases. Along these lines, not everything has to be in release 1.0. This is always more than a single conversation. As I teach them about user stories and and backlogs and prioritizing, I repeat the massage about small releases delivered quickly followed by another release.

Imagine you work in a shipyard unloading ships. You have 5 ships come in on Monday morning. Each takes 5 man-days to unload and you have 5 dock workers.

The Big Bang approach is to work on them all at once. With this approach you get everything done on Friday.

But what if you took the small release approach and had everyone work on one ship. It would get done on Monday (first small release). Tuesday is your next release and the second ship gets done that day. I think you get the picture. 

By taking the second approach, you deliver some value early and continue delivering value through the week. If the ships were full of cars, you would be able to sell cars by Monday, instead of Friday with the Big Bang approach.

The challenge I face is convincing the client this is a good approach. It's sometimes a challenge to figure out when to go live with that first release. No one wants to be told their feature is in the next release, something to deal with when you are working with multiple stakeholders. But once they understand this principle, the idea of small releases is more tolerable.

And as far as my current project, it is pretty big but I have gotten them thinking about the next release and some of our user stories are already being put in that release so we can keep our timeline for the first release, an improvement over the must have everything mindset they first had.

Balance

I haven't had much of a chance to write any posts lately. I've been on a project that has left me little time for other things, but on this Sunday I decided to take a step back.

There was a learning in Daniel Pink's The Adventures of Johnny Bunko; "persistence triumphs talent."  I had a boss that taught me this early in my consulting career, that putting in your 40 hours of billable time wasn't enough. It's the consultant that goes back to their hotel room at night and keeps working that is the one to get ahead. 

But where's the balance? Is there such a thing? Are we going to hit a wall at some point and decide we've had enough?

I believe that by getting away, it makes us more productive when we're at work. You need to have habits that take you away from work and lets you recharge. I'm a competitive runner/triathlete. It can be hard to get as much time as I want to train, but I do what I can. I don't head on a business trip without my running shoes.

Vacations are also important, again, getting somewhere where you can forget about work for a while. Last summer I spent 5 days climbing in Colorado. I pushed myself pretty hard physically but I sure didn't think about work and when I did get back to the office, I was recharged.

So if you're at work, work hard. Go beyond what is expected of you. But know where your next release point is.

Trying New Things

Over the past weekend I went ice climbing with my son. He is a pretty serious climber and I've picked it up because of him, but neither of us have ever ice climbed before. We went to a place near Cedar Falls Iowa that ices down a grain silo. It's really different from the sport climbing we've done, but it was fun and by the end of the climbing day, I was able to make it to the top of the silo.

How often are we open to trying something new? In my work environment, we follow an agile process based on Scrum. We do 2-3 week iterations, with planning sessions at the start of each iteration and demonstrations and retrospectives at the end…but sometimes you have to try something new.

I had a project a few years ago where the work wasn't as predictable. My team couldn't come up with estimates because they hadn't done anything like the work that faced us, so I decided to throw out the iterations and use Kanban. In this case, trying something new paid off. The Kanban approach worked well, we were able to get the work done and everyone learned from it, especially myself. When I was faced with a troubled project a few months later, I knew Kanban would address the challenges and get the project back on track. 

So don't be afraid to try something new. It could be as simple as changing the questions you ask in your daily stand up, or as complex as trying a different methodology. If the approach you're taking doesn't seem to be getting the results you want, inspect, adapt, and move on.

We're All in Sales

Daniel Pink was the keynote speaker at this year's PMI Global Congress. I have blogged about him in the past (here and here). His presentation this time was based on his latest book, To Sell is Human.

As the title implies, a main theme of the book is that we're all doing sales of some sort, even if it isn't in our job title. I thought about the times I've been working with a new customer and trying to "sell" them on agile and why they should start using it to run their projects. He had six pointers to help us as sales people

1. Extroverts aren't better than introverts at selling. It's really the people that are in the middle that are the best sellers. They balance talking and listening the best.
2. Interrogative self-talk is the best way to prepare for something like an important meeting or presentation. Don't think "I can do this" ask yourself "Can I do this" and answer in a way to convince yourself.
3. When we're trying to sell, compare it to something else. So compare agile to waterfall and explain why agile is better.
4. Related to that, less options are better than more options. Pink told a story of an experiment selling jam. When there were over 20 types to sample, people sampled a lot but bought less than when there were only 6 types because is was easier to decide which ones they liked best.
5. A minor negative attribute can help sell. So if you have these great shoes with a lot of desirable features, but they only come in 2 colors, this small negative will actually help you sell. You come across more open.
6. Have more conversations about why than about how. 

I had a chance to chat with him briefly during a book signing. When I mentioned agile project management, he said he thought agile would become the only way to run projects. I haven't finished his book yet, but I still recommend it. I even used the technique in #2 to prepare for a big client presentation yesterday and the presentation went very well.