The last month I’ve read The Goal by Eliyahu M. Goldratt. Apart from being a great book, it was also written in a really interesting way. It’s a novel in which we follow Mr. Alex Rogo and how he learns about the Theory of Constraints. I thought that I might try to mimic that style a bit in this post.
The subject I’m getting back to again and again nowadays is agile for the whole project. In my opinion, agile thoughts often come from development and never get a good foothold in the analysis/requirements or testing departments. “Yes, by all means… Do this agile you like so much, but please let us write the specs and test cases as we always have done.” – is a common reasoning where I’ve been.
OK – on to the story. It comes in two flavors, set in two different companies; Waterfalling Inc. and Agilement Corp. They are at the same point in their projects – about to start development, and we will see two different approaches to tackle that. Let’s visit Waterfalling Inc. first.
And yes, the names, persons, and events in this story are all fictional and just a figment of my imagination…
Waterfalling Inc
Sven is rushing. He has called this meeting with Johan, the tester in charge of the project, and Marcus, the solution architect. Just getting an hour when they weren’t booked was hard enough, but being late won’t improve the meeting climate. Sven swipes into the small room just in time to see Johan and Marcus take their seats. Great – he made it.
“Well, I’m happy that we’ve finally reached this point,” Sven starts, and continues, “As you might know or not, we have been slaving away for quite some time on this project here at the requirements department.”
Johan and Marcus look tired. They exchange a knowing glance.
“Yes, just getting hold of these users is often very hard. They are so busy. This system will really help them, I hope. It would have been great to meet them more, but two half-day workshops were all they could spare,” Sven explains. “Any-who… now we have compiled their thoughts and understanding of the current system into, if I can say so myself, quite an impressive requirements document. It’s 400 pages worth!” Was that a small whistle Sven heard from Marcus?
After a moment’s silence, Johan cuts in: “Well, we in the test team haven’t been sleeping either. We sat in on the first meeting with the customer and then went on to book meetings of our own. With the first draft of the use cases in hand, we have created a whole lot of test cases. There are a lot of different paths to cover in this system, you know.”
Sven interrupts: “Which users did you meet with? Anders and Cilla?”
“No, it was Gunilla and Madde actually,” Johan replies. “But they work with the same thing, don’t they?”
“Yeah, I’m sure they are in tune with each other,” Sven says.
Finally, it’s Marcus’s turn. How often is this part neglected, he thinks. If you don’t think these IT-things and early decisions through, they will become a mess later on. “And for our part, the technical side of things, we have also been doing important stuff. There’s a lot of technical and architectural stuff that needs to be decided long before any code is actually written,” he states with a slight tone of professorship.
Seeing that he has caught their attention, he continues: “For example, the architectural standards that we need to adhere to here at the company, naming conventions, and the layering of the system. We have actually implemented a first run-through of all the layers in the application that will serve as an example. Nothing we will use in the real system but just for trying stuff out.”
“With that in hand, we can safely pass all the reviews that the IT-department makes us go through. That has been the goal for our work so far…”
“Well then,” Sven tries to stop Marcus before this turns into techno-babble, “Do you think you can build the system from these requirements? And the obligatory question – when is it done?”
Marcus: “I cannot see any problems here… You guys seem to have thought of everything. Just the amount of pages before me is a testament to that.”
“As for the estimate – I’d say three months… five at most. Not counting testing and bug fixing, of course.”
Sven looks at Johan, who responds, “No, but we often calculate just the development time divided by PI, which gives us about a month to test this.”
Sven concludes the meeting: “That sounds about right. Let’s finally start creating the system! And hey, good luck!”
Agilement Corp
Steve is rushing. He has called this meeting with John and Mark, and he knows that they both just arrived at the project. Steve wants to make a good first impression. He even bought cookies for the meeting. As he enters the team room, he sees John and Mark on their way back from the coffee machine.
“OK – guys, want to sit down to discuss our initial thoughts on how to tackle this system?”
“I’d rather stand in front of a whiteboard – easier to visualize my thoughts there,” John suggests.
“Great idea,” Steve and Mark respond almost in unison.
Steve starts, “OK, we have now interviewed the users of the application and got a pretty good idea of what they need. Unfortunately, they will not be able to be part of our team. But they have promised to put one or two people at our disposal for an hour a day. So we’ll have to batch up our questions for a day. We thought that was acceptable. What are your thoughts?”
“If that’s what they can offer, that’s what we’ll have to accept,” Mark injects.
“OK,” Steve continues, “for starters, I think the team that has done the interviews will do just fine. And then we’ll use the customer hour each day to check back with them.”
“So how do we do this then?” Steve puts the question out.
“Let’s try to specify the system with acceptance criteria,” John calls out… a bit too loud, maybe. “It was something I read about a while ago that sounded very interesting, I thought.”
“The whole idea is that you start out with a user story as we usually do but then write down some example scenarios that, in essence, are the acceptance criteria for that user story. For example, from a great blog post by Dan North.”
John walks up to the board and writes the following down:
Story: Account Holder withdraws cash
As an Account Holder
I want to withdraw cash from an ATM
So that I can get money when the bank is closed
Scenario 1: Account has sufficient funds
Given the account balance is $100
And the card is valid
And the machine contains enough money
When the Account Holder requests $20
Then the ATM should dispense $20
And the account balance should be $80
And the card should be returned`
“Alright – now we’re talking,” Mark joins in. “That will become both our specification to code against and our acceptance criteria for verifying the feature afterward.”
“And regression test as the system grows,” John adds.
“Fine, fine, my young padawans! Get back to earth, you two.” Steve is not yet impressed. “How do we go about creating all those user stories and scenarios? All we have now is a high-level feature overview. It’s nowhere near the detail level you’re talking about.”
“OK, but some of those features are understood at a level where we can start to create user stories from them, right?” Mark starts.
“Yeah, I guess,” Steve replies reluctantly.
“And we certainly don’t want to specify the whole system at once. Now do we?” Mark is walking dangerously close to being patronizing now.
“Well, a suggestion might be to start with one of those features and try to sit down and write user stories and specifications for them,” John saves Mark from an awkward moment and continues, “That can be done in a workshop with a team of all our three disciplines: requirements, test, and development. And the final result can be double-checked with the customer.”
“OK – I’m getting you now… Something like this, maybe?” Steve steps up to the whiteboard and draws the following picture:
“All disciplines needed to figure out how the feature is to be implemented meet up in a workshop. They all bring their understanding of the problem and any documentation they need to remember what’s been said in earlier discussions,” Steve explains as he draws.
“Yes,” Mark injects, “and the beauty of that is that the workshop will produce a single document with the shared understanding of the problem. It’s all very DRY – Don’t repeat yourself – as any programmer would say.”
“And! We’re creating the test cases at the same time as we are creating the specification,” John adds.
“And! It’s documented in a format that we can show and discuss with our end users. They will surely understand plain English, won’t they? No more explaining state diagrams…”
Steve adds the customer to the drawing:
They stood back for a while – very satisfied with their progress. But John, being the skeptical one of the lot, wasn’t entirely happy. Something was nagging him. Suddenly he realized what it was: “But hey… you surely don’t suggest that we will write these scenarios perfectly the first time. Or even find all variants of them? Then we will just be back in a waterfall process again. Although smaller waterfalls.”
“Of course not,” Mark said, “but then we could just add more scenarios as we develop an understanding of the problem. Or as we see stuff that is needed for understanding the function. Or stuff that we want to test.”
“The document will be a living document that we’re working on throughout the course of the project, or at least the feature.”
All of a sudden, Andrea, one of the young hot-shot programmers, approaches the group: “I’m sorry – I couldn’t help but overhear what you were talking about. I just found this tool called SpecFlow that could execute scenarios written in the syntax you have described.”
The group goes silent. Andrea continues very slowly. “Well… I just thought that … we maybe could run those… scenarios against our daily build and … maybe… get an automatic run-through on our features. As we go…” – she stops here. Was that too bold?
She soon finds out that it was not, when the three men start to laugh and dance around her.
Steve sums it up: “Let’s call it a day! We cannot get further today, I think. Drinks are on me.”
Conclusion
And we’re back in the real world. OK, that felt quite cheesy at times, but I for one realized a lot while writing this. Actually, I have been at Waterfalling in many projects. They still exist today. I promise.
The way I suggest here is one way to go and is based on the works of Dan North and Gojko Adzic and others. SpecFlow is an excellent tool to implement the suggested approach on the .NET platform.