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