4

I work with a small team (4 developers) writing firmware and software for our custom hardware. I'm looking into better ways to organise the team and better define processes.

Our Current Setup

  • Developers are generally working on 2-3 projects at a time.

  • We have projects that work in an iterative sort of way, where a developer is in regular contact with the customer and features are slowly added and bugs fixed.

  • We also have projects with fixed delivery dates, and with long lead times, final hardware might appear only a few weeks before delivery. The fixed projects are usually small changes to an existing product or implementation and the work is somehow intermingled.

  • We are also moving from consulting to products, so we are occasionally adding features that we think will add value, at our own cost.

The Issues

We have a weekly meeting where proportions of time are allotted to each project. "Customer A wants to test feature X next week", so the required time is allotted. "Customer B is having issues with Y, could developer P drive down and take a look?", etc.

When we're busy, these plans are very loosely followed. Issues arise and lower priority stuff gets pushed back. Sometimes, priorities are not clear to developers so there is friction when priorities appear to change. The next week there will be a realisation that we're getting behind on project Z and we all pull-off some long days.

I'm told that this is all quite common for a small start-up in our industry, but I'm just looking for ways to limit the number of "pizza in the office" all-nighters.

sjt
  • 1,607
  • 11
  • 14
Tim
  • 7,746
  • 3
  • 49
  • 83
  • Why did you have an Agile Tag on here? Is it that you want to become Agile or do you think you are already Agile? Which of the 12 Agile principles are you following? In your description I can see only a couple of Agile principles being followed. – sjt Nov 30 '10 at 01:26

4 Answers4

3

Developers are generally working on 2-3 projects at a time.

Multitasking is incredibly inefficient. Switching the brain from one task to another requires time for the gears to change over.

When we're busy, these plans are very loosely followed.

Then why create plans at all?

Is it all possible to dedicate just one developer to one task / product / customer? So developer P is the only one who talks to customer B? (Certainly the developer would need to document exactly what he's doing in case he gets hit by a bus, but he should be recording issues and roadmaps anyway.)

The next week there will be a realisation that we're getting behind on project Z and we all pull-off some long days.

If there had been only one developer on project Z anyway, he wouldn't have been distracted by customer A's problems.

Don't think in terms of a pool of developers serving a pool of customers, think of one developer for a given customer. (This can make vacation planning a little tougher, but if you're constantly pulling all-nighters, you aren't spending enough time away from the office anyhow.)

chrisaycock
  • 36,470
  • 14
  • 88
  • 125
  • Customers generally only deal with one developer, but because we are such a small team doing the hardware, firmware and software, nearly everybody is involved in every project. – Tim Nov 29 '10 at 02:35
  • Do you have to completely customize the hardware and software for everyone who buys your product? That doesn't sound like a scalable business model. You need some way to reuse previous work. – chrisaycock Nov 29 '10 at 02:39
  • Hardware is pretty fixed. But if a customer is committed to purchasing 1000 units, we'll add functionality through an add-on board but development time and further hardware costs are charged out. The companies we deal with are also happy to pay to have the software/firmware integrated into their existing systems, so we cant turn the work down! – Tim Nov 29 '10 at 02:51
  • @Jim If the customers are more than happy to pay, why not hire more developers? Brooks's Law won't apply if you assign only one developer per customer. – chrisaycock Nov 29 '10 at 19:48
2

I'm told that this is all quite common for a small start-up in our industry, but I'm just looking for ways to limit the number of "pizza in the office" all-nighters.

Aren't we all.

"Customer A wants to test feature X next week", so the required time is allotted.

Allotted by whom?

Do you create your own schedules? If not, the only response to management creating a schedule for you is all-nighters.

Realistic non-all-nighter schedules will bother management. Until you can prove that your customers want a better schedule with fewer all-nighters, there isn't much you can do.

The only way to reduce the all-nighters is to get stuff done sooner. But if the hardware doesn't arrive sooner, there isn't much you can do, is there?

S.Lott
  • 384,516
  • 81
  • 508
  • 779
  • For fixed duration based projects we are generally well involved in the schedules. The incremental projects are more difficult as the 'end game' is only loosely defined. Usually they have agreed to buy the hardware and we're waiting on software features to be negotiated. We'll get a start on it as we're developing something similar for another customer. – Tim Nov 29 '10 at 01:42
  • @Jim: "we are generally well involved in the schedules" and you still have "pizza in the office" all-nighters? Since you're creating your own problem, I'm not sure what your question is. Perhaps you should update the question to clarify what you want to do differently. – S.Lott Nov 29 '10 at 02:10
  • We do get involved with the schedules for fixed duration projects, but the iterative projects are just ongoing and management allocate whatever time they feel appropriate for product development. As a young team, our estimates could get a lot better! – Tim Nov 29 '10 at 02:41
  • @Jim: "management allocate whatever time they feel appropriate for product development". "the only response to management creating a schedule for you is all-nighters". I don't get your comments. Please **update** your question to clarify what you want to do differently. Or, are you just complaining? I don't get the question at all. Please clarify what you'd like to change. – S.Lott Nov 29 '10 at 12:29
1

Two thoughts: drive quality and improve estimates.

I work in a small software shop that produces a product. The most significant difference between us and other shops of a similar size I've worked in a is full time QA (now more than one). The value this person should bring on day one is not testing until the tests are written out. We use TestLink. There are several reasons for this approach:

  1. Repeating tests to find regression bugs. You change something, what did it break?
  2. Thinking through how to test functionality ahead of time - this is a cheek-by-jowl activity between developer and QA, and if it doesn't hurt, you're probably doing it wrong.
  3. Having someone else test and validate your code is a Good Idea.

Put some structure around you estimation activity. Reuse a format, be it Excel, MS Project or something else (at least do it digitally). Do so, and you'll start to see patterns repeating around what you do building software. Generally speaking include time in your estimates for thinking about it (a.k.a. design), building, testing (QA), fixing and deployment. Also, read McConnell's book Software Estimation, use anything you think is worthwhile from it, it's a great book.

Poor quality means longer development cycles. Most effective step is QA, short of that unit tests. If it were a web app I'd also suggest something like Selenium, but you're dealing with hardware so not sure what can be done. Improving estimates means the ability to attempt forecasting when things will suck, which may not sound like much, but knowing ahead of time can be cathartic.

orangepips
  • 9,891
  • 6
  • 33
  • 57
-1

I suggest you follow the Scrum Framework. Create a Scrum Environment with an enterprise product. Have product Teams working on the features for their own individual products, which is a part of the combined enterprise product. If you have the resources have a production/issues support and infrastructure Scrum Team. If the issues are coming your way too quickly, have the infrastructure Team try following Kanban or Scrumban.

The Scrum Framework in itself will solve most of your problems if adopted properly.

sjt
  • 1,607
  • 11
  • 14