More on the Dedicated Agile Champion role

In 2011 I wrote a blog post about the Dedicated Agile Champion.  This title is a pattern in Manns/Rising’s book: Fearless Change.

Bob Lieberman sent in a comment that I should discuss this more.  That the job can be complex in larger organizations.

And I completely agree.  In fact, I discussed that complexity in the initial post, but in very general terms.  For example, impediments to me can be very complex and can include many many types of things.

There are many many cases of agile adoption.  One must be modest and say that one has not met every case — far from it.  So, while my comments are based on much experience, still use it as advice in your case with caution.  Your situation might be different than I was imagining at the time.

Bob wants to consider the case of a firm with 10-20 Scrum teams.  And the Champion must deal with all the departments that these teams have to work with….all the non-agile areas of the firm.  These areas (in his case) cannot be ignored because they are critical to delivering successfully.

This seems like a very realistic scenario to me.

So, one point he made is that, in that case, a Champion cannot be very close to the Teams because the Champion must spend so much time with these other groups, and getting them to work with the Teams.

Fair point.

One minor point: does it have to be that the Agile Champion must fix this “impediment”?  (That the other areas help the Teams sufficiently well and on a timely basis.)  Not always, but it might be a key thing for him or her to help with.

More important issue: so, what did I really mean about being close to the Team(s)?

The key issue is that the Champion and many others must see the Champion as being effect.  As driving success.  Much of the real success of Scrum lies with the Teams.  So, to me, if the Champion is helping the Teams be successful (and they are otherwise being successful and becoming more successful), then whatever the Champion does that helps the Teams is a kind of “being close to the Team”.

What we were cautioning against is “working in the sky” on an idea (agile), and no one can see a direct connection between your work and any real improvement, any concrete improvement.

And it is indeed one of the great problems of working with knowledge workers, that they tend to fall in love with ideas and then real results do not happen. Or at least few people can see the connection between the work with ideas and the talking and then the real results.

***

Another key issue is recognize that every Agile Champion’s job is different.

Some areas of difference:

• the size of the firm
• the nature of the products (is agile being used for the main products, or is agile only supporting indirectly the firm’s main products)
• the number of teams
• the number of large departments with agile
• the level of policy and process ‘things’ embedded in ‘the way things work around here’ that do NOT support agile
• the degree to which the culture of the firm naturally supports agile
• the number and degree of ‘technical impediments’…one example: the level of automated testing
• the level of understanding and support for agile in middle and upper management

And there are more.

The point is, that because of these differences, the Champion’s job can vary to a very large degree.  And indeed, in some firms you need to have multiple Agile Champions I think, each covering a somewhat designated area.

To tease for a later blog post:  in some larger firms, should the Champion have any support? Or any other people working with him or her?

More later.

 

 

« « Change the World – Make your bed || A different kind of Scaling problem » »