Working with SbE in System Maintenance

[Mårten]

Hello,

I work as sort of a BA (more on the IT side though) at a relatively large governmental organization. I've started to introduce Specification By Example with one development team and their PO. But even if most of the team members and especially the PO are very keen on trying this, I am getting a lot of concerns from a few team members as of how this will work in System Maintenance. The team works with rather old systems and there is no new development, mostly only fixes or some new functionality.

The concerns is that they will need the full picture, e.g. all the requirements to even be able to start working on it. This is because the system has a lot of dependencies to other systems and they don't like User Stories or scenarios that is to vague because the work they need to do often comes down to a lot of detail, what color on a button, where it should be, what options there should be in a list etc. Until now the requirements are in the form of System Use Cases (that no one really read or understand fully) and some GUI-mockups (that also leads to a lot of misunderstanding due to different domain knowledge).

They seem to want to have scenarios that specify "how" instead of "what* and this is not so good as test cases, in case something would change later, but they don't think it's possible to keep them more general. But I believe it will be a challenge even if we allow the scenarios to be very specific, just because of their kind of work habits and environment.

I know this is mostly an attitude problem; that they are not willing to change their way of working, but do you have any good examples of how to work with SbE in this environment? 

The team and PO already have huge communications issues, which is one reason we are now trying to get them to work better together with User Stories and SbE.

Best regards

Mårten

[Gojko Adzic]

Hi Marten,

In the spec by example book, I wrote about a few case studies where
they applied the process to use cases. The high-level use cases were
scope, and once the use cases got into the development pipeline, the
team and the stakeholders discussed concrete use case realisations
(=examples). wireframes and gui mockups are also examples, but people
often consider them as requirements. you can apply the same principles
and techniques on GUI examples as you can for calculation/numeric
ones. Find the structure, identify variables, then look at the
boundaries of those variables to identify sources of misunderstanding,
and make sure everyone is on the same page.

so if people don't like user stories, my suggestion is don't force
them into that. the conversation about examples can happen around the
stuff you have now, and you can then start to slowly change the
process without a lot of objections.

gojko

> --
> You received this message because you are subscribed to the Google Groups
> "Specification by Example" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to specificationbyex...@googlegroups.com.
> To post to this group, send email to
> specificati...@googlegroups.com.
> Visit this group at https://groups.google.com/group/specificationbyexample.
> For more options, visit https://groups.google.com/d/optout.

[Mårten]

Thank you Gojko for the answer. I have purchased both Bridging the communication Gap and Specification by Example and I have started reading the first one, but I will check out those examples in the second one, thanks!

Good idea to try proceeding with examples from other kinds of requirements methods. I might try that. We have however already started with User Stories and I believe most of the involved people are quite positive to User Stories, but some of them feel the need  for more detail, which the examples then could satisfy. But overall they like User Stories because it makes them talk to each other (at least most of them.. ;)). Before it was a constant drop off of lengthy documents and a lot of misunderstanding and frustration. I think it has become better now because of this dialog that comes from trying to set up concrete examples. They do get quite detailed though. Like for example:

Given: a person with so and so authorization logged in

And: the person has chosen a case to approve

When: the person presses the save button

Then: A warning dialog will appear with the following text"something something" 

Then another scenario for what happens when he presses the OK button on that dialog box, like this and that text goes in to that column in the summary etc. And this is only the positive flow. Then some alternative flows will be covered and so on.

The system we try SbE on is a quite small new functionality where most of the new stuff looks a lot like an already existing functionality.

What's your opinion of such kinds of scenarios?

Our main goal with this particular team and PO is to improve their communication and understanding of each others perspectives, and I thought User Stories plus SbE would be a good start. It is of course a lot of new stuff to get used to for a team that has not been that agile before, but we really want all teams to try go away from Waterfall kind of development. Most of them are agile but not this one :) Most likely we will have to keep some of the documents on the side for some time, but at least try to remove the System Use Cases. If they would have used regular Use Cases it would have worked better probably to use SbE with that.

Best regards

Mårten

> email to specificationbyexample+unsub...@googlegroups.com.

[Gojko Adzic]

Hi,

> What's your opinion of such kinds of scenarios?

my opinion is that you'd never write something like that on a
whiteboard, so you shouldn't force people to write or read it like
that. you mentioned yourself that the conversations are key, so get
people to talk about the examples next to a whiteboard or a flipchart
and capture the results of that conversation in a way they seem to
like to write it down. then find a tool that will allow you to keep it
in that form.

gojko

>> > email to specificationbyex...@googlegroups.com.

>> > To post to this group, send email to
>> > specificati...@googlegroups.com.
>> > Visit this group at
>> > https://groups.google.com/group/specificationbyexample.
>> > For more options, visit https://groups.google.com/d/optout.
>

> --
> You received this message because you are subscribed to the Google Groups
> "Specification by Example" group.
> To unsubscribe from this group and stop receiving emails from it, send an

> email to specificationbyex...@googlegroups.com.