#Agile #Sketch – A process for #Agile solutioning

I was discussing how I wanted to approach an Agile project with my team the other day and came across a pattern that I typically find comfort and clarity in. I like to Sketch. Not the drawing type of sketching – but the project type of sketching.

I like to draw and sketch everything at a high level and then fill in the sketch as I go along on a project. I find these sketches extremely valuable. I also use various types of sketches:

  • Schedule – high level project plans
  • Architecture – high level design
  • Strategy – high level objectives and scope
  • Estimate – high level effort plans

I’m sure there are others.

The concept is two-fold.

1) Create a sketch so that it provides internal and external clarity in regards to what the team is doing and creates a shared vision.

2) Allows the team to think through the sketch. Sometimes oversights, inconsistencies, and errors are only found when you dive down into the details.

The situation

In this situation on the project, I was proposing we create a sketch of the test solution we were going to create. I felt this would be valuable as a method to confirm all the business scenarios that we felt this project needed to address. We would not define all the individual details about the business scenarios, but confirm at a high level, the X business scenarios we would have to ensure we do address and define in more detail in the future.

A colleague of mine asked whether this was a waterfall process.

It caused me to pause and think. Was this a remnant of waterfall processes I had used in the past?

In retrospective, my preference for these sketches seems to be to be very Agile. I am doing what I feel to be the minimum amount of work required. Although these sketches do imply some serialization, I don’t think serialization automatically implies waterfall. I believe excessive and extremely detailed serialization implies waterfall. Some limited serialization to create shared vision and mitigate risk is very Agile.

I viewed what I was proposing to be very similar to a User Story Map. A small amount of time to confirm vision and gain agreement with the team and clients on what the requirements are.

I also saw an analogy back to my video game days where you struggled to get to the next checkpoint. Once you got there you wouldn’t lose the progress you had made. I felt these sketch checkpoints were extremely valuable to spend a small amount of time to confirm the vision and think through the solution. If we had a disagreement we could reflect back to the sketch as we confirmed we had agreement at that point in time. In this way it very much is a risk mitigation strategy.


I think my comfort with the process of Sketching can be related to my concern on whether a project can be done fully in Flow without some up front planning. I believe that Flow can and should be used 100% on repeatable and stable processes, but as we know that sometimes projects can be called neither stable or repeatable.

Rather than having scope, design, or architecture organically grown from a collection of User Stories, I do think that some planning should be done to confirm visions and think the solution through. Whether you call these constructs sketches, User Story Maps, Plans or widgets is  not important.

There are two critical aspects

1) Do some level of upfront planning/sketching/mapping

2) Do as little planning/sketching/mapping  as possible


We need to be very careful in the Agile community that we find the appropriate solutions that mix Agile with Traditional approaches.


#Innovation Games – Rapid Discovery Event

We had our second Innovation Game meeting earlier today and it was very interesting. This meeting was more of a standard application of Innovation Games unlike my previous two posts. It was a meeting that we at Protegra call a Rapid Discovery Event. A Rapid Discovery Event is a Discovery meeting with Innovation Games combined with a User Story Mapping session to quickly gain an understanding of the true business problems and potential solutions.

All the people that attended had never done Silent Brainstorming before.

Here was the agenda for the session:

Two Things – This is a very quick Silent Brainstorming warm up activity where we ask the participants for two things about the proposed solution. One thing that the solution MUST do, and one thing the solution MUST NOT do. This was a good warm up session and quite well received.

Who/What/Why – Silent Brainstorming exercise to start to get everyone to think about Who is going to use the solution, What are they going to do, and Why are they going to do it. Very good exercise and the group started to build up momentum and throw out a lot of ideas. We had an excellent diversity of styles and opinions in this group. Very nice to have and it is making this session very productive. We also had a good diversity in the two facilitators. My co-worker has more of a Business Performance Consulting focus while I have a technical background. I think this is an excellent match and allows for us to ask more of the right questions.

Personas – We take a break from the Silent Brainstorming and have an interactive session on the Personas or people that will use the solution. While we did not capture all the attributes about Personas that would normally be done in a standard Persona session, it was still a very valuable session. This session generated the most discussion and new ideas of any session. The amount of information we captured on the separate Personas and how they would use the solution was incredible. We easily captured at least 4-5 new Personas and ultimately functions of the solution that we were totally unaware before we started. Easily the best session. I think varying Silent Brainstorming with Interactive Sessions also helps to generate more feedback. Need to remember this.

User Story Mapping – The last Silent Brainstorming exercise was a User Story Mapping exercise. This exercise generated some excellent new ideas on what the solution needs to do. I think this session really benefited from having the three sessions held previously. With the results and discussions from those three sessions in hand, people were able to come up with the User Stories very easily. If anything, we had to end some discussions prematurely due to running out of time. It was fantastic to be in a 3 hour meeting where people are passionate and energized to continue talking. I’ve seen User Story Mapping sessions take 20 minutes. Everyone had their stories up in 5 minutes.


I’m an Innovation Games convert. It was a great session and we captured much more information than I had hoped. We have a larger group schedule next week and I am very excited about the information we will gather from that session to combine with this one. If you haven’t checked out Innovation Games online, I recommend that you go there and try out some games as soon as possible. You won’t be disappointed! Don’t be afraid to customize then to your specific circumstance….