Taking the water out of water-scrum-fall.
I do love the term water-scrum-fall. It so aptly describes a phenomena seen, particularly at scale, where teams are using Scrum for development (and perhaps some level of testing), but the processes before and after development are waterfall-ish.
Water-scrum-fall may be a side affect of standard Scrum education, which addresses development ceremonies/practices, but spends very little time on strategy, architecture, requirements management, testing and release at scale. An organization transforming to agile can get the mistaken impression that Scrum is all about development practices. Too many organizations have thought that training and certifying your scrum masters will get you most of the way to an agile organization. I’ve already talked about how this leads to cargo culting type failures.
Looking at cycle time, in water-scrum-fall, a typical timeline for processing a requirement looks about like figure 1.
Applying good automated testing and devops can virtually eliminate, or at least substantially reduce, the fall section of the cycle time, resulting in a time line about like figure 2.
Of course, getting to automated testing and devops is a significant accomplishment that will take months.
But how do we minimize the front end cycle time in water-scrum-fall?
The goal is something like figure 3, where the front end time is greatly reduced (in addition to the fall portion).
Why do we care about improved cycle time? With dramatically reduced cycle time, software organizations can dramatically improve their responsiveness to change. When the business climate changes, or you need to catch-up with a new direction taken by a competitor, short cycle time will help immensely. With short cycle time, you’ll also see overall increased throughput (see video here), thanks to improved focus.
But there are complicating aspects in the front end. There may be many different roles involved (Enterprise Architecture, UX, Operations) and many different interconnected work items. There may be dependencies to work between teams.
Traditionally, deriving/deciding on requirements takes time. Then Architecture decisions are needed. The PMO can group work into big projects that require lots of planning. Lots of documents were produced, then reviewed, revised, and communicated.
Scrum education didn’t cover this. So, in too many organizations, that ‘water’ lead time persists.
Another aspect of the delay is that organizations tend to over multi-task. They explore too many options, working on too many tasks and projects at once. The lack of focus (i.e too much multitasking) then drags out the *water* phase.
I doubt the approaches I’m going to discuss are controversial, but they are not widely practiced AFAIK. In a nutshell, here’s what I suggest:
- Use workshops, attended by the right people, to reach decisions in a very short time frame (1/2 an hour to 2 days). With the right people in the room, an appropriate agenda, and someone working as facilita
tor to keep you on track, a lot can get done in a short time.
- Reach group decisions by developing visual (not text) models. The models document and communicate workshop output. Visual models invite critical input from everyone (What’s wrong? What’s missing? What’s extra?)
- Hold workshops at the last responsible moment (e.g. inside an iteration, after backlog refinement, at project kickoff).
- Address only substantive concerns. Comprehensive modeling is not appropriate
- Output may be specific answers, or it may be multiple experiments towards finding a better answer
Why I like Visual Models:
- Visual models serve well as information radiators. Models provide a mechanism for readily communicating decisions, and provide a basis for incremental improvement as more eyes review your decisions.
The models created can then be posted in team areas for future reference, and incremental improvement.
- Visual models are readily understood by consumers. A brief explanation is likely the most that is needed for anyone to understand a well prepared model. Often, no explanation is necessary.
- Visual models continually invite updates, revisions as new knowledge is obtained, and new conclusions reached.
- I haven’t heard anyone assert that visual models are not valuable. Everyone seems to appreciate the value of the finished product.
Learning to draw the models, and knowing which model to use when, is where the difficulty arises. In my opinion, knowing models simply gives you the appropriate tools you need to do your job.
I suggest you try to learn one model at a time. Look through a list of models, find one that is meaningful for your current project, and figure out how to use it. Continue to add to your skills and you’ll soon enough be a confident workshop facilitator.
A good Agile coach, in my opinion, will understand the importance of modeling, and either facilitate herself, or get a facilitator involved (e.g. from a company like Seilevel ). Some of us can model and facilitate, and since we’re coaches, can show you how.
Co-location is great of course, since these workshops can be done face to face with stickies and white boards. When not co-located, the workshops will suffer a bit, but web tools like webwhiteboard, Linoit, Padlet and others will substantially help when workshops are not co-located. These tools can also radiate the information after the workshop.
I won’t talk much about how to conduct a workshop (a big digression – see the references below). The basics involve having a clear agenda, inviting the right people, having a facilitator to keep you on track, and walking out with clear agreement on all decisions (documented with visual models). Bear in mind that you can team with others to model and facilitate. You know you have a good workshop when everyone is involved, adding ideas, drawing etc.
There are many models available. But I’ve found a few to be most helpful. Don’t overdo. Just use models you need. Questions with obvious answers probably don’t need workshops/models. When multiple opinions are in play, use a model to reach agreement, and then to communicate the decision. .
|Product Owner/Product Manager||Story Map, Impact Assessment, State Machine, Persona, Glossary, Scenario, Prerequsite Tree,|
|Architect||Glossary, Personas, State Diagram, Activity Diagram, Component Diagram, NFR Zone Map, Physical Model/Deployment Model, Data model, Scenarios|
|Project Manager/Scrum Master/Manager||Prerequisite Tree, Risk Map, Evaporating Cloud|
I’ve added a few references in table 2
|Requirements by Collaboration: Workshops for Defining Needs||Ellen Gottesdiener|
|Visual Models for Software Requirements||Joy Beatty and Anthony Chen|
|Software Requirements||Karl Wiegers and Joy Beatty|
|The Logical Thinking Process||Scott W. Ambler|
|The Logical Thinking Process||H. William Dettmer|
|Impact Mapping||Gojko Adzic|
|4 + 1 Model||Phillipe Kruchten|
|User Story Mapping||Jeff Patton|
Well run workshops can greatly reduce front end cycle time, thereby greatly improving the agility of your organization. Many projects/sprints need very few models. But good information radiator models are priceless for getting clarity on decisions, and communicating within and across teams.
Your comments are welcome.