Last week I gave a talk at Turku Agile Day. The premise of the talk was simple: adoption Agile in R&D only is not enough. The goal was to create simple model to guide us through Agile adoption in a company (as opposed to a team).
I came up with a model that included 3 steps and 15 lessons learnt. How have your experiences been? Have you faced similar or different issues?
Check out the slides for the adoption steps and the lessons learned in the context of each step.
Check out the slideshare page for the notes on the slides that explain a bit more of the content for each of the slides.
5 thoughts on “Agile is easy! It’s making it work with your business that is hard!”
Just gave this a read. I certainly could identify with many of the early points, especially since I was at least a member of the pilot you referred to.
Agile like any methodology before it, has always suffered from the fact that often many of those which will be likely adopters follow no process and never have followed any process, converting those individuals, whom I personally refer to as cowboys, will always be difficult. Agile provides a structure, one that is inherently lightweight, that said those practices tend to be extremely important, educating those members who followed no process might well prove difficult. IMHO, Agile simply will not work if you try to build a chair(project team) without the necessary legs. Initially scrum masters need to envisage themselves as coaches, you need a committed product owner, if they don’t turn up to demos…likely hood is you’re already in trouble. If you have a good scrum master, product owner, you can assemble a good team and Agile will work. Quite quickly you’ll see people over processes.
Ultimately I think if anyone wants Agile to succeed in their organization, they first need to focus on the project and get that right. Moving from Project -> Program -> Portfolio might take a number of years and like anything it might be a question of timing. Whilst often people envisage continuous integration as merely TDD and Continuous Build. Achieving continuous deployment and educating the benefits of why you’d want to do that, might take substantial organization change.
If your first project succeeds, chances are, you’ve just begun your first step on you Agile Transformation journey.
Thank you for the interesting presentation. I especially like the cheat sheet! and the reminder to focus on optimizing the system.
You mention that in some cases Agile actually adds “structure” to what could have been a previously “chaotic” set of cowboy coders.
How about this thought, as you take agile outside the pilot projects, then to R&D and later to portfolio management you are adding the same type of structure to what used to be “cowboy managers” 🙂
Maybe I’m just crazy, but that’s how I see it… I think there’s a blog post here… need to develop this thought.
Did you also experience some of these “lessons” I describe? Care to share those?
@Vasco Indeed, often when Agile fails(scrum being the most common variant), those who come from the purely management track have never ever been following any process. Often they’re worked within a meritocracy and if you persist long enough, rewards come your way.
Agile often uncovers adhoc “cowboy” managers. They’re often the ones that are assigned key roles in the Scrum process. Be it retooled System Analysts(Product Owner) or Project Managers(Scrum Master), that said often these folks adapt quite well. It’s their superiors that often fail.
I had a word with one of our management folks yesterday about this. His viewpoint was that for sure, there are cowboy managers, but there are cowboys in many different professions. He felt that any failing he’s had with scrum adoption amongst teams such as sales, has been to do with the tool use rather than the concept. As I said before you need an essence of team a common mission objective, common iteration objective, scrum roles. Sometimes a Kanban model which is really all about representation not a dramatic shift.
Comments are closed.