Re: [scrumdevelopment] Experience requirements for Scrum (team)(was: Re: Scrum Guide interpretation)
- On Mon, May 2, 2011 at 12:50 PM, Adam Sroka <adam.sroka@...> wrote
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.Hi Adam,
I think I understand and agree with your statement above when you said "how" to tailor is important but in my mind "when" the organization can start the tailoring is also key, especially if they have not gone through at least one complete cycle with Agile or Scrum to see how things really work and see what kind of results they get in their context.
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.Completely agreed with you that it will be rather dangerous for an organization new to Agile to tailor Agile without coaching expert guidance but this is almost unavoidable since Agile and especially Scrum sounds so simple after one Agile white paper or two...
From what I have seen from some project teams, it looks like some people seem to think that building software from user stories with some user involvement and having continuous integration in place is enough to qualify what they do as agile, but it is often not true....
Agile and Lean Coach, Author of Scrum in Action
> *1*<http://www.amazon.com/Scrum-Action-Andrew-Pham/dp/143545913X/ref=ntt_at_ep_dpi_1>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 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.