I, along with many others who adopt an agile approach to their work, lean towards a mindset that there's no 'best practice' in implementing tools and processes - but rather the right one to use at the right time. For me, processes and techniques, such as use of analytical models, are like tools in a toolbox. They are ready to be brought out at the appropriate occasion by an expert craftsman, or alternatively, me. Some are like a screwdriver, providing value in a huge variety of jobs. Others are like that weird special basin wrench that you bought to replace the tap (faucet) in the bathroom, less frequently useful but no less valuable for that when the right situation arises - like my leaky kitchen tap.
In the last year or two I've found myself increasingly finding the tactically applied state model to an invaluable addition to my tool set. I've always found simple state models to be a great testing tool but in a product management capacity a state model is also surprisingly useful as a method of communicating and reaching consensus across roles.
- In early stages of development they are an effective way of collaboratively establishing a model for the problem space that can be used as the basis for the software solution
- They provide testers an early opportunity to test flaws in solution thinking before these are encoded into software
- They help to flush out inconsistencies between the thinking in different roles around how the software will map to the real world, and allow consensus to be reached around the scope and supported transitions within a feature.
All of these things and more make standalone state models a very useful tool, but it is actually in using state models in a more progressive, iterative fashion that I've found the greatest value in recent months.
Simple format
Let's clarify what I'm talking about when I refer to state model. There are different options for presenting state models right from very simple sketchy whiteboard styles, through to the rigid formal documentation kind such as UML state models (See here for a decent summary of the format).
Anyone familiar with this blog will guess that I lean towards the simple, flexible approaches that yield the most value with the least rigmarole. Lee Copeland's "Practitioners Guide to Software Test Design" provides an excellent introduction to a simple modelling approach that is probably the closest representation to the format I find useful.
When working with developers I typically operate a simple modelling representation of
Despite it's simplicity I've found this format sufficient to explore a problem space and flush out the flaws in early thinking on a solution. It also carries the benefit of being very easy to represent in Powerpoint - something that shouldn't be undervalued. Sometimes I stick to just using arrows to represent a transition, however I often find it easier to represent these as a shape simply because it can support multiple inputs and outputs for places where items undergo an equivalent transition. It also helps in discussing the models as it prompts the questions about whether certain states should support certain transitions e.g.
"Should we be able to delete from the edit page"or whether certain transitions are equivalent e.g.
"Is deleting a published item equivalent to deleting a draft one?"
A worked example
Imagine we want to create a blog platform. We want to create new draft posts and publish them to read on our site. Before we dig into the problem in our optimistic 'this is a simple feature' naivety we might consider the initial model to look something like this
I can guarantee that after an extended user story elaboration session involving developers and testers, we're likely to have a less beautiful but much more representative model looking something like this.
This is one of the fantastic things about collaborative analysis - through the process of interactively modelling and questioning, we have collectively explored the problem domain. Together we have established a model for a solution that has addressed some flaws in our initial thinking that would certainly have surfaced later in development with greater impact. More importantly we have a model for a solution that is understood by all of the active stakeholders in the development.
Incremental States
The beauty of using a state model to support agile development is that it provides us with an elegant way of representing the incremental nature of the development, whilst ensuring that we have a robust solution at each stage. If we can identify a slice of our model to support at each stage of the development then we can develop and test a complete subset of capability. Developers can use the representation of each stage to be clear on scope , testers can to understand the incremental delivery and test the integrity of it, and product leaders can use to communicate progress and capability to a wider audience.
For example - in our first user story for our blog platform we may identify that we're going to support the ability to draft a post. We can identify a clean segment of our model that defines the scope of this piece.
- The question comes up whether we want to support delete of drafts at this stage. We decide to include this as it provides a nice complete subset.
Now we want to deliver value quickly so we want to be able to publish our simple post.
We extend the model. This raises questions on scope
- Do we need to cover reverting a published post to draft? (not yet that's a separate value item)
- Do we need to be able to edit the published post? (not yet - let's focus on the top value item of publishing a post)
- Do we allow delete of the published post? (No we will consider the workflow of published posts later)
We may still be missing some obvious capabilities, but we have established a valuable workflow with a clear solution state model that can be rigorously tested, without getting distracted in supporting other states and transitions which add less immediate value and can therefore be deferred.
And so on, incrementally as we build the capability and add items that provide further value, for example being able to edit a published post, where we may decide to allow save and publish of an unsaved new draft as well as unsaved changes in a published post.
and subsequently we may add a route to remove unwanted posts, whether published or not.
We have a way of clearly communicating the expectation of what states and transitions will be supported in each development step, as well as identifying where gaps are and ensuring that we have a complete model in place at each stage. We can apply a high level of rigour around what has been delivered as it should be a complete and coherent solution, albeit one that may not support all of the desired states of our final solution. This provides confidence in our ability to release ensuring we have no 'loose wiring' in the incremental stages of delivery.
Non-trivial examples
In many textbooks the examples given are so simplified as to be very challenging to apply to any real-world examples so it's worth me saying that the worked example here is very similar to a model that I drew up in an real session in the last few weeks (although I'll admit the one here hasn't had the benefit of collective elaboration and testing so could well have some holes).
As with many such approaches the value here lies less in the model itself and more in the value that comes from the process of creating it. Getting a team together at the start of an epic item and working through the creation of an initial state model can be a fantastic way of aligning minds on the bigger picture and how to robustly deliver value in stages.
I've found this approach to work best on greenfield developments that involve the introduction of completely new system entities with multiple states. It may be less useful when introducing other shapes of new capability. For example when adding a set of rich and complex interactions within a single component such as an image editor - other approaches will inevitably be more useful. Which brings me neatly back to my original point - now where did I leave that basin wrench?
Photo by Edouard TAMBA on Unsplash
Post a Comment