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.

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.

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:

Big Visible interviews with many of the conference speakers

Agile Alliance posting of keynote presentations from the conference

Projects at Work interviews with conference attendees

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.

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.