What would you do to improve the working of a small Development team? [closed]

Question

My company is having a reshuffle and I'm applying for my boss' job as he's moved up the ladder. The new role would give me a chance to move our development team into the 21st century and I'd like to make sure that:

1. I can provide sensible suggestions in the interview to get the job so I can fix the team
2. If I get the job I can actually enact some changes to actually improve the lives of the developers and their output.

I want to know what I can suggest to improve the way we work, because I think it's a mess but every time I've suggested a change it's been shot down because any time spend implementing the change would be time that isn't spent developing software.

Here is the state of play at the moment:

• My team consists of 3-4 developers (Mainly Java but I do some .Net work)
• Each member of the team is usually works on 2-3 projects at a time
• We are each responsible for the entire life cycle of the project from design to testing.
• Usually only one person works on a project (Although we have the odd project that will have more than one person working on it.)
• Projects tend to be bespoke to single customer, or are really heavilly reliant on a particular customer environment.
• We have 2-3 "Products" which we evolve to meet customer requirements.
• We use SVN for source control
• We don't do continuous integration (I'd like to start)
• We use a really basic bug tracker for internal issue tracking (I'd like to move to an issue/task management system)

Any changes that bring a sudden dip in revenue generation will probably be rejected, the company isn't structured for development most of the rest of the technical team's jobs can be broken down to install this piece of hardware, configure that piece of hardware and once a job is done it's done and you never have to look at it again. This mentality has crept into development team because it's part of the company culture.

Answer 1

You seem to have too grand ideas for your small team, but I would advice you start small and slowly work your way to incremental improvements in efficiency.

For example, whilst something like continuous integration would help you all improve the speed of your builds, and hopefully the quality of your releases, that's all it'll do becuase each team member works alone on a project at a time. Its worth the time spent implementing it solely to improve the standardisation and speed of your builds, not for any other reason given your team setup.

However, moving from a simply bug tracker to a full-blow task management solution would not help anyone. If each team member works alone, and has a bug allocated to him, does it really help him escalate a bug though statuses and update the owner and other fields? Does it help anyone else who is not going to look at his code?

You need to consider what improvements will really make a difference, not which improvements you'd like to make just because they're there to be made.

I would drop all the .net work, there's no point in having a single team member working with a different system. I'd probably work on some set of VMs to replicate customer environments so testing or development can be quicker to set up. I'd also look at managing the configuration sets that each customer has in some way.

Answer 2

I am now more or less in the position you're applying for. It's not even been six months so I lack the experience to give you a truly wise advice, but here is what I have learned so far.

First and foremost,

You need to be patient

There are always plenty of broken things we want to get fixed right away. But you can only allocate this much amount of resources to it, changing things mean it will take time to get used to it, and changing to many things at the same time might alienate your team.

This being said,

You want continuous integration

You, your team, your hierarchy, your customers, you all want continuous integration. Even if some of you don't think so. Set up a build server with incremental builds, nightly builds, documentation generation, automatic tests, direct access to the latest stable package, and you will make their day.

You want to get rid of anything that wastes time

Your team should be spending their time doing great stuff. But most likely, they spend a sizable amount of it doing something totally unproductive. Identify all the things that steal time from them, things they should not have to do, things a machine could do, things that should not be done more than once, and fix them. You're one of them, you know where time is wasted and what they really want to be doing, right?

That build process that takes a dozen steps that you just "have to know"? Get it done by a script once and for all. For some reason it cannot be fully automated (yet), document it!

That compilation that takes two hours to complete? Do what it takes to reduce it to an acceptable amount of time: chop it, profile it, assign a task to someone, but don't let your team stare at compiling screens.

That one issue that keeps coming back every other month and each time takes half a day to figure out? Get it fixed, really fixed, write tests for it, and make sure the test is run automatically with every new build (I'm not even talking about TDD here, simply regression testing and automated tests).

That project you're working on that takes 5 minutes to launch? Take the few hours it takes to identify the bottleneck and get it to launch in a flash. While you're at it, why relaunching when you can simply reload the data!

That workstation that takes ten minutes to boot in the morning? Give it RAM, give it an SSD, give whatever it takes so it doesn't waste hours of engineers time when a hundred bucks would cut it.

That server that takes so much time to handle your requests you're seriously wondering if it's not sequencing DNA? Get someone to identify the problem.

Those people who keep coming several times a day with incomplete half-thought requests that were not even validated yet? Tell them to come to you or to one person in particular, but don't let them interrupt your team's work. Shade them from these annoying distractions, from irrelevant details, and give them well processed information they can work with.

That bunch of documents spread all over the intranet that nobody ever knows where to find or which version to use? Get it all in a same place (or at least referenced in a same place), dated, with a version and a contact.

Your hierarchy will frown upon some of these ideas, but here one of your best arguments is the technical debt metaphor. Also recognize what doesn't need to be changed though: "If it ain't broke, don't fix it." Or put differently, "Is it worth the time?"

See also: How can I convince management to deal with technical debt?

You don't want to get too crazy

Your team is small, so no need to hammer them with overly complicated processes. Hey the point was to get stuff out of their way! And again, be patient, bring one change at a time and let it sink in, and fine tune the wheels until it runs smoothly.

Since your team is small, you can also experiment. Once you've identified a specific problem you want to nail (say, the bug tracker is too cumbersome for example), see what solutions are available to you (bugzilla, Redmine, Trac, Atlassian, Trello, old fashioned white-board...), then try one, maybe only for yourself, maybe with just another team member, see how it works, how it's accepted, and adapt. The solution turns out to be uneasy? Try something else. Is it better? Good stick with it.

These were my two cents on the topic. As I said, I'm quite new to this too, so people who know better are very welcome to comment. :)

Answer 3

There are some good thoughts in the other answers, particularly @gbjbaanb. However, I can't help but think that something is missing from the question. What are the problems that the team has currently? What is preventing the team from fully contributing to the success of the business?

Not doing continuous integration isn't a problem, unless it is preventing the team from delivering in a high quality way. The absence of a task management system isn't a problem unless the team is losing track of tasks or is having difficulty communicating status. These are good practices, that probably won't hurt, but if they aren't addressing the things that are keeping the team from succeeding directly, the management won't be interested.

Your starting point should be a diagnosis of where the problems in delivery exist and where opportunities for better contribution to the success of the company exist. Ask yourself the following questions:

1. Can the team help the business grow? What is the management team trying to accomplish with the part of the business that does software development? Are they trying to expand the team? Are they trying to sell more complex, larger projects? Is there some overarching goal that can't be met because of the maturity of the development team?
2. Are there currently delivery problems that are interfering with the success of the business? What are the biggest problems you have from a delivery perspective? Does the team miss deadlines? Do they get the requirements wrong? What do your clients think about the quality of the work being delivered? Is the team able to be responsive to changing customer needs?

Depending on the answers to these questions, you will get a sense of what problems are important to address first, and where there is opportunity to contribute to the growth of the company. There are a few different ways that this could play out. Here are some examples:

1. One common problem is a lack of transparency - i.e., the customer doesn't know how the system is shaping up until it is almost done and then they are disappointed with the result. A solution to this could be a deploying more frequently throughout the development cycle and exposing the in progress work to the customer. CI could help by ensuring that there is always a working version of the build and minimizing integration headaches between these deployments, but the key in this case is getting software in front of customers often and early.
2. It could well be that the team is just writing bad code that is hard to maintain and difficult to fix. In this case, CI and task tracking, for example, don't really help much. You probably do need collaboration across the team and perhaps code reviews to ensure quality. In this case some focus on educating the team on best practices for writing quality code would also help.
3. You mention that people are responsible for their own QA. This seems like a potential red flag. Is testing automated? Could this help reduce manual QA effort? Might it be better to have a dedicated QA person responsible for integration testing before code gets to customers?

All, or none, of these problems might exist in your environment. The point is that there is no set of improvements that make sense in any and all environments. You need to be driven by the specific challenges that exist at your company. Any of the so called "best" practices mentioned above can help, but they can also be wasted effort and money if you are addressing problems that don't exist.

Answer 4

So your boss got a promotion, I guess he (at least partly) will be involved in the application process for a new boss.

Your boss probably(/hopefully) got promoted because he did a good job. That means that your current process is working and is profitable. You need to recognize the strengths of the current model.

Also, the "I want to change everything since it's broken" will probably not get you the job if the old boss is part of the hiring, since this will mean that you indirectly call his work for broken (he has run the team this way and he got a promotion). Actually, he has turned down many of your ideas and that lead him to a promotion. That means, your ideas was wrong. (Not wrong in a technical sense but in the eyes of the company, which is the only thing that matters).

You should not try to "fix the team". You should improve your deliverables. For example, reducing the buss factor would make it possible for you to deliver all year around, that would reduce the revenue dip during vacations (that you talked about).

Take small steps in the direction you want.

---

If we assume that your boss did a bad job and have accumulated a technical debt you should ask yourself if you really want the job. This debt will somehow show itself in the future and then it most likely will be seen as the fault of the new boss.

If this is true and you get the job you'll need to do huge changes to the process without management support. That's almost impossible. You need to take small steps that adds value and you'll need to work hard on your leadership to be able to lead your team through changes. I actually don't think this is a technical question at all and maybe you'll get a better answer in the management section of Stack Exchange.

Remember that as a developer you had the freedom of choosing or want to choose the technical best approach. As a boss you have more factors to account for and the technical best solution does not have to be the best solution over all (for example, the benefits of switching to git may be spoiled by the education your team will need).

To try to answer the technical aspect of your question:

• Improve the bus factor by never letting anyone work alone on a project. There's several ways you can do that, for example with pair-programming or code-reviews. Find a way that fits your team.
• Make sure your products are maintained longterm. The usual way for this is to have a "product owner" for each product which will be in charge of the longterm development of that product. This will reduce technical debt and make sure that changes done to one clients codebase is backported to the main codebase for the next customer.
• review your tools. You might benefit from the improved branching and merging features of a DVCS instead of SVN, but it's not sure. Specially not if your team is comfortable with svn but not with dvcs. Do a review of all your tools, .NET, java, svn, bug/ticket-system. One at a time!
• How can you improve your responsiveness to customers need? Can you use some type of CRM system to improve your customer relationship?

Answer 5

What do you use to build your products? If you use ANT or Maven for example, there are numerous plug-ins/tasks such as checkstyle that you can use to enforce coding standards.

Having one person per product is highly undesirable. Do you do peer code reviews? This could be one way of exposing the other developers to the other products. At the very least I would suggest knowledge transfer sessions, to ensure if you suddenly lose a developer they don't take all knowledge of the product with them!

Answer 6

1) I would recommend picking up GIT as a version control system, the logic behind this is that its a distributed version control system opposed to a regular version control system. This basically means that the developers can commit locally as much as they want without pushing up to the remote repo, this not only helps developers commit more frequently and have more control over their merging and branching, but also gives additional redundancy as if the main server goes down you can rebuild it from peoples repos.

See more about the topic here: https://stackoverflow.com/questions/871/why-is-git-better-than-subversion

2) I would adopt CI as quickly as possible, makes your life a lot simpler. I tend to use Teamcity and Youtrack, as they are both free and brilliant tools which are robust and easy to setup and manage. You can then have it so a developer can commit in GIT (or SVN) having a message like:

#task-1 Fixed
Done something to fix task 1

Which would then get pulled through into TeamCity which would automatically run your build script (assuming it contains steps to template files, compile, test, package) then would integrate with YouTrack allowing that issue to be updated on the Agile Board (you dont have to be agile to use the benefits of the board). So you have a COMPLETE development eco-system where you can see for every commit, why it happened, what it was and what was changed, or even look at a bug/tasks history to see who worked on it when.

3) Use environmental build scripts if you dont already, something like RAKE (and Albacore for .net) will get you up and running. You can then have it so a developer checks out a project from GIT (or SVN) and runs a build script/batch file which will setup the developers IIS/Apache servers, their configuration files, the database etc. This way you can make sure all developers can teardown and setup their environments easily and get up and running with projects quickly, but also you can use this same build script on your CI server in the previous step. You ideally want the generic scripts for stuff like template, compile, setup web server, setup database, unit tests, integration tests etc, then a set of specific properties/config files describing each environment, so dev would have configurations to use Database Server A and Web Server B, whereas live environment may use Database Server Z and Web Servers C and D.

4) If you dont already do so, train up on automated testing. Mainly on unit testing and mocking, then integration testing and acceptance testing. If you are a web house go look into selenium/webdriver and how you can automate your browser testing. This can then be run on your build server to prove that a commit has not broken the server (assuming you use a build script).

5) Try to make some sort of shared knowledge repository, it sounds like everyone is a knowledge silo there, so if there is an issue with Project A, only Developer A can look at it. So if Developer A manages Project A, F, H, J and walks from the company you will then have 4 unknowns. So install a wiki or some other tool which will allow you to collate information so people can give an overview of each project and the quirks and setup instructions etc, if you combine this with the automated tests and build scripts almost any developer can pick up the project, build it, test it and see what needs to be fixed etc.

Hope that helps