It sounds like what you’re saying boils down to:

• A self-managing, self-designing Scrum team only exists when the entire team is experienced and committed.
• In more realistic situations, management should be allowed to manage the team and influence design decisions in order to avoid bigger problems.

If this is right, then the problem isn’t with Scrum, but with how your team has adopted it. Either

• It’s still early and everyone is still learning to be efficient Agile team members; or
• Agile and Scrum aren’t a good fit for the team’s personality; or
• Agile and Scrum aren’t a good fir for the project demands; or, more likely
• Agile and Scrum aren’t compatible with current Management’s concept of management.

Scrum and Agile aren’t only about iterative software releases. It’s also about improving the software development lifecycle. Each iteration should bring improvements to the application and, equally important, to the development process as well. This means there’s going to be a period up front where things may not work all that well, but if you’re team is on board, things will get better.

IF your team is on board. I’ve seen Scrum fail simply because somebody wouldn’t play ball. Suddenly, the efforts of 5 people to be Agile are completely derailed because one other person’s incentives don’t line up with the Agile/Scrum ethos. Don’t be that person! You may not like what’s going on, but why is that? Is there a real problem? Is the team simply not adopting Agile effectively, or is this new approach simply still foreign and scary?

It is quite possible that you are perfectly comfortable with Agile and Scrum, and that your team is indeed failing at improving or delivering. In this case, you can either decide to ditch Agile development, or invest more time and effort in fixing the problem. Do you have a Scrum Master? Does everyone in the team understand what Agile development is? People usually shy away from Agile development when they think it will make them more vulnerable or liable. This shouldn’t be the case, but sometimes people feel that way…

Or, even worse, sometime’s it’s even true. Ask yourself if Agile/Scrum/iterative software development actually makes sense in your situation. If not, adopting it might put your team under undue stress. I’ve seen projects follow iterative development when Waterfall would have suited everyone much more. Don’t simply adopt iterative development because it’s the -in- thing. Make sure it fits your project/business. If it does, great! If it doesn’t, find a development and management style that does.

But, ultimately, if you do chose to follow an Agile/Scrum approach, make sure everyone is properly educated on the process, the tools, the goals, the advantages, and the sacrifices. In your situation, it seems like people are forgetting that a highly iterative process can sacrifice Design and Architecture in the short term because sprints react to the ever evolving needs of the Product Owner. But these are short term sacrifices. Your team should ask for hardening sprints to chip away at their accumulated debts (whether they be technical, architectural, testing, etc). That’s how Agile development balances reactivity and maintainability.

whew. I think that’s all for now!

One of the keys to Agile development (and Scrum in particular) is a shortened feedback loop. That is, the development team are expected to deliver working software every two to four weeks. If, after one or three sprints, the team is not delivering, management knows there is a problem and can change direction.

Take your scenarios:

1. Contractors/disinterested team members. Either the team isn’t delivering (get new contractors STET) or they are delivering unmaintainable software. This should come into evidence fairly quickly if they are not producing repeatable (automated!) tests that demonstrate the software actually works, and if they start panicking when a new user story mandates the reworking of code from an earlier sprint. Scrum does not negate the need for IT governance, and this is especially so when working with contractors.
2. Inexperienced developers are an issue no matter what the project. The solution (no matter what the methodology) is to put at least one experienced programmer on every team. Again, it should be evident quickly that the team doesn’t know what it’s doing.
3. Masochists/Heros. Again, the requirement of delivering working software every several weeks should make it evident that the team is wasting time. If the team starts working stupid hours, don’t let them take on as many stories the next sprint.
4. Bikeshedders Not delivering==problem that is solvable.

A command and control structure on projects doesn’t really handle these issues any better. It cannot instill the sense of ownership needed for problem 1. It requires the involvement of experienced developers (which is the solution for item 2 either way). It plays into the masochist/would-be hero’s hands, unfortunately resulting in high-risk situations and shoddy software. And, it probably won’t show and solve the team’s inability to make technical decisions any faster than Scrum does.

Scrum is a fail-fast methodology (or framework, anyway). That’s its biggest strength.

This is why it’s not enough to focus on Scrum or technology — talent selection is in part what makes or breaks the project. No methodology, supervision or policies can make up for lack of talent.

These four examples examples are exactly why it’s important for the team to include some good senior developers who have experience delivering complex projects, and who are committed (through personal interest and financial incentives) to ensuring that the project stays on track. The team does not have to be comprised entirely of experienced devs, just needs to have them in lead positions.

In case of outsourced project, it is good to be sure that both the outsourcing team has appropriate skills and experience, as well as having experienced developer internally who would monitor the output of the outsourced team, possibly doing a lot of hand-holding, writing specs, and reviewing the code (when source code is part of the delivery).

The argument is not to let an incompetent team manage itself? Why would anyone want to put a Scrum team in place and fill it with people who aren’t capable of doing the job?

Maybe this manager with the better technical ideas needs to be on the team?

You want someone else to make the technical choice, but you think this team is going to be able to develop and schedule with this preferential technology when the entire team opposes it. Good luck with that.

I can’t support an argument against something because there are situation where it won’t work that aren’t common. I would argue the teams described in this question would produce poor code regardless of the amount of supervision. If one manager could over-come the incompetence of an entire team, creating software wouldn’t be so difficult, but that’s not the case.

It sounds like the familiar Architecture and Technical Debt debate your having.
You don’t have any mention of an “Architect Role”, which may be part of the problem For some great resource on “Software Architects” see: http://www.codingthearchitecture.com/authors/sbrown/. Simon Brown has lots of good ideas trying to address many of the issues your currently facing.

Seeing you’re London based, there is a good Software Architecture conference in London annually. See a review I’ve written about the value of the conference. Software Architecture Conference – London 2012 by Jamie Clayton

I would also keep an eye on software decision for “resume padding”. Many short term developers wanting to use a technology combination based on no business reason other than to improve there own skills.

After many years of working (fighting) with business decision makers and accountant/financial staff making business decisions (tight wads), that software maintenance and support is very important and should be factored into corporate budgets because it’s easily becomes 80% of the cost of running the software, while the initial Scrum/Project represents 20% over the lifetime of a corporate software solution.

Pitch to the business an in-house Maintenance/Licensing contract for any corporate software, as 20%-30% of the upfront project cost per-annum. This is what any commercial software vendor would charge as a minimum. If the business will not accept those costs as part of the Cost/Benefit, then you should advise against the project (let them make the fatal decision).

Here are some things that occurred to me after writing this question:

• A development team often sits within a larger organisation which has its own policies and practices (I’m not talking about waterfall-style things like “must have a complete project requirement specification before writing code” which are incompatible with Scrum!). There may be requirements for how or when deployments have to be done, coding style guides or coding standards, etc. – some of these could be guidelines, some of them could be “must-fulfill” requirements. Then, realistically, I think Scrum is about the team deciding how to do things within those constraints and guidelines (and where it feels it is necessary, e.g. to remove impediments, trying to persuade the organisation to change them) but not about a team unilaterally ignoring them. Or it shouldn’t be, anyway.
• A development team never has an absolutely unlimited budget. If a design or architectural decision has budget impact (e.g. acquiring new servers or VMs for a distributed NoSQL database, or longer initial development time or a risk of that), it may need to be signed off by someone with authority on budgetary matters. Scrum cannot change that.
• Training, or even just opportunities for experienced developers to chat with an inexperienced team, can help to avoid beginner mistakes such as “God classes”.
• Code review, pair programming, or even just working on each other’s code (which should be a normal event due to the cross-functional aspect of Scrum), can uncover problems early. Even just looking at someone’s code that is not your own can make you more objective about the impact of design decisions. Many programmers love to poke holes in other people’s work, let’s take advantage of that tendency 😉

The scenarios you are describing can occur in any methodologies, they necessary don’t have any thing to do with your Scrum/Agile adaptation.
If you are hiring developers who have already worked within Agile Framework most of them know the impact their coding might have on the maintenance aspect of the project.