Are my team's processes out of control?

Question

I'm a software dev team leader (I recently took control of a new team), and ultimately responsible for maintaining high productivity, good quality and organized priorities.

I have 6 senior developers in my team, but things feel like a mess here. The situation is that I have to deal with JIRA requests from about 10 different points of contact in our company, and they all represent different business units, or clients.

The problem I have is that my job mainly consists of putting out fires the whole day and making sure that everyone's problems are being worked on. Unfortunately, the culture in our company has been high productivity (fast releases) but low quality (production bugs), and our clients won't accept a sudden delay in results.

What are some good ways of handling this? I have tons of theories, but I'm looking for an answer from someone who actually has working experience in a situation like mine.

Here is a small list of how things work:

• Each developer is responsible for a specific application and services interacting with it;
• Releases are typically tested by the client in a simulated production server, and then deployed to the live server;
• Each application is used by an average of 50-80 people, with 8 applications in total.

Thanks

Answer 1

our clients won't accept a sudden delay in results

Well, then they have to accept the poor quality they're getting.

What you have to do in order to change this is get your clients to accept the reality of software development (or any other production!): that rushing things affects quality.

Create a big list of the things that are going wrong - of the things that are broken, the times that they've had cause to complain. Explain to them the reason for these problems and tell them what you'd like to do to change that. Make sure you explain to them the percentage of time your team spends supporting and fixing live applications. If you're not collecting the data on that, now is the time to start (and collect it for a month before you present the information to the clients).

Get the key stakeholders in a room and say: "do you want X fixed, or do you want Y delivered? We only have time for one of the two." Make them responsible for setting the priorities, and be clear that you have limited capacity. If they ask for something new, ask them what they're willing to sacrifice from their current roadmap to achieve it.

Ask your team what time and resource they need to "put things right" (both in terms of fixing basic bugs, and in terms of fixing bigger issues in code quality/architecture/etc.). Include those items in the list of things that your stakeholders have to prioritize.

The best thing I ever did in my current job was to get the top 8 stakeholders in a room at the same time, and lay out a pile of 16 index cards representing the new features that had been asked for. I stepped back from the table and said: "we can deliver one of these at a time. What order do you want them in?" Let them debate eachother over the business priority instead of you being stuck in the middle.

Answer 2

Stop, drop and roll. Fires need fuel and often it comes in the form of panick. Set aside time to manage yourself and team in order. Evaluate your developers and see if you have any that are not skilled enough and/or don't work hard enough to produce the results you want. Decide who stays (and make an effort to keep them), who needs a little push, the rest have to go. Evaluate the support and tools your programmers are getting to make sure they can do their job. Make sure sound testing, review, source control and documentation are followed. Good people with good tools need to be accountable to do good work.

There has to be a system to know what your team needs to do, is currently working on and when they expect to be completed. Lots of methodologies, theories, software, dry erase boards and sticky notes, documents and email to get this done. Make something work by making everyone stick to it. If everyone has some input into the system, there is more incentive to follow it.

Get a better understanding of what the clients expect. This may not be a part of your job. There may be other individuals who pretend their hair is on fire, their clients are unhappy and the sky is falling. It's what they do and some are really good at it. If everything is an emergency, than nothing is an emergency because it won't all get done. Offer to sit in on discussions with clients occassionaly. You'll find that many 'nice to haves' turn into 'deal breakers' by time they get to the dev team. Be the technical liason or some other excuse to help out. Making promises you can't keep is worse than telling them what they don't want to hear in the first place. We want to do a good job so we need 8 weeks and not 5. They'll be happier in the long run.

Answer 3

Ultimately you need to educate your clients about software development and involve them in the process as much as possible. What they are seeing now is rapid delivery of new features but also bugs in the software. While they will be happy with the former they won't (or shouldn't) be happy with the latter.

You need to explain to them that with better processes while the delivery of new software will be delayed by a short amount, there'll be fewer bugs (there'll never be zero). If you can get agreement that this is the way forward you'll be able to start introducing the processes you need to regain control over your development.

Using Agile process might help here as they suggest (and in some implementation mandate) that the customer is included as part of the team. If you involve the clients very closely they'll see what's working and what you can produce first hand.

Answer 4

My (limited-experience) opinion: I think there are two problems to solve. First, the quality process. Do you use scrum/waterfall/something in between? In scrum, you can add additional tasks for each story: 1 to come up with a test script/plan, another to run it, another for a code review, etc .. In waterfall, can you simply add these steps in?

The other problem is the massive main issue that exists everywhere in software. Managing expectations. I.e. increasing time from someone shouting that they need a button to do X to having it delivered.

If you can add extra steps to the process and make a big fanfare announcement about it [we are now implementing this quality process: which will mean less time fixing bugs! and better quality results! big email/meetings etc to let them know], and deliver results regularly (ala scrum), the idea is those who you are delivering to will learn about and see the value in the extra process steps, and they will buy into it. Less time fixing bugs = more time implementing and testing features.

Clients won't accept a sudden delay in results? They pretty much have to. It's clear it can't continue as-is. Perhaps you can add the extra QA steps and then if needs be add more team members? But the quality steps are absolutely required.

Again if you use scrum or similar, you could aim for a one-week sprint so there are regular deliveries of results. That will appease people just as much as a fast turnaround.

Hope that helps to some degree..hope I haven't missed the point.

Answer 5

What you've described sounds very normal and not really alarming at all.

• Customers usually have a different mindset about what's important than engineers. We like things to be right, but the customers are faced with a reality that rewards punctuality over purity. They need to have their problems solved quickly to be competitive, and that's exactly what they're paying you for.
• Setting priorities is too big and hairy for one person to manage alone, having a backlog of important issues (so you're using JIRA), with lieutenants managing each area of interest is the best option we have for keeping impotant work at the front of the schedule.

There's nothing to worry about. That said, you can save yourself a lot of pain by shifting as much of the management tasks as possible out to the paying customer, by involving them in the development process of setting priorities, and down to technology, automating as much of the routine as possible.