Show all posts
8 years ago

Going Agile From Within

"You can't apply Scrum without an external expert"
"You can't apply Scrum without a Certified Scrum Master"
"You can't apply Scrum without XYZ"

You can replace Scrum with any other buzzword. Is it really necessary to have an agile coach on board to join agile camp? Is it really required to send someone to CSM courses and delegate Scrum adoption to this brave knight in a shiny armor? I believe it is not the only way to go, and there are 2 reasons that support my vision:

  1. I did not attend any courses, conferences and other events, but I did learn agile and became an agile expert.
  2. We implemented agile process in our company without any external help.

To me it looked (and still looks) natural to improve development process internally. It was an ad-hoc agile adoption  in our company. There was no defined structure, but on-going learning. People have been reading books about agile development which I recommended. I've been making some presentations about agile history, main processes and so on. People have been reading articles and discussing new ideas. It worked out, finally. Even with such an unstructured approach you are able to set up an agile company. But are there better ways?

Agile Coaches

What's wrong with external coach/trainer/consultant? Nothing, actually. You pay someone to teach you. You pay someone to inject agile culture into your company. You pay someone to get it faster.


The problem is that this process is so slooow. It is inevitably slow, because all the mindset changes are slow, and you can't speed them up greatly. My estimate is about 1 year as a minimum (no proof, sorry, just personal experience). You can't absorb all the agile spirit in a shorter period of time (maybe some geniuses can, but they don't need coaches anyway). I do believe that a good agile coach can speed up agile adoption, but not as greatly as often advertised.

OK, so changes are slow. It is absolutely required to manage the change over a long period of time. You can't setup something, run it for a couple of iterations and leave. There is a high chance that development team will degrade and slip back to old-and-oh-so-known practices quite fast. It leads to several possible conclusions:

  1. If you hire agile coach, it is better to have about 1 year contract.
  2. If you hire agile coach for just 3-6 months, setup internal learning/change process as fast as possible.

The main idea of agile adoption is a paradigm shift. People should change their habits, rituals, working patterns and activities. It is SO hard! Some people just can't accept it and leave the company. The goal of agile adoption is to change mindset of as many people as possible and let rock-hard minority go.

So why I personally don't like the idea to hire someone who will teach us agile? It immediately puts our intelligence to question. Are we really not able to learn ourselves? Can't we read some books, discuss them and try, for example, Scrum in a single dev. team? If we want to hire someone, to me it looks like we've already given up and can't do anything cool without external help. It looks like we got exhausted and now need a power recharge. It is similar to an external CEO hired in a desperate attempt to save company.

Don't get me wrong. Agile coach can help greatly. But I don't buy the paramount idea that development team can't go agile without external help.

Problems and Solutions

I like challenges and like to solve problems without external help. What I like is a full team involvement and participation. It is so cool when people discuss problems and generate solutions. If I ever hire an external consultant, it will be a person who will teach how to solve problems. Problem solving is the MOST IMPORTANT skill (can I stress it more?) for any good developer/tester/designer/you-name-it.

Here I see a major flaw of Scrum as a methodology (so far?). It does provide a framework, but it says nothing about problem solving. OK, you should have a retrospective meeting every other week. You should identify problems, generate ideas and write action items. You should execute action items and retrospect in 2 weeks. Sounds good. But HOW to identify problems? HOW to generate ideas? Scrum says nothing about that, but I believe this should be the core of any agile process.

That is why I pay more and more attention to lean and other problem solving techniques like 5 Whys, TRIZ, etc.

Knowledge From Within

There are various ways to ignite the team and solve problems internally, but you can't solve problems effectively without knowledge. Study Groups could be the most promising way to educate people. To be honest, we did not try it. As I mentioned, we did not have any structural approach so far, but intuitively came to something similar to Study Groups.

Study Group is a small group of people (4-6) that have cadence sessions e.g. weekly. There's no distinct leader, they rotate with every session. People should be really interested in the domain. For example, if you have Study Group to learn TDD, all the members of the group should be passionate about TDD learning and actively participate in discussions.

Why I think Study Group should work? First, there's no Boss inside. People can freely discuss various problems without pretending that they know everything. Second, there is a clear focus. You should not form a group with a goal to solve all the development problems, instead it is better to form groups to study UX, study TDD, study Scrum, study Lean. Once again, Study Group is not a problem solving technique, but it helps to educate people. And it is absolutely clear that educated people will generate better solutions faster.

Here is the nice summary about Study Group. And here is the list of other learning methods that every agile team should pay attention to.

  • adronbh

    Yeah, saying you can&#39t have Agile without X thing/staff/etc is kind of crap. The whole coach concept and all that is a bunch of corporate mumbo jumbo as far as I&#39m concerned. When in doubt I always look back at the manifesto and think how something does or does not fit into those ideals.

    Great write up, enjoyed the read.

  • Michael Dubakov

    BTW, if people ask me whether they should have APM tool to start with agile, I always say no. It is just so wrong to start with a tool. There should be a REAL need to use more complex tool than whiteboard and sticky notes.

  • Pawel Brodzinski

    While I share your approach – I pretty much prefer to figure it out by myself along with the team – I think there are valid arguments to hire outsider too and not only to make a process faster. People tend to treat outsider differently than insider even if the latter delivers more reasonable message.

    I liked Scott Berkun&#39s article on the subject a very good and well-weighted:

  • Michael Dubakov

    These are arguments for hire a speaker. Trainer is not the same, since listening is not the best way to learn

    I agree that great trainer can help greatly and great speaker can change your vision. But it is so hard to find it! If we take Agile CE conf. How many *really* great speakers were there? To be honest, zero. On latest Agile conf. in Chicago there was 1 great speaker for sure, Jarred Spool who indeed changed my mind about importance of UX. But 60% of sessions I attended in 4 days at Agile2009 were quite boring and without something significantly new to me.

    “Hire great trainer” may sound as a good advice. But they are expensive and rare. Should you hire someone just good? Maybe. It depends.

  • Pawel Brodzinski

    Yes, these are arguments for hiring a speaker, not a coach/trainer but the former is more general, that&#39s why I find them valid.

    I look at speakers and/or coaches more like on a fresh blood in organism than like on the best of breed folks who are full of ground-breaking ideas. So I don&#39t expect every presenter to be one of top 100 speakers in the world. I don&#39t expect every presentation would teach me something new.

    As I wrote in my AgileCE summary – I believe if you&#39re a heavy practitioner of something you will likely learn barely few new things from other folks talking about the same subject. For me this is pretty much expected.

    I&#39d go even further – I&#39m naturally skeptical for thought-leaders even though these people usually set up frameworks we follow, i.e. I don&#39t believe David Anderson has answer for every specific Kanban-related question. And this is a part of this DYI approach – we know our problems better and as far as we&#39re open and willing to learn we&#39re likely to find better solution even than top-notch outsider consultant.

    Having said that I don&#39t think that listening to any other but best of breed speakers or having an outsider to discuss your process is a waste of time. Even when someone is an average speaker, and speaker&#39s fluency in English affects our judgement hard, it doesn&#39t mean she has nothing valuable to share. It&#39s just harder for audience to catch these important messages.

    The same is with coach. The better coach the easier it is to catch important lessons. Personally I wouldn&#39t hire average coach, but for me events like AgileCE works in a similar way like coaching. I had a lot of discussions with other practitioners, where I we were going through our organizations sharing ideas, asking questions, evaluating answers etc. For example the way Paul Klipp&#39s team uses Kanban seems to be pretty different than the way we use it. And even though I don&#39t plan to copy Paul&#39s way I have a trick or two I consider as useful.

    Even more, I learned quite a few things from people I completely don&#39t agree with. AgileCE was for a me one big coaching session, even though I wouldn&#39t hire almost anyone (in anyone at all) from there as a coach.

  • Michael Dubakov

    Good arguments. But it seems we switched to conf. usefulness discussion 🙂 I do agree with your points and I believe the conf. was valuable for many people. But I just expressed my personal feeling and perception, no more, no less.

    Moreover, I don&#39t like when everybody says “oh, that is so great conf.! So many new ideas and so many cool sessions! Can&#39t be better!” In such cases I want to show some areas to improve. Nothing is perfect 🙂

    Also I think workshops are much better as a learning technique than a pure listening session. What I discovered during various conf, is that it is quite hard to organize and structure really interesting and useful workshop. But still I believe any conf. should have more workshops and less talks.

    Here is the example
    2 days full of workshops and 1 day of talks. It gonna be great experience I believe.

  • Wildfalcon

    Thanks for the interesting post Michael 🙂

    I agree that it is not necessary to have an external coach, or trainer. My own experience backs this up in that I starting being self taught, and then after I was working in an agile way met coaches and experts.

    Had I not had that exposure, I would still be doing agile development. But I would not be doing it as well. And this is where I feel a coach/trainer makes the biggest difference, in the change from doing something acceptably, to doing it brilliantly.

    A (good) coach has the experience and knowledge to see things differently, and to suggest new ideas that I would not have come up with as quickly from my own learning.

    I think there is also space for initial training, as a knowledge transfer. Many teams do not have enough knowledge of agile to accurately try it, and training is a more efficient way of getting a team to a common initial understanding than books.

  • Joshua Milane

    Sounds like you are looking for a “solution in a box” but Scrum is not one. Everything needs to live within an environment, right?

    “But HOW to identify problems? HOW to generate ideas?” – the same way you would without the S word… or PMI… or RUP… with your people. This is where you have to revert back to Agile instead of Scrum if it is not obvious to you, no?



  • Michael Dubakov

    You are right, no framework has this embedded. And I see this as a weakness that most likely will be improved really soon.

    >>This is where you have to revert back to Agile instead of Scrum if it is not obvious to you, no?

    What do you mean? Agile is quite a broad term. What exact practices you may recommend to identify problems?

  • Michael Dubakov

    Definitely I agree that dev. team should not live in isolation. Coaches just one way to have fresh flow from the outer world.

    Again, my post was not against trainers, but against the vision that it is not possible to change without them. I do agree with your arguments, they are all valid 🙂

  • Robert Dempsey

    Interesting post here, though I must say that you all are crazy and should hire me to help you implement Agile!

    Just kidding. No seriously, I AM kidding. Let me put on my serious face.

    I too am in the camp of “just freaking do it yourself.” Frankly I think anyone can read about Scrum, XP, Kanban, whatever, and see what works within their context. I did that with my company 3 years ago, and I see many teams doing it.

    I think that most companies that hire coaches though are not software shops, and their main business is not building software applications (as is the case with you and I Michael). We&#39re talking about companies, typically larger, that somehow ended up with a team of developers (typically in the IT department), and have no idea how to handle them. Now let me tell you how I really feel… In my experience these same companies also have a culture that does not support Agile principles.

    So the only way for change to be initiated is if some “expert” comes in and helps them to see why they need that change. Does that happen overnight? Hell no, though managers still try to make it so. Do they need the attitude of wanting change in the first place? Yes, especially upper management.

    So can a team implement Agile themselves? Absolutely. Do some teams need a coach to help them implement Agile because of the corporate culture in which they are? Absolutely. Is there one golden rule that can be applied with any of this? Absolutely not.

    Now that problem solving thing you mention – that would be great if they taught that in schools rather than just how to write code.

  • Michael Dubakov

    I must say it is a very nice summary of the discussion 🙂

  • Alexandru Bolboaca

    I think our article “Questions About Agile that We&#39d Like to Answer” is on the same note.

  • Ilja Preuß

    There is a broad range of practices out there for identifying opportunities for improvement (not just problems!), generating ideas for improvement, and implementing them. For Scrum to single in on just some of them would be as misguided as promoting specific engineering practices (which, depending on your perspective, might in fact not be *very* misguided).

    If you asked me, I&#39d recommend starting by taking a second look at retrospectives. There is a whole community with its own body of knowledge out there on how to facilitate retrospectives. The book “Agile Retrospectives” would be a good start, as would joining the retrospectives Yahoo group.

    Other approaches you might want to look at besides lean include Appreciative Inquiry and Solution Focused Coaching, to just name two that come to mind immediately.

    Hope this helps…

  • YvesHanoulle

    I agree you don&#39t need a coach to make changes.
    I am working as an agile coach, and I want to get as quick as possible. That is: help a team to find it&#39s own voice and be sure they think on their own.
    At the same time I think everyone (person/team/company) can use a coach to go faster to a higher level. I read an afwull lot of books and implement a lot of what I read, and still I advance much faster when I talk regurly with my (personal) coaches.

    I agree with Ilja a team that does retrospectives will come up with everything in the agile world and much more… To help to do this I would advice have every team members facilitated the retrospectives at one time.

Try for free

Account url: *
How many people would be using Targetprocess?
  • Myself
  • 2–20
  • 21–100
  • 101–1000
  • 1000+
By clicking Continue you agree to our Terms of service and Privacy policy