Re: [scrumdevelopment] Experience requirements for Scrum (team)(was: Re: Scrum Guide interpretation)
I don't disagree with George at all, but the one thing I was saying that subsequent responses don't seem to reflect is that it is more about how you adapt than when. I am not sure that it is every too early to improve, but I think it might be dangerous to do it without expert guidance (particularly at scale.) I'm not even convinced that it is a good idea to adopt Scrum "by the book" without appropriate coaching.On May 2, 2011 12:23 PM, "Andrew Pham" <andrewpham74@...> wrote:
> On Sun, May 1, 2011 at 10:29 PM, George Dinwiddie
>> On 5/1/11 10:49 PM, Adam Sroka wrote:
>> > On Sun, May 1, 2011 at 4:05 PM, strazhce<infobox.oleg@...> wrote:
>> >> --- In firstname.lastname@example.org, Adam Sroka<adam.sroka@...>
>> >> As I understand, you are talking about how to introduce a team to a
>> >> Scrum and guide it during its application.
>> >> I would like to know (and I purposefully don't ask more specifically):
>> >> How what you said relates to the notion "XP/Agile is for experienced
>> >> This question IMO relates to shu-ha-ri, people and organization
>> maturity. My feeling is
>> >> - Ron says - start with any team/customer as if it is at Shu level and
>> let them walk in their own pace
>> >> - Adam says - push the team/customer (hard?) to go for Ha or even Ri
>> level behavior
>> > I like the Shuhari model, but it is a bit limited. Specifically, I
>> > think that in a domain as complex as software development it is likely
>> > that we are doing some things at one level and other things at another
>> > level all the time.
>> > The folks I find myself coaching are typically doing Scrum at a Shu
>> > level, but it is likely that they have been developing software for a
>> > while and have skills at a higher level. These software development
>> > skills are still useful, but they may need to adjust the way they
>> > apply them. That sometimes seems to be the hardest part.
>> > I struggled for a while to figure out how to help my clients apply
>> > their existing software skills in a responsible way while doing Scrum
>> > and at the same time learn some new skills that the faster pace and
>> > less certain plan require. The problem is figuring out where to start
>> > and how to measure progress.
>> > The way that I have solved that problem is to apply Systems Thinking.
>> > However, if I apply Systems Thinking honestly it is not always the
>> > things inside or around the edges of the framework that are the most
>> > prudent things to change. Sometimes the framework doesn't really fit.
>> > If the framework is the impediment then I have no problem adjusting
>> > it, and it seems to me that is just as true whether I feel my client
>> > has mastered the framework or not.
>> > So, I am not really talking about Shuhari per se. I am talking about
>> > working with the right coaches who understand the implications of
>> > Agile at the management level, at the organizational level, and at the
>> > sausage making (crafting working software) level. Those kind of
>> > coaches don't always stick to the framework, because the framework
>> > doesn't always make sense for *your* situation. What is important to
>> > me is that you get the benefits that Agile promises, and Scrum alone
>> > is not always the best way to achieve that regardless of the skill
>> > level of the team.
>> > Now, all of that said I agree with Ron to the extent that if you are
>> > going to apply Scrum you should understand it well, including how and
>> > why it is put together. The best way that I know to understand Scrum
>> > is to practice doing it, and doing it as it was designed to be done.
>> > The same goes for XP or any other tool/framework/practice/process.
>> > Once we are educated and practiced we can better understand how to
>> > apply them and we can make appropriate decisions about when to do so
>> > or when not to. I suppose *that* is about Shuhari.
>> I'd like to second these notions, but add the thought that what Adam
>> does, and what I do, is to help a client tailor things to their current
>> situation /from the perspective of an experienced coach/.
>> This is a very different thing/ from an organization new to Scrum or Agile
>> deciding to tailor things before they've ever tried to do things in a
>> genuinely Agile fashion.
> I completely agreed with George's statement statement and can also confirmed
> from the trenches how things usually went astray when organizations hurried
> to tailor Agile even before they have tried to do things in a genuinely
> Agile fashion and learned from there.
> Andrew Pham
> Agile and Lean Coach, Author of *Scrum in Action*
>> - George
>> * George Dinwiddie * http://blog.gdinwiddie.com
>> Software Development http://www.idiacomputing.com
>> Consultant and Coach http://www.agilemaryland.org
- Hi, Adam,
--- In email@example.com, Adam Sroka <adam.sroka@...> wrote:
> In my opinion it is not the responsibility of the coach to do these things
> per se. Rather, an experienced coach can help guide an organization to do
> these things successfully based on his experience.
> You don't hire sherpas to climb the mountain for you. You hire them for
> their knowledge of the terrain and its various perils so that *you* can
> climb the mountain in relative safety. A coach is a very similar thing.
> Also similarly, the ultimate success or failure of the expedition is not the
> sole responsibility of the sherpa, but most experienced climbers recognize
> that it is irresponsible to proceed without his assistance.
> On May 3, 2011 5:30 AM, "strazhce" <infobox.oleg@...> wrote:
So if I start using Scrum/Agile/whatever without coach, I undertake a risk of doing it wrong. If I hire a coach/mentor, I pay for avoiding most common mistakes other people made and speeding up my change, for opening my eyes to see things I wouldn't come across otherwise. It seems similar to taking or not taking personal/career coach.
Ok, I've thought about some implications (http://www.agileskillsproject.com/collected-knowledge/ideas-to-refine/hiring-agile-coach). My main concern is trusting the coach, but it is a different topic.