Retrospective: Why my former team don`t want to use BDD anymore

[David Shavit]

BSD

Hello everyone

During last three years we introduce BDD methodology in my team.

the team develop new client replaced old legacy one and add new desired features

almost the whole team (5-10 developers, 1-3 BA or PM team, 1-3 Testers) was new to BDD and we hire 1-2 consultants to guide us with the process.

currently the original most of the dev ant test crew spread to other projects. The PM stayed and new developer hired to maintain the system.

although the not-so-happy title that I gave to this message I want to say that from my sight of view, as the project manager of this project, I think this was a good decision. but I can`t escape from the fact that they currently PM neither the new dev don`t want to continue with that approach and not planning to maintain the pretty large spec and automation suit.

 

So, I Asked myself, what go wrong? and I asked the PM guys (and girls) too. 

what I find is that (currently I`ll focus on the things I think need to improve)

1. this thing seems to them as auxiliary automation thing that isn`t cost effective
2. we have long session (10 appointments of 3-4 hours each of 3 amigo) of discovery but later the PM said that they lacked a lot of details that we talked about it.
3. later in the dev period which was based on scrum, only then the real and detailed specs were written.
4. after a bunch of scenarios, we add an UI appendix written with a lot of conditions, sometimes it looks like that appendix were the comfortable and fluent place to the pm to express them self
5. in some sprints (approx. 50 percent) the PM stop writing the gherkin and it became the job of the youngest team mate - the automation developer. 
6. because that most of the develop team sit at other location, it seemed that a lot of the discovery we did during the sprints was on the emails and phone calls. Only after that the automation dev write the specs. (usually accomplished that only in the n+1 sprint)
7. We talked on the previous on vague scenario and mixture of problem and solution domains so I wouldn`t repeat on that matter.
8. Major Lack from my sight of view is that the PM crew didn`t get direct feedback from the CI system. They had a feedback on the release version of all sprint, but they didn`t see the connection of the BDD process regarded what they got.
9. The new programmer said that she`s not gaining much from the specs, only some developer guides who document the software architecture was useful for her.

I`d happy to learn what we should do, and maybe there`s still a way they can convinced that it will be very wasteful to stop this very invested process.

Thanks a lot

David

[Liz Keogh]

Hi David,

Some suggestions inlined to yours:

> 1. this thing seems to them as auxiliary automation thing that isn`t cost effective

I like to pitch BDD as an analysis technique which results in tests as a nice side-effect. Even without automation, the conversations can be very effective.

> 2. we have long session (10 appointments of 3-4 hours each of 3 amigo) of discovery but later the PM said that they lacked a lot of details that we talked about it.

I like these conversations to happen as close to the work being done as possible, so right when the dev(s) pick up the story to work on it. If the stories are sliced finely enough, it's only a 5-10 min conversation, and the details stay fresh in everyone's heads. So, lots and lots of small conversations, rather than huge long sessions. (If a dev is waiting there's always refactoring and tidying up and documentation and email to do.)

> 3. later in the dev period which was based on scrum, only then the real and detailed specs were written.

Not a problem if you leave it until they're actually about to code.

> 4. after a bunch of scenarios, we add an UI appendix written with a lot of conditions, sometimes it looks like that appendix were the comfortable and fluent place to the pm to express them self

Right, so BDD isn't the only way to do analysis. It's OK to include detail in other ways, too. The "Test Pyramid" suggests that we should have way more unit tests than end-to-end scenarios, so if you're doing something like validation, for instance, it's OK to have all the tests for that at a unit level. The value of validation is in guiding the user to fill in a form correctly, so just have one example of that at a high level. It takes a bit of practice to work out what to do at a code level and what to do at a system level; generally if it's "the same kind of thing again" lower level unit tests are the way forwards.

You can also bring the UI to the conversation and just write down conditions around it too. I wouldn't expect to see "username field limited to 36 characters" in a BDD scenario, but it's part of the requirements so find a different way to capture that.

> 5. in some sprints (approx. 50 percent) the PM stop writing the gherkin and it became the job of the youngest team mate - the automation developer. 

I do actually like it when developers write the Gherkin down. They type fast, and it gives feedback on whether they understood the requirements correctly. I like it better though when it's a record of a conversation between the 3 amigos. These days I advise any PMs, BAs etc. to come to the conversation just with the titles of the scenarios, plus any other information needed to have the conversation (that can all go in a JIRA ticket or equivalent if needed) and then add the record afterwards.

Also nobody talks in terms of Given / When / Then, so as long as the dev reckons they have enough information to do the write-up, you're probably good to go. I usually feed my scenarios back to my Product Owner (by email  if necessary) to check that we got everything. It doesn't take long.

> 6. because that most of the develop team sit at other location, it seemed that a lot of the discovery we did during the sprints was on the emails and phone calls. Only after that the automation dev write the specs. (usually accomplished that only in the n+1 sprint)

I've done 3 Amigos via phone call; capture the conversation, write it up later. It's also not completely unusual to discover more scenarios while coding. I suggest limiting conversation and coding to about 7 scenarios at a time; if you need more than that, split the story.

> 7. We talked on the previous on vague scenario and mixture of problem and solution domains so I wouldn`t repeat on that matter.

Cool. Scenarios should usually be problem-domain rather than solution-domain.

> 8. Major Lack from my sight of view is that the PM crew didn`t get direct feedback from the CI system. They had a feedback on the release version of all sprint, but they didn`t see the connection of the BDD process regarded what they got.

Dashboards are your friends. Get it up at the stand-up while you wait for people to arrive. If the build pipelines aren't running green, make that a priority.

> 9. The new programmer said that she`s not gaining much from the specs, only some developer guides who document the software architecture was useful for her.

She might have gained something from learning about the specs in conversation. Having said that, it isn't the only thing that's helpful, so having conversations about architecture etc.. are also a good idea.

I wrote this guide to the kind of questions I like to ask in 3 Amigos conversations. (It sounds as if the consultants might have been more focused on automation and tooling?)

Also note that if it's really really boring work that's well-understood, you probably don't need to have the conversations; and if it's highly uncertain work that nobody knows what it looks like, do it early and spike / prototype it until it's understood, then do BDD.

Last thing:

> they currently PM neither the new dev don`t want to continue with that approach and not planning to maintain the pretty large spec and automation suit.

See if you can work out which system capabilities are boring and stable and not being touched any more. You might be able to extract those out into their own libraries and services and get them out of the build. Otherwise, I'd be interested to know how they plan to keep up the quality of the code and avoid an ever-increasing manual testing effort, since every day's worth of development adds linearly to regression testing effort.

Let us know if any of that helps!

Cheers,

Liz.

--
You received this message because you are subscribed to the Google Groups "Behaviour Driven Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to behaviordrivendeve...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/behaviordrivendevelopment/3c3a8d30-d966-48a4-8663-27e1f96a0d85n%40googlegroups.com.

--

Liz Keogh
l...@lunivore.com
http://lizkeogh.com
http://lunivore.com

[David Shavit]

BSD

Hello Liz

It certainly helps!  the Suggestions are kind of fresh insights for me, and even surprising a little , so Thanks again!

unfortunately, It seem to me that they don`t have enough budget to invest in BDD or even other approaches to lower the regression costs, maybe they really planning to depend on manual QA to accomplish that. I`m not sure about it, probably days will tell. 

thanks again for the attention and detailed well understood explanations.

David

P S George, Konstantin. Alex, and Andrew  (or others group members) - I`d happy to learn from yours sight of view  and experience about my retrospective: what would you think that I should have done so the PMs and new Dev team became eager to continue with the BDD practices? What I have missed? and What are the "Golden rules" to convince maybe other teams that without BDD  their dev mission became  far from being cost-effective (under the conditions Liz emphasized that it shouldn't be boring domain) ?

ב-יום חמישי, 12 בנובמבר 2020 בשעה 15:16:58 UTC+2, Liz Keogh כתב/ה:

[George Dinwiddie]

David,

On 11/15/20 5:27 AM, David Shavit wrote:
> P S George, Konstantin. Alex, and Andrew  (or others group members) -
> I`d happy to learn from yours sight of view  and experience about my
> retrospective: what would you think that I should have done so the PMs
> and new Dev team became eager to continue with the BDD practices? What I
> have missed? and What are the "Golden rules" to convince maybe other
> teams that without BDD  their dev mission became  far from being
> cost-effective (under the conditions Liz emphasized that it shouldn't be
> boring domain) ?

Retrospectives are not a place to convince others to do things or tell
them the answers.

Retrospecives are a place for the group to look back, together, at what
they saw, heard, and did in the time frame in question. This allows them
to see things from all of the points of view in the group. It's
surprising how, even in a small group, people notice different things.

Retrospectives include looking for patterns in what has happened, and
look for new insights about it. Consider not only the surface level of
what you and done and tried to do, but also the assumptions underlying
that. In terms of BDD, it might be worth talking about what value each
person thought or hoped BDD would bring, and how well it did that. You
might also talk about unexpected value that you discovered along the
way. If you can, try to get to double-loop learning instead of merely
tweaking the symptoms.

Does that help?

- George

--
----------------------------------------------------------------------
* George Dinwiddie * http://blog.gdinwiddie.com
Software Development http://www.idiacomputing.com
Consultant and Coach https://pragprog.com/titles/gdestimate/
----------------------------------------------------------------------

[David Shavit]

BSD

Hello George and thanks a lot on your excellent remarks.

I thought about the retrospective with all my former group. I have done it partly with the consultant which open us the door to the world of bdd. and we had some interesting thoughts.

later I imitated another discussion with  the PO team, but unfortunately it was very poor discussion when I make some analysis with myself I found out that the PO and the Development team (outsource we hired) didn`t even have the base of what bdd is for, and what happening when there`s no kind of process of "backlog refinement". and other crucial and the basic philosophy of BDD. I don`t blame anyone (but me) nor the consultant that I was grateful that he introduced us with bdd world. but nowadays after a long process of studying of what`s is BDD i`m not sure that asking the dev team nor the POs on what they hope BDD will bring them. I think they are being far far away from what bdd intend to be so I think It wouldn't be so useful with that circumstances. it seem to me that the learning curve toward acquiring solid  understanding on BDD approach is pretty high. but as far as I getting the picture, I think it is must-have knowledge to everyone involved with software development

David

ב-יום ראשון, 15 בנובמבר 2020 בשעה 21:56:40 UTC+2, li...@idiacomputing.com כתב/ה:

[George Dinwiddie]

David,

Is your PO team happy with the results of the current way of working?

- George

[David Shavit]

BSD

Good Morning George (In my time zone :-))

I thinks he has ambivalent attitude: I think they are happy with the results, but on the other hand they don`t think that the BDD way is the main reason which responsible to there feelings.

I thinks It`s important to say the fact that this is their first developing effort they have participate ever, and they don`t have other development work to compare with it.

David 

ב-יום שלישי, 17 בנובמבר 2020 בשעה 19:13:47 UTC+2, li...@idiacomputing.com כתב/ה:

[Jon Acker]

David, at it's very essence - and I don't see why anyone would *not* want to have a system like this - working this way is a matter of setting a goal that you all agree on (including the Product Owner, or whoever knows what it's supposed to to) and then set up a system that automatically checks to see whether you've reached that goal. That's a suggestion you could make that very much sets the stage for the adoption of BDD (of course this is the essence of TDD as well)

Furthermore, as Liz says, it is useful as a business analysis tool - if - and only if - the scenarios are concisely written in business language, usually English (but could even be Hebrew - there's a translation file), and focused on the expected outcomes, working with a programmer and a product owner on these scenarios forces them to a. share the same language b. share the same understanding (consequence of a) c. argue about the expected outcomes to commands given to the system until everyone agrees that they are correct.

Jonathan