Design, Agile, and Gall's Law

The topic of design has been crossing my path lately. I see a lot of overlap with Agile principles. One of the principles I came across is called Gall’s law. It states that "all complex systems that work evolved from simpler systems that worked.” It was introduced by John Gall in his book Systematics in 1975.

This is very similar to the Agile principle of simplicity. It can be seen in the practice of Test Driven Development. You write your test case and only code until it passes the test and then you stop. No gold-plating here. 

This is also similar to the principle of MVP (minimal viable product)  that originated in the Lean Startup. The idea is to make a product as simple as possible, get it into your users hands, and see how it works. You make your improvements to the product based on the feedback from your users. 

Seems pretty logical, but my experience is that it isn’t followed as often as it should be. I see plenty of examples where scope creep takes over, and rather than getting the MVP out, features keep getting added - needed or not - while the users are left waiting. So next time there's a request for just one more feature, remind people of Gall's Law.

PMI Global Congress Wrap-up

I'm at the Orlando airport, departing from this year's PMI North America Global Congress. I've attended at least part of every North America congress since 1999, and even a few of the ones in Europe. While I did enjoy it, this year's was definitely not among my favorites.

I missed the first day's activities due to a personal commitment. I heard mixed/negative reviews of the opening keynote, Drew and Jonathan Scott, HGTV's Property Brothers. When past keynotes have included Malcolm Gladwell or Colin Powell, I can see how this year might be a bit of a letdown.

The second day keynote, David Robertson, was very good. He talked about how innovation evolved at Lego, based on a book he wrote on the topic. A key to Lego's current success was their ability to do more with less. They cut their inventory of parts in order to have better focus after almost going bankrupt in 2003.

The final keynote, Stacy Allison, was also very good. She was the first American women to summit Mt Everest. Some of her key points:

• Know how your story - your passion - is relevant to the organization and the mission
• Learn to laugh at yourself
• Know when to let go (she had to abandon her first attempt and come back a year later)
• It's our personal vision, not the organization's, that picks us up when we get knocked down
• Recognize your daily and weekly successes, not just the big one at the end
• When resolving a problem, focus on the solution without blame

I didn't see any of the paper presentations. I delivered one myself, plus participated in a panel discussion so I spent my time focused on those activities. The feedback I heard was typical...there were some really good sessions and some weren't so good. I know PMI spent more time preparing the speakers and working with them on the presentations, so I would think this would have had to helped the quality of the presentations.

Stories and Maps

I conducted a user story mapping session with my client last week and it proved to be a very effective way to help them see the big picture. The idea came from Jeff Patton. You can find more about it here.

If you're not familiar with user story mapping, it is something like this: first you think about the high-level functions and features you're going to be delivering and you prioritize that horizontally from left to right. Then you take your user stories for each of those features and you prioritize them top to bottom. Here's a picture to help you see it.

What I had seen with my customer was that we had gotten too focused on one of the features and spent almost a whole iteration getting it perfect, rather than prioritizing all the stories across all the features. By setting up a story map they could see all the work that still had to be done, which help them decide on what stories were really needed for the first release and which were just window dressing.

There's this idea of the walking skeleton, which is the bare-bones minimum that you could include into a release and still have it functional. Story mapping helps you identify the walking skeleton because you're looking across all the features. Going back to our picture, we would draw a horizontal line through the user stories. Everything above the line is part of the walking skeleton and would be delivered in the first release with the stories below the line coming in future releases.

So if you're having trouble prioritizing your stories try using the story mapping approach to help you get the big picture.

The System Shall...

I’m currently working with a client that is adopting agile, which really means there are people around that have done agile, but it’s not widespread nor is anyone on my particular project experienced with agile. As is common in these situations, I’ve gone through at different points to try to help them develop their agile mindset. My developers are well-versed in agile, but the client is acting as the product owner, so their understanding of agile is important to project success.

Before my team started development, the client started working on a “requirements document.” It’s full of statements like “The system shall allow the user to select a need by date” Now while each snippet can help provide information, the document as a whole is about impossible to digest in order to understand what we’re supposed to build. I’m going through the document and working with the client team to extract user stories. 

As I’m working with the client, I am also trying to build the agile mindset within them. Agile isn’t just about following a different process. It’s about thinking about what you’re doing, inspecting and adapting as you go. In order to do this effectively, you need to know the why behind your actions. Why are we writing user stories instead of requirements documents? Why do we work in short iterations? Understanding this will help them become more agile, even after my team and I leave...and maybe they'll no longer be writing "the system shall..."

Lean Climbing

I’m on my way to Colorado for a weekend of outdoor adventures, climbing and mountain biking. As I was looking over the route for the climb (Kelso’s Ridge up Torrey’s Peak and a possible double with Gray’s Peak) I remembered an article I recently read on applying the principles of lean climbing to business (here).

I’ve done a couple 14ers before, so this will be my third and maybe fourth, all with my son. We plan on being lean on this climb. Enough water and food, but not much more. Our timebox is getting down the mountain before the afternoon thunderstorms. 

My current client seems to get lean. As we were working through the user stories for the project, they made the decision to prioritize and pull out the lower priority stories without any prompting from me. With so many of my clients, there are many discussions before they think about taking any stories out of the backlog for the current release. 

I think if I could take my clients on a climb, with each user story represented by a small rock in their backpack, they would soon realize the benefit of keeping it lean. There’s a cost with each user story, and being able to defer some stories means you get up the mountain sooner. 

Morning Routines

I’ve come across a number of articles lately that have talked about the importance of a good morning routine (like this one), so I have been trying to practice some of these techniques.

One practice is to start the day with meditation, not checking any electronic devices. I'll admit, sometimes when I'm working from home I'll turn on the TV while making my morning coffee before heading up to the office, but I don't start responding to email first thing in the morning.

Another recommendation is to journal. Your mind is the most sharp in the morning so that is not the time to waste responding to emails. Instead figure out what your top two or three priorities are and try to get those accomplished first thing in the morning. Journaling can help you figure out where to start your day.

I have also found that I can change my evening routine to be more productive as well. I find when I'm traveling and staying at a hotel, that if I skip the TV and put on music instead, that I'm more focused and get more work done.

So is it time to change up some of your routines?

Time for a Demo?

When I first learned Scrum, the idea was to have 30-day (4 week) iterations with a demo at the end of each iteration. Today I see teams that have iterations from 1 to 4 weeks, or in the case of Kanban, no iterations at all. So the question is, how often should there be a demo?

I’m a believer of getting sign off on a user story once it's done. This usually comes from the person who wrote it, who may be a proxy to the product owner. So when we get to the end of the iteration, all the stories that are completed have already been reviewed by someone on the business side but not necessarily the product owner. 

So the questions is, If it’s a short iteration, does it make sense to have a more formal demo of the stories? I think in some cases the answer is “no.” 

On one of my projects where we were using Kanban, we planned the demos every 4 weeks. This allowed us to finish a set of stories that were part of a feature, so the demo was more complete. I think this approach works with short iterations as well, only conducting the demo after every second or third iteration, depending on how long your iterations are and how complex your features are. 

There's also another consideration. I work with clients building applications that will get rolled out to the organization. On these projects, we need to consider organizational change management. The demos serve as a way to help introduce the new application to the end users. So from this perspective, there may be a large number of attendees at the demos. This is another argument for less frequent demos.

So while a demo can be held at the end of every iteration, even for short iterations, there are some reasons to hold them less frequently. 

Tools

When I was young, I had a riding lawn mower. We had a big yard out in the suburbs and the riding mower made the job quicker. Today I live closer to downtown in a house with a smaller yard. I’m currently using an old fashion reel mower…no motor, just foot power to make it work. For the yard I have, it’s all I need.

With all the technology around us, it’s easy to get caught up in the latest thing. Tools can make us more effective, but sometimes they can be distractions. 

Take project management tools. There are a plethora of them around and I have used them effectively on projects. But I have also run projects with just a white board and stack of post-it notes, not letting the technology get in the way of interacting with my team.

The Manifesto for Agile Software Development says it should be “Individuals and Interactions over Process and Tools” so ask yourself if the tool you are considering is going to help you or could it just be another distraction? Put another way, A fool with a tool is still a fool."

Minimal Viable Product

I have a customer with a challenge. We've been working on an application and finished our first release. The business folks looked at it and came up with a list of "must-have's" they want before going live. The IT folks are pushing back, trying to keep additional work to a minimum before going to production. They even threw out the phrase "minimal viable product" or MVP as a way say what's the least that can be done.

However, MVP isn't about doing the least amount of work and calling it done. When taken in context of Lean Startup, it's part of a process. First you build the MVP and hypothesize what you think will happen when you go live, you measure against your hypothesis, and ideally learn something that takes you to the next step.

When I work with customers used to a more traditional approach to projects, I often see resistance to the MVP approach. They think they have one chance to get what they want, so they ask for everything. If they truly thought in terms of MVP, they would be able to think about it as what do they want first, knowing they get a chance to ask for more.

In some cases, the next step may not be in the same direction. In Lean Startup, there's the idea of the pivot, making a more fundamental change in direction. Groupon started as an online activism platform and PayPal started out building security software for handheld devices (think Palm Pilots, not smart phones). There are plenty of other examples out there of companies that didn't get the results they expected and made a pivot. Lean Startup is about getting to that point as fast as you can.

For my customer, we're going to time box another round of development, make them prioritize the must-haves, and then hopefully go to production, so they can see it they are moving in the right direction. Are you ready for your next step?

10/10/10

There's an interesting decision making technique that I came across in the book Decisive. It's called 10/10/10. The technique was developed by Suzy Welch. She has a book by the same name.

The idea is to think about how you will feel about a decision in 10 minutes, 10 months, and 10 years. The idea being discussed in Decisive is how to avoid short-term emotion when making a decision. Bad decisions, they say, are made while having strong emotions such as anger or greed.

For example, I recently bought a new car, what a lot of people would agree can be an emotional event. Ten minutes after I walked out the door, I'd be excited about the new car and happy with my decision.

In ten months, I may still be thinking about the car I didn't buy and if I would have been happier in that one.

Ten years from now I'll be happy I choose the car that was more reliable over the one that would have been fun, but probably had more problems. If I didn't keep the car ten years, I would have been happy that the car I choose was the one with the higher resale value.

So next time you have a decision to make, think about 10/10/10.