How can I organize 3 software engineers to work together with 2 clients?

Question

I started working in a stock broker that hired me and more two developers to build a piece of software to help them.

I am the newest member of the development team. My friend, another developer in the team, asked me to create a software engineering model to apply in the project, because the way they are doing now is not working.

They do not have a specific model to follow, they just decide what to do verbally, the two owners of the stock broker (which are in this case, the clients) ask them to develop a feature so the developers just stop what they were doing and start working on it, they do not have a specific list of requisites or features that the product should have...

My idea was originally to try to implement and adapt Scrum in the following terms:

• Create a product backlog ASAP.
• The product owner role would be filled by the owners of the company.
• Me and the other developer would be the Scrum Team.
• One of the developers would be the Scrum Master.
• We would have one sprint per week.
• Meetings every friday to review the last sprint and plan the next one. (Sprint Review, Retrospective and Planning)
• I do not see the necessity of a daily review meeting. I thought we could do sporadic meetings during sprints when one of the members feel necessary.

Is it possible that this is going to work? What can I do to make it better?

Answer 1

Don't use Scrum - it doesn't seem appropriate for this situation. I wrote an answer on Software Engineering Stack Exchange about the minimum number of people to implement Scrum. Right now, you describe the bare minimum number of people to form a Scrum Team (a company owner as Product Owner, 3 developers with one being the Scrum Master).

I can see a few hiccups with this plan. First, the Scrum Master needs to be able to be a coach to the Product Owner as well as the organization - can the person that you select to fill this role have the necessary influence with the owner who is acting as Product Owner and the rest of the organization? Second, do the people that you've identified have the necessary time, knowledge, and experience to function as Product Owner and Scrum Master?

Instead of Scrum, I'd start by looking at an approach modeled after Kanban.

First, create a board to contain work items. Work with the team and the people managing the product to determine what information is necessary for the team to be able to do work. This is sometimes called a Definition of Ready. Instead of having the owners interrupt work, they begin to formulate a work item that meets the Definition of Ready. They may need help from the team to do this, though - set aside time on a regular basis to manage this. You can take some guidance from "grooming" or "backlog refinement" sessions from Scrum on how to manage Definition of Ready and ensuring work is in a good state.

Then, prioritize the work items. I'd try to make sure that one person has the final say in priority ordering. The ordering of the work items determines the order that the developers do work. As soon as a developer finishes a work item, they look at the top of the backlog and choose the top-most item that they are capable of doing, progressing that from "to-do" to a done state. It is important to have work-in-progress (WIP) limits set and enforced.

Generally, the principles from Lean Software Development should be helpful. Your planning, review, and retrospective activities should happen appropriately. You may choose an approach more like Scrum where these happen on a regular cadence. Or you may choose an approach where they happen as needed.

If you have a decent backlog, good definitions of "ready" and "done" for stories, and good habits around planning, review, and retrospective, you should be able to scale your process. If your team grows, you can consider adopting a framework such as Scrum. If you start growing to multiple teams, you can look at other frameworks such as Nexus or LeSS for scaling Scrum. You can also learn from Disciplined Agile Delivery with respect to tailoring and growing your process.

Answer 2

There is several things here I identify as project risks that you are not directly addressing with your proposal. I also identify many answers address problems you don't have as an inside project team that is to collect written demands to manage liabilities.

First, you identify "two clients" and I was expecting they would be two distinct projects. However since they are the two owners, I imagine they both direct the project. In this situation it might be difficult to obtain a clear priority chart, outside what is obvious priorities for both of them they most certainly have different nuances of what they consider added value.

Second, you identify that developers interrupt themselves when they are asked to develop a feature. This look very odd to me in a situation where clients hold all the demands, in this organization it seems much more natural for developers to ask for the next task when the first is done rather than stopping something to meet a new expectation. I suspect that developers identify priorities such as bug-fixing or refactoring they start working on when they have "spare time" as well.

In this situation, the biggest organizational risk I see is not the lack of written agreement or strategical planning, which you seem to be anxious about, it's the lack of a clear arbiter in a 3-way discussion on what is the team priority. This risk is not addressed by planning, but doing a urgent prerequisite to all planning, that is sharing vision both ways, so the developers team understand what is the end business goal and the board understand that there is day-to-day quality tasks which have long-term influence on the rate and quality of new developments.

Then, and only then, you can obtain a proper backlog and a list of priorities for the weeks to come.

Answer 3

Scrum might be a good way to organise the dev team, I wouldn't skip the daily stand up though.

But by far the biggest problem I see is this verbal agreement with the client. Its fine to talk features through informally, but you need to write down the requirements and get the client to agree to them before you start work.

This can be as simple as "Ok, ill write up this meeting and email it to you."

Make sure the business goal of each feature is clearly described and that what you work on matches it.

When everything is going fine, this is an extra hassel to go through, but if it starts to go wrong you need to be able to go back and point to this kind of thing.

• "we agreed to work on feature X, feature X is done, please send moneys"

or more likely

• "we were working on feature X, you asked us to stop and instead do feature Y. That is why feature X is not complete"

Answer 4

The number one thing you need from the client is the called the acceptance criteria. How the team breaks down tasks is only the teams business.

Acceptance criteria is a short and sweet description of what needs to be demonstrated for the story to be marked as completed. Going into more than that with your product owner is not required.

You can communicate more if you like but this is the critical bit. It defines what they expect to see when you demo.

Answer 5

The first step I would take is to document a couple of processes that everyone can agree to abide by. What it sounds like you are doing is attempting to put lipstick on a pig by trying to overlay a chaotic work environment with a few titles.

The first step is to have a formal way of documenting work to be done and work that has been done. Once you have more formal documentation then it is easier to discuss the work, to estimate the work, and to prioritize the work. With more formal documentation as to current status then when changes come in, it is easier to discuss the impact of changes in work load as well as to have a better feel as to what is possible or not. In some cases new work requests can be bundled with existing work requests or work in progress.

As you build up a better sense of what you are doing and reviewing the history to see how well your estimates are holding up against the reality of doing the work, you will get better at scheduling work as well as getting better at estimating the effort for changes. And the non-technical people will get a better idea as to effort required and impact of changes.

Two tools are a first step. First a source code and document repository is needed in order to track changes to the source code and deliverables you are working on. Secondly a task and defect tracker is needed to track work in progress and to document and organize work needing to be done such as change requests and defects.

There are a number of open source products that will do both of these. The most preferable way would be to go with a hosted system as there are a number of companies providing these services and facilities and they are fairly inexpensive.

The nice thing about these is that a dashboard is pretty much a standard product offering allowing for transparency about schedules and deliverables.

Once your team has the tools in place to organize your work and your team is comfortable with these tools, using them successfully, you can then move into the more managerial and cultural aspects of your work.

I suspect that part of the problem you face is that the non-technical people within your organization do not understand or have an appreciation for the effort and time required for development. I would expect that they are used to a chaotic, multi-tasking environment with constant interruptions and changes in direction. However this doesn't work with development which requires concentration and time on task without interruption.

Your team is small enough that you do not need the kind of formal titles you are describing. You do need a few formal processes that everyone buys into and agrees to but you don't really need formal titles. And I suspect that the fewer processes and less managerial effort required for those processes the better.

Your main problem is the chaotic environment and that is a culturally and education and training problem.