How to implement SCRUM without forgeting the four principles of the agile manifesto on the way?

Question

Don't the four agile principles get a bit lost in the middle of all the SCRUM process? How can this be avoided? How to promote these four principles over the process that is imposed? How to make the technical staff aquire a more value-oriented mindset and act in more assertive manners instead of turning them into drones?

Answer 1

When it comes to Scrum implementation it pretty much depends who you listen to. If you go with Ken Schwaber's, rather conservative, approach you'd hear that Scrum is actually the solution and you shouldn't change it much.

However you may also find opinions that Scrumbuts (we do Scrum, but...) are the best flavors of Scrum.

The latter kind of answers your question - it's not about applying specific method blindly. Do what works for you and if it doesn't just stop. That's not what you're going to hear from everyone but, well, if you look for kind of common sense answer you won't need to look for it very long either.

There are many people who don't treat agile in general and Scrum specifically as sacred cows. For them, well, me included, it's just one of tools I may use - either as a whole or only partially. So it's not processes and tools over people.

I would also point that as long as you're going to choose your own way understanding how the work is done and how a team works is crucial. Otherwise you will be throwing out parts of this or that method without understanding why they were implemented in the first place, i.e. what the team was supposed to get thanks to them, thus what you should address with different bits and pieces.

Pretty often lack of understanding the work is a reason why selective approach to any method fails.

Answer 2

Since you can't implement principles, you are left implementing practices - aka Tools, techniques and methods by Peter Senge in the Fifth Discipline Fieldbook. Peter makes the case for two other things that hold your "domain of action" together:

1. Guiding Ideas
2. Innovations in Infrastructure (both social and technical)

To keep from missing the principles, don't forget to lock in the social and technical infrastructure necessary to cement those guiding ideas.

I think that is best done by implementing vanilla scrum first - See my answer in Strict or Pragmatic Scrum?

Answer 3

Agile principles alone will not get your software delivered.

If you think Scrum is the right method for your shop, then make it so. That is hard work enough in its own right. You can worry about specific principles once the results are there, and only so if it wil clearly bring an improvement.

Answer 4

In a way, yes. The principles get lost, as team members, and especially Scrum Masters, focus more on "doing the planning meeting right", "sticking the post-its on the board at the right column" and so on. But this is not a problem with Scrum itself. The problem is that some people don't even care about the principles, in the first place. This is particularly true on companies used to heavy processes. When Scrum is adopted, they tend to see it as yet another process, with its own rules, rituals and procedures, not attending to the rationale behind them.

The very idea of "welcoming change", one of the cornerstones of the agile philosophy, faces a great deal of resistance. So, for example, if someone proposes that stand-up meetings should not be done in a certain project (for whatever good reason) some people will object: "but this is against the rules of the process!" The right way to deal with an agile method like Scrum is to treat it as a set of general guidelines and use your best judgment for the particular circumstances of your projects.

Answer 5

Of the twelve agile principles, there is one that I have found most helpful to bringing an agile mindset to the team.

I have had the most success with looking for opportunities to point out instances when the team has self-organized to solve a problem. After doing this a few times, team members begin to believe in their ability to self organize, and come to expect that the other side of the statement; that the best architectures, requirements and designs will emerge. In other words, recognizing success in this area has the effect of motivating the team and can be a stepping stone for bringing trust to your process.

Answer 6

Any time you have the team members who are done early, be sure to focus them on the right hand side of the manifesto:

• processes and tools
• comprehensive documentation
• contract negotiation
• following a plan

Since starting the transition from waterfall, I've seen these things be forgotten rather than de-emphasized, but they are critical to the integrity of the team.

And remember that the value is in the team:

Cost is just a function of talent (or lack thereof). I would be surprised if you are really able to get a lot of direct savings - more than 30% or so compared to USA - for teams in Slovenia or Croatia, but you might have expertise, a gelled team, or cultural knowledge that is hard to replicate elsewhere.

References

• Manifesto for Agile Software Development
• Outsourcing vs Offshoring – AVC
• Agile Workshop