Friday, February 05, 2016

Are You Experimenting?

I came across another interesting idea in Change By Design. It was presented as Toyota's ideas around training and had 4 principles:

  • There is no substitute for direct observation
  • Proposed changes should always be structured as experiments
  • Workers and managers should experiment as frequently as possible 
  • Managers should coach, not fix


This idea of experimenting caught my attention. So often as I'm designing a solution for a customer, they want to try to get the perfect solution first time out of the box. When they don't know what perfect is, they struggle to make decisions. I can recall one client, after 3 weeks of developing a complex interface, others looked at it and we went through another 3 weeks revising it. This was all in development, the real end users didn't have a chance to try it out. No experimentation at all, just managers trying to guess what was needed. No direct observation.

This is just one example of something I see a lot of. Not being open to experimenting. Smart organizations are figuring it out though. The push for a DevOps approach and employing Microservices is a move in the right direction. With DevOps, we can deploy something and if it doesn't work, we can have a different solution out in weeks or maybe months, not quarters or years. With microservices, we get away from the monolithic applications and have a bunch of small, independent components. If one doesn't work quite right, the whole system doesn't fail.

So how open is your organization to experimenting? Are failures discouraged or recognized as the first step towards success? Are you trying to get everything perfect or do you recognize that everything is a prototype, even if it's in production?

Tuesday, January 12, 2016

Divergence and Convergence

There's another idea from Tim Brown's Change by Design I thought was worth writing about. It's the idea of divergence and convergence.  Early in a design project (or any project), we want to collect lots of ideas. This is divergence...creating lots of possible choices. Linus Pauling, winner of 2 Nobel prizes, stated "To have a good ide, you must first have lots of ideas." If you're writing user stories, don't try to limit story creation. Just because a story is written doesn't mean it will be delivered but if it's never written it definitely won't be delivered.

Brown provides some ideas for generating ideas
  • Have an overarching purpose. I think of Design the Box when I hear this.
  • Involve the whole organization (or whole project team, sounds like agile again).
  • Don't discard ideas just based on who came up with them
  • Allow people room to experiment. This sounds like a spike to me. 

Now we get to convergence; making our choices. This is where we take a look at all our ideas and decide which ones to move forward with. It's grooming the backlog, prioritizing the stories, and throwing away the ones that don't fit our goal. Again, we should use our vision to help make these decisions. 

Brown points out the design is both art and science. The divergence is about being creative. The convergence is about using more analytical tools to make decisions. Also, don't think of this as a linear process...you may go back and forth between the two steps. For example, you just finished an iteration and are getting ready to plan the next one. You may have a divergent step and you synthesize the information generated in the iteration and demonstration but you need to quickly move to convergence to pick the user stories for the next iteration. 

Wednesday, January 06, 2016

Design Thinking and Constraints

I've been reading the book Change by Design by Tim Brown. It's part of my overall interest in design in general. I have found a number of interesting ideas in the book so far, and I'm not even half way through it. 

One concept had to do with constraints. Anyone that has worked much on projects know that constraints are a big part of it. He talks about three aspects of constraint; feasibility, desirability, and viability. 

Feasibility is looking at whether or not something can be done in the near future. 

Viability is looking at whether or not it's sustainable from a business model perspective. 

Finally, desirability of course is will it be something that people want. In design thinking you want to take into account all three of these aspects as you're working on a project.

As I think back to projects that I have had that have been either successful or not successful, I can see how all of these play into a project's success or failure. 

On an actual project, we can test for feasibility by doing something like a spike, a short test to prove out if the idea will work.

Viability may be a bit harder to show on a project. It will take other supporting input such as market research to prove the approach is a sustainable business model. This is probably best done before you go to far in the project.

I think there's a very strong tie between desirability and how agile projects work. It's that whole idea of working closely with your users to truly understand their needs. 

I've seen other ties between design thinking and the agile approach. I'll have more to say on the future blog post.

Tuesday, December 15, 2015

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.

Tuesday, October 13, 2015

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.

Tuesday, October 06, 2015

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.

Monday, August 24, 2015

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..."