How to harness the chaos within the development team?

Question

I'm a rather experienced software developer. I worked with many teams and projects throughout my career so far. The recent two projects, however, challenged me in an unusual way. Namely: they were disorganized, or rather organized in a way that I perceive as not effective.

Both of the projects are for the banking industry. They showed some surprising similarities:

• full-fledged Scrum (I mean - planning, refinements, retrospective)
• big teams (9-15 team members)
• no mockups before development
• 20-25% of the developer's time spent on the meetings
• developers assigned to work on something they lack expertise about (React devs assigned to Angular, .NET devs assigned to React)
• low quality of backlog and functional requirements
• superficial code reviews (pointing out if you forget to delete commented out code, but nevermind that code is not clean, names are bad and there are no unit tests)
• low developer's productivity
• missed deadlines
• poor quality of code

In case of the first project I tried to convince the team to reorganize, I suggested to split (it was at first around 12 people, later became 18 and more even), I wanted to convince them that we must have mockups first and should reduce the number and/or length of the meetings. Unfortunately, all the requests and suggestions have been rejected. They just said - 'it is what it is', 'we won't be able to fix the situation', 'we always worked that way'.

Finally, after a few attempts to fix the project and improve it - I quit.

The second project shows the same symptoms at this moment and I don't want it to fail, but I see the same patterns emerge.

How do you harness the chaos within the development team? How do you convince the team to follow the well known good principles? Is it possible at all, or maybe some organizations will always produce such an environment? If it's impossible to fix such a team - how do you convince yourselves to work in a team which you know works ineffectively and against the good principles?

Answer 1

I suggest starting by picking something that doesn't challenge the boss too much, say code review procedure, and asking him to put it on the agenda for the next team meeting. Then have a list of questions for the team: Do we care about variable names? Should we reject code that doesn't have unit tests? etc.

Try to get the team to decide on what they feel is important, don't just impose your ideas. You can collect some examples and everyone can say what they like and don't like, but try to take a vote and pick one way to do things. Then follow those standards or you'll be just another maverick adding to the chaos.

Use the retrospectives to praise the things that worked, and tackle whatever seems important and within your ability to influence.

See if you can take some of those poorly defined backlog items and talk to the users to add detail.

However some of these things are entirely your boss's decision (or his boss's). You might be able to suggest changes, but ultimately this is a sign that you should be asking for more responsibility and to take on some management tasks. Your team could be split into two or three scrum teams, with you as one of the leaders.

Answer 2

You don't have to be an authority to provide leadership. Authority is granted. Leadership emerges.

Rather than telling everyone what to do, show them that your ideas work. Ask others to hold you to these high standards. Seek out meaningful peer reviews. Ask them about the quality of your names. Make mockups. Have them reviewed. Do requirements. Have them reviewed. Even if it's at your desk or while standing around the watercooler.

Find people who share these values and offer to work with them. Form a team within the team of people you work well with and try to focus on similar areas of work together.

Once you find such people move your desks together. Help each other with tasks. Have your own meetings. At your desk, in the hallway, in the cafeteria. Keep them short, informal, and effective.

Don't use this as an excuse not to work with someone. But with 9 to 15 people on the team it's going to fragment anyway. Make your fragment a good fragment.

Now sure, you might not get any acknowledgement for doing this. Don't do it for that. Do it because these ideas really do work and make life better.

Answer 3

It does not sound like chaos at all, at the contrary. They seem very well organized, although perhaps not efficient in the short term and not in a way you like.

I worked for a bank too, for only 7 months and that was enough. I do recognize some aspects. They have a lot of stakeholders who go a long way into a tall hierarchy. That explains the meetings (the number and the amount of time they consume). You may think "what they do in 2 years with 100 people I could do in 3 months on my own". And you probably would be right. It takes a certain kind of people. Particularly patient ones. If you are not one of those, do not waste your energy.

Banks are often career driven. I never worked anywhere where people were talking so often about their next pay raise or promotion. That also explains a lot: if you do well you get promoted and some newby will replace you. There is little room for excellence and their defense will be they do not want to depend on excellence. So they have a system that always works, may be it slow.

Do your part and don't expect too much too quickly (if you want to last that is). It is like an army. You will not "fix" that. I suggest to go with the flow a bit, have a good look around, you can learn a lot about corporate culture and how that works. And then move on.

Answer 4

While I agree with what Robin Bennet said and I can confirm that it is a valid approach, I would also consider a different approach: brute force.

If you are an experienced developer who knows what he's doing, then start imposing good practices. Schedule short meetings. Insist that code review needs to be done and do not accept user stories until the code is properly reviewed and later tested. Insist on mockups and do not take no for an answer. It will inevitably lead to a head-on confrontation, but it will put you and your ideas in the spotlight and then it is up to you to convince the management that your way is the right way and to gain their support.

If you do, then the things will turn your way. If you don't, then ask yourself what are you doing in such company.

Answer 5

The best way to influence a team's direction is to stick around a while and excel, without using your current circumstances as an excuse. If you think mockups will improve quality or reduce rework, then do them for your own tasks and prove it. People will say, "Landeeyo gets fewer complaints about his designs not meeting customer expectations. Maybe there's something to those mockups he does."

Don't complain about receiving an assignment in an unfamiliar technology, see if you can find someone to switch with and solve the problem. If you can, and it speeds you both up, then management will consider that solution next time. If you can't, you will realize resources are being allocated as best as possible, even though it's not always optimal.

You're looking for ways to get buy-in to your ideas. Managers have to do the same thing in order to be most effective.

Answer 6

First of all, let's be clear: Two observations don't make a pattern.

Then again, I prefer the "evidence-based" route...

Short answer

Your clues are not enough. If you want to go forward, you have to know where you are starting at. You need the "medical history" of a team/organization/case that you deem as "pathological", in order to be able to find out the whys, before you can go on with improvements.

Long answer

Any enterprise/company/business that has not yet gone down is based on something that keeps running and, after a point, some balance typically strikes and almost all levels of management have formed a fair idea of the resources-to-needs ratio, as well as the cost-to-benefit ratio margins necessary to keep the company up and running. These are somewhat magic. These inexperienced developers are not being "done a favor" working in these projects. Generally, someone, somewhere, at some point, considered those developers fit for the purpose. Which brings us to the ...purpose!

Low productivity? Missed deadlines? It doesn't matter, as long as the company is up and running. Inexperienced developers cost less, which may be OK if you just need them to produce spreadsheets with formulas, spitting out some VBA scripts, a simple front-end for an in-house database, or other programming errands. There are probably companies that run exclusively on interns as IT support for years on end.

There is one thing you must never forget. Much as we may (occasionally) underestimate the technical knowledge of "Management" with respect to software development, there is something that they (and anyone, really) can tell you right off the tip of their head with respect to any system in the world, that is when they depend on it, of course.

It works...

Or it doesn't, which is when you have a problem and you call Houston asap. Management generally messes up when there is a problem. When there appears to be no problem at all, Management generally excels at rigidity. People that run the business want nothing changed because change involves risks. That is a primary element of mentality when money is involved and, fool yourself not, it is very effective. This mentality has kept businesses running safe since ...the beginning of civilization... and a day.

Regardless of whether you agree or disagree, I propose to keep the take-home message:

Up above, looking "downwards", there appears to be no problem at all.

If they are up and running and nobody is complaining that much, then that's that. Had anything been perceived as a problem to the well-being of the business, someone would have made a fuss about it long before your presence and you can be certain about this (citation needed alert, of course, anyone more experienced will definitely know better).

Suggestion

I understand I may have exaggerated a bit in my aforementioned commentary. However, I am simply trying to make a point. Take a step back. All your observations are pointless and mean nothing, until you clarify the one thing that rules them all: What is the task at hand and why does each involved administrative task-force (management etc.) not see a problem in the overall result. Why is it that you have identified multiple problems, while people that depend on the output of this team don't? Decode what it is that they see, so you can know what they perceive as a problem. A backlog might mean nothing to a Bank, but a small calculation error, a wrong decimal, a mistaken rounding, may make all the difference in the world. And as long as nobody complains, everyone is happy. When people are happy, they do their best to change nothing. Find out what "happy" means to all involved, up the ladder.

In short, get all relevant perspectives and get them quantified. Otherwise, you will be trying to teach a dog how to fly and, what is worse, you will never even understand why the dog does not want or need to fly... it may well be because its nutritional choices on the ground are far more diverse and voluminous.

I know this is practically not-an-answer as far as your actual question is concerned but, given your experience and suggestions, you seem to already have many good ideas and the fact that you have been unsuccessful does not necessarily mean you are doing things the "wrong" way. Plus other answers have provided many great ideas as well.