Re: [scrumdevelopment] Experience requirements for Scrum (team)(was: Re: Scrum Guide interpretation)
- On Sun, May 1, 2011 at 10:29 PM, George Dinwiddie <lists@...> wrote: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@...> wrote:I'd like to second these notions, but add the thought that what Adam>> 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 developers"?
>> 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.
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.
Agile and Lean Coach, Author of Scrum in Actionhttp://www.amazon.com/Scrum-Action-Andrew-Pham/dp/143545913X/ref=ntt_at_ep_dpi_1-1
- 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.