Sunday, December 28, 2014

Better Decision Making

I started reading the book Decisive by Chip & Dan Heath. They have a couple other books I've read, including Switch and Made to Stick, so I thought I'd give this a try.

I'm only about a quarter through the book, but so far, I am enjoying it. It's easy to read and has some good examples to support the ideas. The book is about how to make better decisions. It starts off outlining what they say are the four "villains" to good decision making;

  1. Defining the decision to narrow, not considering enough options
  2. Confirmation bias, we filter out information that doesn't support our position
  3. Focus on short-term emotions and not longer term outcomes
  4. Overconfidence in our ability to predict the future
From here, the book digs deeper into each of these villains and develops strategies to deal with them, starting with the issue of narrow framing. For example, they talk about the "whether or not" type decision. One example was Quaker Oats buying Snapple in 1994. Quaker Oats did buy Snapple and it turned out to be a mistake. The acquisition failed. One study they cited stated that 52% of whether or not decisions that organizations make fail. 

The key is to widen the frame of the decision. Should be buy Snapple or invest the money into internal research or another acquisition instead. Have more to decide on than just "whether or not." 

I'll have more to share on the book as I get through it, but if you're looking for something to read, I'd recommend it so far.

Monday, October 27, 2014

Tom Peters and Soft Skills

I recently had the opportunity to hear Tom Peters speak and I have to say that even at the age of 71, he still has a lot of energy and passion.

He began the talk with his experience coming out of college with an engineering degree. He found the math and science classes did little to prepare him for the real world, the people part of the equation, or the “all important last 99%” of being successful. It’s the soft skills that are hard, the people and relationship skills but that’s not what is the focus of education.

He then went on to talk about the Agile Manifesto and how that is the key to successful project management. From here, he shared some other pieces of wisdom
  • Politics is life, relish it. If you don’t like politics, you probably shouldn’t be managing projects
  • While intelligence (IQ) is important, having good emotional intelligence (EQ) is more important
  • Whoever tries the most stuff wins. Again, sounds like the idea popular in agile circles about failing fast.
  • To be effective, you need to “suck down” and help the people on your team. He didn’t use the phrase “servant leadership” but that’s what it sounded like to me. 
  • There’s no excuse for a poorly run meeting. Take the time to prepare so that it is effective. We can’t get rid of meetings. 
I found it interesting that so many of his ideas aligned with the principles of agile, even though his background is not in software. I’m often asked if agile can be applied outside project management and I think his presentation shows that “being agile” is important regardless of what field you are in.

Saturday, August 09, 2014

Agile 2014 - Final Thoughts

A number of themes surfaced during Agile2014. One of the big themes was scaling agile. There were a number of presentations on the SAFe model, Discipled Agile (DAD) and the new framework by Jeff Sutherland. There was also a lot of discussion on how Spotify scaled agile (be sure to download the paper).  

I appreciated the opportunity to hear about DAD from the creators, Scott Ambler and Mark Lines. Mark gave a presentation on how this framework was implemented at Panera Bread. The next day, Scott provided more details on their framework. 

One common opinion professed by many of the presenters was that there is no one size fits all with agile. There are no best practices. Everything has to be taken in the context of the organization where agile is being implemented. Experiment. Fail fast. Try again. Don’t copy what Spotify did just because it was so effective for them. You can start with a framework, but don't just follow a framework.

The topic of delivering value came up as well. Pat Reed/Walt Wyckoff from iHoriz did a good presentation on a value based framework for portfolio management. Pat stated that even now, 60-90% of features don’t deliver the value that was desired. Another presenter said we shouldn’t focus on shippable code but consumable code. It doesn't matter if it ships, it matters if it gets used. Only then is it bringing value.

There were other topics getting attention, including DevOps and #NoEstimates. The Coaches Clinic and Open Jam added to the value of the conference as well. I'm also sure there were topics I missed. With well over 200 presentations, it's hard to catch everything.

I think a conference like this is a great way to spark some new ideas and maybe help you get out of a rut with your day-to-day routine. Keep in mind that agile is all about inspect and adapt. If you successfully implement agile but then don't try to improve from their, you're doing agile but not being agile. 

If you missed the conference and want to get a flavor for it, here are some resources:



Friday, August 01, 2014

Agile2014 - Soft Skill Presentations

Three of my favorite presentations at Agile2014 were on soft skills; Diana Larsen’s Best Job Ever, Lyssa Adkin’s Facilitating Intense Conversations, and Jean Tabaka/Em Campbell-Pretty’s Creating Agile Tribes

Diana Larsen was the keynote presenter on Wednesday. After a bit of dancing, she got to the presentation. She had three main points

  • Do Work you Love to Do
  • Work With Purpose
  • Take Care of you Tribe

The message was that we don’t have to do a job we hate. Hard work can be rewarding, but there has to be a purpose behind it. 

Lyssa Adkins presentation was about facilitation when there is conflict. Her talk started out more like a discussion on Buddhist practices; things like meditation and mindfulness. Her discussion was based on the facilitation techniques of Diane Musho Hamilton. As part of the presentation, she brought 6 people up on stage and facilitated a discussion among them and demonstrated a number of facilitation techniques such as creating safety, reframing, and listening fully. 

The third presentation was based on the book Tribal Leadership by David Logan and both presenters talked about work environment built around some of the ideas in the book and the positive impact that had on the workers. The presentation wrapped up with the attendees making t-shirts of our tribe.


Tuesday, July 29, 2014

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.

Wednesday, July 02, 2014

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.

Tuesday, June 03, 2014

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.