3

I've been working for this company for about 5 months. They had very aggressive hiring policy and the result was that the development teams were build fairly quick and we started contributing to the product's code base without any formal development process in place. At the beginning most of the people were confused, not knowing what to do, since the product is fairly big, the code base is old and there is a lot of confusing code and few people with enough experience to explain what's going on.

During this period it was obvious that everyone is acting chaotic and back then the need from some formal approach was obvious. However time passed by and now the people have gained some confidence, some experience, knowing a little more about what is expected from them and I would say, they already started to feel comfortable as it is.

And now I'm given the opportunity to try and convince some of those people (the team that I am part of) to try and adopt the BDD. If this had happened two months ago I would feel very confident talking to them. I imagine how I explain them how we will get together at the beginning of each sprint, writing our scenarios, making sure that we all start with the same understanding about what should be done. Then, how there will be no downtime for the QA's but instead the whole team starts working, knowing exactly what needs to be done (eliminating that feel of not knowing what you need to do) and collaborating with each other/helping each other.

Bu this is the picture from 2 months ago. If I tell them now the same things I'm not sure if they gonna be interpreted the same way. I feel that it's most likely that now they will find irritating to spend time writing scenarios (after all now they know what should be done or at least they think so), they don't feel so lost anymore so the idea of pair programming and spending more time discussing stuff is more likely to be seen as waste of time or even sign of lack of skills. Things like living documentation or filling the communication gap won't make much sense either since we haven't hit those problems.. yet, and last but not least I myself lost my confidence that BDD is actually something that will definetlybenefit the team. After all if the team members are feeling OK, if the management is feeling OK, then why bother to change something. Maybe things are going fine.

This is where the things get very subjective and I need some advice. Do you think that given the circumstances the adoption of BDD is something that worth the effort. If no - why? If yes - what arguments would you give to such a team in order to make them enthusiastic about adopting BDD and willing to make the effort needed for that?

  • "I myself lost my confidence that BDD is actually something that will definetly benefit the team." If even you don't think its a good idea how do you expect to convince anyone else? – Ewan Mar 10 '17 at 9:46
  • I believe that even if BDD is not that good, even worse is not having any process at all. I always prefer, especially when we talk about companies with 100+ people, that formal process are almost always better then just letting people do the work however they see suitable. – Leron Mar 10 '17 at 12:17
3

Lets forget BDD per se and just talk about introducing a generic new process to a team that's already up and running in some existing process.

First of all you need to work out what the driver is. "How much more money will the company make if you introduce the new process".

Unfortunately if the company is not experiencing any problems at the moment the answer to this question is invariably that the company will make less money. processes tend to slow people down.

So there is no point introducing a new process unless the company is loosing money due to some identifiable reason. eg

  • new releases have bugs
  • new hires need lots of training
  • deadlines are not being met
  • a legal requirement is not being met
  • etc

If your new process will address these reasons, then you can cost it up. But you will still have a challenge getting people to make it happen.

So your first step can be to introduce some manual process which fixes the immediate issue. say you need to produce a data protection law report each quarter, get someone to manually check the database etc and produce the report by hand.

Once you have established that the task needs to be done regardless of how hard it is, you can show that your new process makes the task easier and or more reliable.

  • It's true that the money are great motivator, but the.. well let's say problem here, is that the company is trying to be maybe a little bit more agile than needed. Even if something is causing a lost of money, the company (at least for now) will still try to leave each team to decide on themselves how they want to work and what process they want to adopt in their work. We almost always fail to deliver our commitment but for the time being the company is not getting involved and letting the team deal with it's issues. – Leron Mar 10 '17 at 12:11
  • i understand, but my view is that if you are 'very agile' (i think we all know what you mean :) ) then introducing a process will slow you down. If the problem is missing deadlines then maybe you could make a business case for estimation recording and tracking, which would lead into your new process – Ewan Mar 10 '17 at 12:18
  • So, if I understand you correctly, you suggest to address each issue independently and create our custom process for solving it, instead of trying to adopt some existing process, is my understanding correct? – Leron Mar 10 '17 at 12:24
  • 1
    hmm not really, the idea is to create the pain first and then introduce the solution. This forces you to prove that you really do have a problem and gives your new process a concrete and obvious benefit ie. 'you wont have to fill in the estimation reports and 15m interval timesheets anymore' – Ewan Mar 10 '17 at 12:31

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.