5

Much has been told about the advantages of agile development and Scrum in particular, however, most of these assessments assume that an organisation comes from a very rigid methodology of Waterfall. But what if a company is organised less strictly than advised by Scrum, not more?

The organisation I work for is a former startup. The team is used to tackling any issues or requirements as they come. The organisation does make a half-hearted attempt at implementing Scrum but the general attitude is rather negative, with many people seeing Scrum only as corporate red tape. What benefits will we get from applying more discipline?

  • On the dev side, the team is reluctant to sacrifice coding time for planning sessions. Especially if the whole team was supposed to attend: so far any planning or estimation was done by a team leader alone (unless they actively seeked assistance from some of their devs).

  • The business, on the other hand, is not used to having to provide detailed requirements for whole two weeks up front. So far they only provided a general sketch of the things they needed most at the time and fleshed it out on the go. Now, if there are gaps in the requirements at the start of the sprint, the team should in theory tell them that the item is not 'ready' and the new feature will not be worked on for the next two weeks, meaning it will be deployed in a month at the earliest. How would you make the business accept this loss of flexibility?

How do you sell agile development to a company that is already agile to the point of chaos?

  • 2
    The "tackle things as they come" is called Kanban. And some people say that Kanban is superior to Scrum. As Scrum exists between "standard" management and ideal Kanban-like development. – Euphoric Feb 4 '17 at 20:11
  • 1
    @Euphoric: I don't think that's a fair description of kanban. Like scrum, kanban relies on stories or tasks that exist on a backlog. – Bryan Oakley Feb 4 '17 at 20:29
  • 4
    If you have a pretty decent team of good professionals, you can forget about all the trash and just let them solve problems. I'm convinced that it'll work. There is an interesting podcast about this in Software Engineering Daily called Developer Anarchy – edalorzo Feb 4 '17 at 23:34
  • 3
    You sell scrum by understanding both scrum and their current processes enough that you know how it could help and when it wouldn't. All I see here is complaints that they aren't doing it faithfully. Scrum isn't a religion. Give people a reason to care. "It's chaos!" isn't a reason to do it. "Already agile" isn't a reason not to. – candied_orange Feb 5 '17 at 1:18
  • 1
    You'd best be damned well sure that it's broke before you try to fix it. What problem are you trying to solve? Do you want to do Scrum because it's "Agile" and what you're used to, or because it's going to actually bring some tangible benefit?? It's been mentioned a few times, but it bears repeating here: Lots of teams are fighting hard to get to where your team already is. Don't muck it up. – RubberDuck Feb 5 '17 at 15:56
12

If your teams are producing code of appropriate quality at a rate acceptable by management, there is nothing to be gained by using scrum. In a sense, scrum is a framework to guide a team to reach this exact state.

However, if your code is of low quality, or if the code you develop doesn't always meet the needs of the end user, or if management is unhappy with the lack of transparency into the development process and finds planning around development schedules difficult, scrum may help.

Scrum is about embracing change by helping teams focus on efforts that deliver real value to the end customer in a predictable manner. By introducing a short feedback cycle, teams can be sure they are providing exactly what the customer needs. In addition, management has more visibility into what the team is doing now, what they are planning to do over the next few weeks, and when features will be ready.

And finally, scrum provides a framework for teams to become better at writing software through continuous improvement.

The end result of a team using scrum is a team that can predictably deliver high quality code that meets the needs of the user. If your team is already doing that, there's no point in changing what you are doing.

  • 1
    Great answer! Just to add to it, if an organization leadership is asking you to move to Scrum, the real question you need to ask is 'why now'? Usually the leadership is missing something they need, and Scrum may or may not be the answer. What is it they need that you don't have right now? That will help you revise your process. – Jay S Feb 6 '17 at 13:09
  • Scrum is not a methodology but a framework scrumguides.org/scrum-guide.html – Artem Malchenko Jan 23 at 16:58
  • 1
    @ArtemMalchenko: thanks for the comment. I've updated my answer to use "framework" rather than "methodology". – Bryan Oakley Jan 23 at 17:46
  • This answer mirrors my experience with Agile in a medium sized team environment. The danger is that management (aka the project Owner) will sometimes feel entitled to "pivot" constantly to the detriment of the long-term design/vision of the product because of all these short-term deliverables. – Patrick Hughes Jan 23 at 19:37
8

One sort of counter-intuitive benefit to scrum is it forces you to prioritize your backlog, be really aware of your actual capacity, and limit your work in progress. What we found when we started doing scrum was we thought we were being really responsive by tackling things as they came, but really each new thing we took on just spread ourselves more thin and delayed everything.

In other words, instead of finishing the 3 highest-priority tasks in 2 weeks, then the next 3 highest-priority tasks in the subsequent 2 weeks, we would agree to all 6 at once, but it would take a month to complete any of them, because we were spread thinner. Focusing resources on fewer tasks delivers value more quickly.

Also, you shouldn't try to do scrum precisely like the cookie cutter mold. You can do 1-week iterations. You can delegate most of planning and estimation to one person. Create your own criteria for when a story is ready to start. Hold regular retrospectives and adjust it to fit your needs. Individuals and interactions over processes and tools.

1

You have some good responses here with which I don't have any real differences.

I did key into something you said about your current situation being "agile already to the point of chaos". Agile is NOT chaos. I have run into many people who claim to be agile because they are just super flexible and don't have any heavy process, and they think they are efficient...

I have worked in entrepreneurial companies that didn't have a formal framework and they thought they were agile, but you are right, at times they are just chaotic. Karl Bielefeldt's response is absolutely correct. There are numerous benefits to adopting an agile framework and the continuous improvement disciplines that go with it. Scrum is just one method.

This approach may be great in the early stages of a start up. But the lack of discipline can impede the company's growth over time.

BTW, Kanban is NOT less disciplined than Scrum, it is actually more so, when done correctly. You may need an agile coach to look at your processes and business and help you tailor something that keeps it light but gives you some of the benefits. Maybe Scrum would be right for you, maybe it's kanban, or XP, or a blend. No one can tell you without taking some time to get to know your company, your product, your development culture, etc.

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.