-1

I started working in a stock broker that hired me and more two developers to build a 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?

  • If you intend to use the Scrum framework (or even the name) please refer to its definition in The Scrum Guide. – Alan Larimer Nov 7 '17 at 15:28
1

Is it possible that this is going to work?

This is pretty opinion-based. If you want my opinion, the answer is "maybe". Thomas raises good points about potential difficulties, but depending on the Team, these may be easily surmountable. Which leads me to...

What can I do to make it better?

"I don't know, try it and see." The single most valuable tool in Scrum (and arguably all of Agile) is the Retrospective. Try something. Inspect how well it worked. Adapt. The precepts of Agile don't have to just apply to the product. They can (and should) apply to the process, too.

So, don't spend too long worrying about what to try. Just pick a process and try it. Then (as a whole Team) refine it - or outright scrap it and try something else.

  • Upvoting this. Other than that, in your position I would avoid roles and just try implementing a WIP limit so we wouldn't constantly be switching tasks and leaving un-done work. Sprints IMO are good specifically in cases where a team has difficulty getting to a releasable point, or where formal product-level feedback milestones are needed. – yitznewton Nov 7 '17 at 15:02
-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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.