A) Do shorter iterations, so there’s less chance of disruption, and it’s easier for people to learn that they can wait a few days.

B) Turn as much work as possible into cards and be strict about using Yesterday’s Weather to decide how much you can do. Something new comes up? Then something else gets put off.

C) If you can’t keep all the urgent stuff away until the next iteration, assign one person to handle fires for the week.

D) Do a lot of pairing. If it feels like islands, there’s probably not enough cross training or collaboration.

E) Explain to the bosses that they need to decide between the appearance of doing a lot and actually getting a lot done. If people always feel behind, that’s not a sign of bad execution, it’s a sign of over-ambitious planning.

Basically, you’re right to focus on the team feeling out of control. The team must firmly believe that the best way to serve the business is to be disciplined about how much work they take on, and how well they do it.

Good luck, and feel free to drop me a line with updates.

We have 4 developers, 2 designers and customer service doing double-duty as QA. We are maintaining our 10 year old version 3 monster CRM SaaS web based application, doing professional services integration contracts, biz dev, new features, and supporting a network of partners using our api. Basically, we are biting off quite a bit for a small team.

The issue is that everyone wears a few hats so accountability is sometimes to “the team” and sometimes elsewhere. Our sprint goals are often secondary and therefore we miss out on important team dynamics.

Some mornings at our stand up it feels like six islands and people just reporting tasks and why they didn’t work on the sprint cards. The team then gives up on the sprint goal because they are not in control.

There have been a few sprints with good energy and good team dynamics, but it is fragile and I suppose my question is how to hold the line when the business goes through periods of chaos (priorities coming from many directions with little warning or time to respond). It’s not always like that, but we’re neck deep in it now and Agile is taking a lot of heat in the form of misplaced frustration.

Depends on the team size, but I’d expect to spend 90-120m for that. Add in a regular 1-hour meeting for estimation to prep for the iteration planning meeting, and <10 minutes a day for standups, and that’s less than 10% of one’s working time allocated for regular meetings. That’s about the norm for the teams I coach.

I don’t think making the meetings happen less often should save much time. The more often a meeting happens, the less people worry about getting their thing in right now; there’s always next time. The less fresh things are in your minds, the more time it will take to cover them. Plus, you can keep shorter meetings crisper.

If you feel like there is a lot of wasted time that would be doubled by having shorter meetings twice as often, then perhaps you should ask yourself why. Do people not come on time? Are the meetings not time-boxed? Do you lack effective ways of cutting short tangents, distractions, bloviations, and discussions with no outcome? Is the team not fully focused on delivering value early and often? Those are all things I regularly ask with bad meetings.