A development workflow for a team of 3 developers that minimizes outside interruptions?

Question

My question is similar to these two topics;

• A software development workflow for a company of 2-4 developers?
• How to manage a Web Project

but where my team fails is when we are all working on separate projects and we get bombarded with input from many other departments.

I'm sure Scrum and Agile are similar in that, once the project is started after its defined, there should be very little if not no input or changes to the plan. This tends to fail every time no matter the size of the project. We do have the support of the company and product owner but some of these problems originate from that very same person.

How can we minimize these outside interruptions to the project?

Answer 1

The following is pulled from a few different sources (including my own experience as a solo freelancer with multiple clients); however, you mentioned Agile and Scrum - so my terminology will be similar.

1. Shorter development efforts, with extended silence:

   What I found worked for me was to have, essentially, a one week sprint. On Monday, you meet the product owners - or collect the input from all of them and set priorities for the week. Developers forecast what they think they can do by Friday. Then, get to work.

   Friday comes, you show what you did. The three of you chat about what worked in the processes you actually control - and make improvements. Weekend. Monday - rinse and repeat.

   If the product owner(s) can't calm down for 4 days and let you do your work uninterrupted, then there's probably a bigger problem.

2. Definition of done:

   You all (product owners included) should define what "done" means for each task that will be in the sprint. It may start out as "it just works" - but there should be a drive/desire amongst the team to refine and mature the definition to include engineering excellence.

3. Definition of ready:

   Don't accept into a sprint items which have not been crystalized to a certain, agreed upon, state. This may start out as simple and very generic descriptions (button in top left) - but there should be a drive/desire to improve to having mock-ups, maybe multiple requirements written in an FDD or BDD style in the language of the business...and so on.

4. The only way to change direction is to stop first:

   So, you've got:

   • Entrance criteria (ex. If an item isn't broken down enough to be done in 1 week - we don't do it);
   • Exit criteria (ex. It just works); and
   • A communication plan (we meet Mondays and Fridays - and possibly daily for 15 minutes, but that should be more for the team doing the work - not the product owner) - between that time the PO can't say anything...

   If, for whatever reason, the product owner(s) has (have) to change things mid-sprint, it's okay and, in scrum at least, there's a simple way to do it - tell the developers to stop what they're doing, possibly abandon all the work to date, and start again.

   If this happens, I highly recommend modifying sprint lengths to get back on the Monday-Friday timetable (it works wonders if you're on that sort of weekday schedule - modify for whenever the team gets time off).

5. Two levels of defects - developers only hear about one during a sprint:

   Level 1 defects mean stuff is crashing, horribly, it's bad, really bad. Level 2 is everything else - we found a glitch and a workaround, or we want this to be yellow.

   During a sprint (all 4 days of it, because the 5th cumulatively is taken up by meetings), the team is only informed of level 1 defects. Further, when the team is informed of a level 1 defect - all of the developers stop what they're doing and assist to fix the problem. (This is known as "stopping the line" in Lean Manufacturing.)

Now, you may not be able to (or want to) implement all of these. Further, you're corporate culture may not be one where a dramatic shift like this is a good idea. So, start slow.

Maybe the Monday-Friday book-end meetings that cover: What we are going to do; what we did do; and, for the developers, how can we do it better? Then start adding things to it...at the sprint review (Friday meeting with the Product Owner) is a great place to suggest having a definition of done and ready. Number 4 may not need to be brought up at all - but, if the PO interrupts, just inform them on the day; or, again, at the sprint review just bring it up and say, "You know, when you do that..."

Hope that helps.

Answer 2

TL;DR

[W]here my team fails is when we are all working on separate projects and we get bombarded with input from many other departments.

Scrum is designed to handle exactly the problem you describe. Specifically:

1. Your team should be collaboratively working on a single project, not multiple projects. If you have multiple projects running simultaneously, you will need multiple teams.
2. The roles of Product Owner and Scrum Master are designed to limit the negative impact of "bombardment" from outside the team. It is fundamentally the Product Owner's job to filter stakeholder requirements and manage them through the Product Backlog.

Change Control Enforced by Sprint Planning

Scrum is a framework that embraces change, but enforces change control by limiting most developer-facing changes to the Backlog Grooming and Sprint Planning phases of the project.

The sprint itself is a protected work zone that does not allow new work or changed requirements into the iteration. If a change is truly important enough to warrant an explicit termination of the current sprint and a return to Sprint Planning, then the Product Owner is empowered to do that.

The fundamental idea is that the project remains flexible, but that making changes within an iteration has a real cost that needs to be made explicit to the project and to its parent organization. It is the Scrum Master's job to educate the organization about this framework requirement, and to enforce the rules of Scrum within the team and with the Product Owner.

Stakeholders still get what they want, but it requires a shift in both stakeholder and Scrum Team behavior. See below for more specifics.

Adjusting Sprint Length

Keeping your sprint lengths short increase overhead and reduce the maximum size of the team's units of work. However, it offers the project more inspect-and-adapt cycles during the life of the project, so this is an area where each project must find its own optimum sprint length.

Answer 3

While I agree with the answers above theoretically, see my answer in this link for how I managed to implement this. I know it can be extremely challenging to apply what is effectively an ideal in a real world environment that is currently chaos. I found the key to be small steps and introducing an 'inspect and adapt' process.

https://softwareengineering.stackexchange.com/questions/206381/does-scrum-lend-itself-to-multi-project-environments/207246#207246