Take the 2-minute tour ×

I appreciate that this question may be controversial. In a sense, it is the flip-side of the question "Business trying to make technical decisions".

In Scrum, the development team is supposed to be collectively responsible for making design and technical and code-level decisions, to fulfill the customer requirements. There is a division of responsibility and power between the product owner, who defines and prioritises the stories by communicating with stakeholders, and the team, who decide how to implement the stories.

I think this is motivated by the belief that, since developers are intimately familiar with the code they have written so far, and all the information they have memorised or noted about the project, and they will face the consequences of poor decisions when they have to modify the code in future, they are best placed to make design decisions. And if in hindsight they realise they made a bad decision, it will be a very valuable learning experience for them, and they won't be able to blame management for what went wrong. In theory, I agree with all this. But (to kind of play devil's advocate) I can see several situations in which following this principle to the letter could be a bad idea:

  1. The development team are mostly either temporary contractors, are (unbenownst to others) intending to jump ship, or are going to be made redundant after shipping this project, or are going to move to another project and there is an entirely separate team which will do "code maintenance". (A good example of this might be: a typical outsourced government computerisation project.) So, for any of these reasons, the team mostly aren't the people who will be doing the actual maintenance.
  2. Or, the development team are all inexperienced developers who don't really have a clear idea of the maintainability problems that can be caused by slipshod development practices or poor design decisions. While they have an incentive in theory to do the right things, the incentive isn't working yet because they haven't been burned enough times (or they haven't acknowledged the connection between sloppy coding practices and getting burned).
  3. The development team like making big mistakes and working crazy hours to fix or work around them because (a) they are workaholics, (b) they like wasting time writing boilerplate code or using some bad old framework because it gives them a sense of job security, or (c) it makes them look like or feel like heroes.
  4. The team like to endlessly bikeshed, or discuss endless different permutations of ideas, or add "internally-visible features" which are low-value, while the business really needs them to deliver value faster, and come on, good enough is good enough!

There may be others in the organisation who could provide a variety of useful inputs into design and technical decisions: More experienced developers; Polyglot developers; Specialists, including DBAs (who may not necessarily be in the scrum team); Managers, who may be cynical and may have seen over-ambitious or wrong-headed architectures go awry too many times.

But it's not just about getting input from people with valuable experience. More than this, isn't it fundamentally sometimes necessary for management (at any level) to be able to say "No, this way of implementing it would be a bad idea. Do it this way instead", or at least "No, you can try that later if there's time, but do it this simpler way initially"? It seems to me that Scrum is too idealistic in this respect. I know that this does happen, obviously, but to say that because of this interference "your organisation is not doing Scrum" suggests that "doing Scrum" is not desirable in such cases!

share|improve this question

closed as unclear what you're asking by MichaelT, Euphoric, gnat, Eric King, gbjbaanb Jan 6 '14 at 14:34


Have you got a good system in place for prioritising software tasks. You could just add in "Period code review/maintenance" and ensure it gets more priority. –  Jamie Clayton Jan 5 '14 at 14:51
What exactly is your question? I see you listing many (anti-Scrum) Straw-men but I don't get the point you're trying to make. Are you asking people to pull the straw men apart? Most of those situations you describe sound like a bad idea regardless of method you use. –  Dave Hillier Jan 5 '14 at 15:54
@RobinGreen Are you saying some development process exists that can succeed with teams of people like you described? Any kind of development methodology will fail if you only employ people who have no motivation to properly do their job. –  Euphoric Jan 5 '14 at 16:08
@Euphoric I'm positing that they have no motivation to do their job properly unless a traditional command-and-control hierarchy tells them to do so. I think I'm right in saying there exists projects that have been delivered successfully without using Agile... –  Robin Green Jan 5 '14 at 16:17
I still don't understand what the actual question is. I disagree that using a command-and-control will actually work in those scenarios. I've never seen anyone else assert that you will actually be effective in those scenarios with that style of management. –  Dave Hillier Jan 5 '14 at 16:43

7 Answers 7

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!

share|improve this answer
I have rarely if ever seen mention of "hardening sprints" before. Thanks for that idea! –  Robin Green Jan 5 '14 at 12:30
+1 for sometimes it's true. It's horrible to be on a project with iterative requirements but a waterfall deadline. –  Amy Blankenship Jan 5 '14 at 22:53

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.

share|improve this answer
Note that I've had multiple good experiences with contractors in Scrum. –  Sklivvz Jan 5 '14 at 22:24
@Sklivvz - As have I--one of the best projects I've worked on in recent years was manned almost entirely by contractors. It was a little rough when they left, not because they did anything particular badly but because it's always hard watching all that knowledge walk out the door. The key was that expectations were clearly laid out and the contractors were very very good and took pride in delivering a high-quality product. –  Matthew Flynn Jan 6 '14 at 2:21

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).

share|improve this answer

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.

share|improve this answer
+1 for > 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. –  Euphoric Jan 6 '14 at 7:35

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).

share|improve this answer
I've had similar problems to the OP in the past, and I've actually got Simon to come and speak to the team+management. Results? Total disinterest. –  Sklivvz Jan 5 '14 at 22:26

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 ;)
share|improve this answer
In your experience, how well are the project sponsor's and staff interacting with the scrum processes? Is it breaking down barriers? –  Jamie Clayton Jan 5 '14 at 14:56
@JamieClayton It was more of a general question, not about any particular project per se. Obviously I hoped to get useful insights out of asking it but I wanted to ask quite a broad question about the tension between Scrum and the organisation's need to control things. –  Robin Green Jan 5 '14 at 15:00

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.

share|improve this answer
