How can a small web team maximize efficient use of time and prevent redoing work

Question

I'm a member of a small team that does custom websites for pretty much anything. We have the work split into 3 categories, back end and database, JavaScript functionality, and front end design.

Right now our workflow has a lot of room for improvement. We do use source control, we've tried using TFS, but were unsuccessful in scoping our tasks correctly. They were either too large, or too small, or just ignored because they were in the wrong category. We are currently using Zoho.

Zoho seems a little easier for our setup, but we're running into the same problem of not having a good order of work. We believe the trouble originates from not having a source of work.

For example, a business report might be hard to design without having the data. Our front end person cannot properly style a page without knowing what the elements will look like. They will then wait for the data to be known before creating the page. Our JavaScript person will not create the page because there is no styling or places to inject the JavaScript. The back end will not be created because there is no request for data coming from JavaScript.

This can cause some work to be redone if the report is styled, and expects an order number 1234 but instead gets ORDER_1234+123456789 the report ends up looking funny and needs to be restyled.

We've seen some really good results from this, but our process is not very efficient and occasionally causes work to be redone.

So I ask, how can a small team of varying skills create and distribute work efficiently?

PS. None of us are project manager types, so I'm not entirely sure what to tag this as.

Answer 1

It sounds like this is a breakdown not of technical approach or project management approach, but rather of conversation. Here is what I would expect to happen in the scenario you present:

First, I'd expect to see a type of conversation in which team members with all of the needed skillsets and knowledge (Javascript, Front-end, Back-end). These conversations almost always have to be face-to-face because they will usually need something like a white-board to facilitate a concrete design discussion.

My guess is that since you're talking about a report, they'd start with what information the user expects to get and how they'll use it. This will probably be at a high level at first and whoever has knowledge of what's in the DB can fill in detail where they have it off the top of their head. The participants should be very open about what they know and what they don't. They could then leave this conversation with a better idea of how each will approach the work and where they'll need to stay flexible.

After that, I would expect them to write their code in a way that is easy to modify as details come in. For example, if I need the order number, I'd probably just assume I'm getting 1234, then if it turns out I get something complex like your example, I'd add code to parse it afterward. Which brings us to the next important point: treating code like a factory line almost always leads to poor results and poor efficiency.

If three people have to work together, they need to be constantly talking and sharing their progress. Unless it is a very small feature, the team should be adding a new chunk of the report from back end all the way through at least once per day. I wouldn't try to daisy-chain the work.

Answer 2

I joined some workstreams with such issues. Generally things improve by making sure that there is proper task ownership. The teams I encountered with these issues I enforced a Kanban board with clear task ownership such as the ones you can find using Trello or JIRA. I cannot comment on Zoho never used it.

With simple rules

• once a task is assigned to anyone, the person has 36h to send it back to the project manager or the right colleague asking for additional information. Otherwise the dev implicitly recognize that he has all he needs to complete the task.
• project manager or product owner should not "spoon-feed" requirements but should proactively ask "is everything clear?" "when can you start?" "what is your level of comfort"? I usually do this every two days for each team members when project is on a rough patch. Otherwise once a week is enough.
• When starting a project you take a big risk of stalling if front-end does not have style book/guidelines, QA not have a written down list of requirements/user stories and ready to be systematic about it, back-end does not talk to both front end and dev ops, dev ops does not know the timing of the releases and the general performance parameters. In my humble experience, these require a few meetings in the beginning of the project to be tackled immediately.

Does that help?

If that does not work, consider a part-time project manager or someone to help on delivery. Will cost some money in the short term but long terms it should be very beneficial.

Answer 3

Learn about modern software development. Work collaboratively to design, implement, and verify each complete (all layers) piece of functionality. Working horizontally (within a layer) leads to imperfect stacks.

Manifesto for Agile Software Development

Vertical Slicing

The Nature of Software Development

Answer 4

First of all, it seems that you have issues with the requirements (they are not clear, lack of understanding, lack of commitment,... etc.).

In the case you need to:-

1. Make sure that the team understands the requirements before starting the work.
2. Daily Stand up meeting (10-15 minute) to know three things:- what was done yesterday, what will be done today and what are the blockers (if any).
3. After every iteration do a retrospective meeting, to know what went well and what needs improvement.

After that you need to improve the development process gradually.