Agile (Scrum) adoption - how did it go? [closed]

Question

Closed. This question is opinion-based. It is not currently accepting answers.

---

Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.

Closed 2 years ago.

For those of you who have implemented Scrum in your organizations, what were your biggest obstacles and if you did overcome them, how?

Answer 1

We do mostly scrum projects at the customer site. Hardest part in my experience is finding a good product owner in the customer organization:

• Too many people think they should be the product owner,
• The product owner has a hard time following the pace of the team
• Product owner has a hard time getting all the detailed information the team needs
• Moving items down the product backlog to add something with a higher priority is difficult
• etc.

Training internal teams to use scrums is doable, bringing in your own scrum master is doable, but a good product owner should be part of the client organization. It's harder to train this external person. Having a proxy product owner, who works together with the customer product owner does help a lot.

Answer 2

Where I work has been using Scrum for a while now but it seems to have gone through a few phases. In terms of obstacles, one part is to prevent putting in too much change at once and just introduce things slowly,e.g. put in a daily standup one week, a couple weeks later put in a story board, a couple weeks later bring in pair programming. This allows for the various tweaks that will happen to work and if the changes improve things then this can help build up some good momentum. Another point is to make sure that if there should be changes in how something is done that the person being corrected isn't belittled or mocked. At times this may mean that you interrupt someone or that you bring in a "Can we get back to basics?" or something similar to try to put things back on track rather than just yelling at someone or doing something else that is counterproductive.

Bringing in consultants was one of the best things done around here, IMO. Now, these guys came in to help evolve how development was done here. Bringing in pair programming, TDD, concepts like broken windows, organizing project folders, and bringing in mocking for tests, were all excellent additions that while we may have gotten there on our own, it may have taken a long time which wouldn't work out so well.

Answer 3

Background: In 2006 I contracted with a large company which had adopted Scrum cold turkey just months before I arrived. The company hoped Agile/Scrum would save their huge enterprise software product. Of the hundred or more programmers there, I worked closely with a team of about a dozen for a year, observing and participating in their Agile experiment.

Summary: I believe Agile helped more than it hurt. By the end of the year, the team could consistently estimate and produce features, whereas previously their productivity was rather erratic.

Implementation: Since this was a large organization and a large product, the project ran as a "scrum of scrums." There was one scrum master for about every 15-20 developers and these teams were often divided into smaller, closely working scrums of about 6-8 people for an iteration. Teams were largely independent, could adjust their own iteration frequency (1 month down to 1 week) and were given lots of flexibility to implement agile as they saw best. The company regularly brought in Agile coaches (such as Object Mentor) to help train the scrum masters, teams, and management.

Obstacles: Plenty. Some of them related to Agile, some not. In no particular order, here are some lessons learned:

The product backlog was revised way too often in the beginning. Eventually, the team and management took several days to go over all the features, estimate them, and prioritize them. It was a big hit, but it helped tremendously. Lesson learned: get your product backlog in order early and keep it maintained. Product owners must have a clear idea of what they want.

We lost time experimenting and dealing with fads and hype. When you start, you have no way of knowing if you're doing things correctly. There's temptation to constantly fiddle with the agile process taking the focus away from the product. Lesson learned: having an experienced Agile coach does help reduce this learning curve. There should always be someone pushing back on any experimentation. Limit the number of "spikes".

A good scrum master is invaluable. Certainly in the beginning, it's a full-time position.

It takes time. It took several months before the team started to be comfortable with the process.

Pick your battles. Some programmers will be understandably skeptical and others will outright dislike and flight the change. Allow for some flexibility. For example, enforce the use of a product backlog and iteration schedule, but don't require everyone use note cards. Be particularly sensitive to introducing tools and programming methodologies such as pair programming or test first development.

Finally, keep communication open and manage expectations.

Good luck!

Answer 4

The biggest issue, as already stated, that I too have experienced is the lack of buy in. It is very difficult to get people to truly become vested in the process.

The other issue, which is also one that directly contributes to the above issue, and also in a large part one of the founding causes of Agile is the lack of management to stick to the outlines of the manifesto of Agile.

In Scrum, Lean, or whatever version of Agile you are working with one cannot break from the manifesto points. If a process is being used to break away from those priorities then most likely the management is screwing up and the buy in will fall apart. The manifesto MUST be followed:

Manifesto:

• Individuals and interactions over processes and tools
• Working software over comprehensive documentation
• Customer collaboration over contract negotiation
• Responding to change over following a plan

Some scenarios might be when a gantt chart appears from one of the above processes for whatever reason. Gantt charts can be useful, but if all of a sudden a developer is reviewing a gantt chart with management, the last point is broken. Responding to change has slowed because encouragement of the plan is being favored over change. Instead a board with stickies should be used, simplify what is on the board with only the current working items and back burner items. This makes changes easy. Once anything is solidified in a "tool" it slows responding to changes. Sure, management needs to record and track things in some ways, but pushing that onto development only slows the responding to change, and pushing tools onto developers (unless they want them for development and can utilize them appropriately) messes up the first point, of the individuals over tools and process.

In another way, don't stop development for the purpose of writing comprehensive documentation. Unless you only have a single developer, then someone should take the documentation load autonomously from the development role. Pushing these things together drastically slows development and for periods of time, can shut down any effort to actually get working software.

The last point, is to always, ALWAYS stay in contact in some way with the customer or prospective customer. Talk to them regularly about what they want. Talk to them daily and show them as much as you can of UI, or even data flow work. Anything that they would understand they should see. Talk to them, educate them about the architecture and ideas going into the application and never forget that you are building the application for them.

Summary:

Biggest issue is buy in. Second is management sticking to the manifesto guidelines.

If you can mitigate these two risks, you should be good to go. Anything else is cakewalk after getting buy in and getting management to understand that they'll need to be truly strong, and non-micro management managers. Specifically, managers might even need to become leads, or fill a different style of role.

...hope I didn't stray off point too much. :)

Answer 5

I moved from a company that adopted Agile to the tee to another company which follows the traditional methodologies.

Perhaps the biggest difference I have seen is that the second company struggles to prioritize. There is so much work on each person's plate that they fail to deliver on time. IMO, Agile brings about some transparency to the situation and lets the team as a whole prioritize.

A scrum master in the Agile world would take care of fire-fighting and be the voice of the (sprint) team. In fact, in the first company (where we had a separate scrum master and program manager), the scrum master would fight it out with the program manager when the latter makes false promises to the management. Meaning, the scrum master knows how much a team can produce/deliver after a few sprints, which helps her nail down on the predictability of a team.

I also noticed that the R&D resources have a sense of accomplishment at the end of each cycle, and are looking forward to the next one. But then, a good project manager could get this done in traditional scenarios as well.

Answer 6

While working as a Delphi developer a few years ago, I managed to get Scrum adopted by my development team for a time.

The whole process worked very well for us - having the team estimate prioritized tasks on a backlog gave us meaningful timeframes to target, and the whole "Managements job is to remove impediments" was great.

The biggest problem was that the process was always perceived - and referred to - as "Bevan's good idea".

While the team appreciated the value we gained, and were happy to continue with Scrum, the Team didn't take the scrum methodology on board as their own. After a while, I got tired of "pushing" and we "fell out" of following the Scrum approach.

Lesson: Make sure the team takes Scrum on board and owns the approach.