Add a Comment

Comment by Rory McKinley on October 19, 2009 at 19:28

phpslacker: Yeah, you are right about TDD (and I think many of the other XP practices). Devs with a few trips around the block are more likely to see the merits of XP if they have already felt the pain of the freak show that is software development. Junior devs could probably grow into XP if mentored (and here pair-programming is probably an excellent way to bootstrap).

greg: I think the success of junior devs will very much depend on the composition of the team. If the team is salted with a couple of grizzled veterans :), then I think juniors can play a valuable role if their energy can be directed. However, if your team is overwhelmingly juniors, then I would agree with your assessment.

The caveat is that, even if you have senior devs, that is no guarantee of success, unless they have the right attitude. The interwebs are full of seasoned devs that scoff at Agile principles. I have met devs who, while senior, don't like the discipline and accountability that Agile practices demand. Both the above "types" are examples of people who could hamper any effort to introduce Agile principles in general (and scrum in particular) as much as a junior dev.

Comment by Greg Eales on October 19, 2009 at 18:50

I still maintain it can only work on a senior level:

Juniors usually get lumped into support, where they pick up hacking habbits. It is onlt when they get the "essense" of dev that they actually appreciate SCRUM and not just see it as some steps to follow.

As PhPSlacker said, you can write off TDD with Juniors, they just dont get it.

Juniors are more concerned with getting the thing to work over good refactorable design philisophies. Which is the essense of ANY agile process.

Getting juniors to estimate tasks and burndown is like loading your six shooter with blanks and throwing it into the darkness.

SCRUM leaves the responsibility of the project to the dev, it is a trust relationship. Which brings me to my next point, juniors dont really know the implications of falling out of your sprint sandbox. They tend to take the approach of "Will keep trucking till it is done" rather than using sprints to track velocities in a feature based fashion.

Comment by Quinton Parker on October 18, 2009 at 21:42

@Rory I agree. I realized soon after my previous post that I was referring more to XP than SCRUM. SCRUM doesn't advocate TDD (XP does). SCRUM alliance may mention TDD. Maybe advise it.

TDD is hard... for novice programmers. When u TDD u better know ur Object-Oriented Design principles so that ur tests can run without dependencies like databases, frameworks, blah. Thats the skill-level problem i was referring to.

Back to Rory's point. So SCRUM adoption doesn't require skillful developers since the TDD requirement is loose and optional. It certainly does require people who able to work autonomously (or self-organizing). Some are quite happy to be sheep. Nothing wrong with that

Bearing this in mind, if u want an XP team u need to predominantly hire ppl who desire to be autonomous and self-organizing else u better pick a different method such as SCRUM. If ur team is full of sheep and generally stuck in the dark ages then waterfall is the better choice. Really.

So if u could categorize employees into 2 types of people they might be

1. Peeps who wait for things to happen to them
2. Peeps who believe they have the power to influence the outcome of things that affect them

Guess which type is good for ur agile team?

Link to "Kinds of employees you want to hire" article:

http://www.businessweek.com/managing/content/sep2009/ca20090922_894897.htm

Comment by Rory McKinley on October 18, 2009 at 16:48

phpslacker: It's not always a matter of skill level. Even developers that have years of experience may simply not have the right attitude to be an effective part of a "self-organising" team.

Perhaps there is a danger in taking developers who have always been told what to do and when to do it and then telling them that they are self-organising masters of their own destiny and leaving them to their own devices.

If you are a Safari books subscriber, you can read initial drafts of Mike Cohn's upcoming book - he makes a point about the composition of a team (amongst other things) and how there needs to be a difference in skills amongst members. Perhaps this could be extended to attitudes as well?

I view Scrum's ceremony as training wheels :) - it gives you a nice safe framework if you are prepared to supply the elbow grease. Once you have spent lots of time with the ceremony you can slowly evolve to agile practices that perhaps use elements of scrum without the ceremony?

Where I work, I think we have been doing quite well so far, but as we grow and learn, areas that we could safely ignore in the early days are going to have to be addressed. Some of these areas are not pretty :). I am not worried about addressing these areas, what worries me is that we may be overconfident regarding how much we think we know.

Comment by Quinton Parker on October 18, 2009 at 12:24

@Carlo @Greg woa guys I've been pondering on these very issues over the last month or so myself. I feel that scrum is an adoption framework for teams who heard about the wonders of this "agile thing". Its a me-too framework. Note: I'm not slating SCRUM

Agile adoption shouldn't really be "adoption". It should b a natural revolt to the naive madness that is waterfall. I too believe that u need to have been burnt by waterfall to want a better way of doing things

Does anyone for one moment think that the guys who drafted the agile manifesto use SCRUM? I doubt it. Their decision-making & moves are far more natural than that. If u understand agile u can however see the same values & principles implemented in SCRUM. The agile principles are there its just that SCRUM training focusses on the ceremony

Agile is pitched by the experts in software industry in an attempt to evangelize other experts. Its not suitable for "younger" devs. The reason for this is distinction can be found in the Dreyfus model for skills acquisition. SCRUM/Agile adoption in a team of novices is like handing a blowtorch to a toddler. Only competent to proficient developers will realize and comprehend agile values & principles. Unfortunately for me, this is empirical knowledge :/

Comment by Carlo Kruger on October 18, 2009 at 10:34

Hi Greg. Not sure I agree. While younger devs usually lack the skills to implement effective scrum at the code face level, what they have going for them is a lack of the muscle memory of years of waterfall and the right attitude. The more scrum teams I coach, the more I realise that actually agility in coding is much more than just writing some unit tests. Being able to truly work incrementally is not well understood and teams have a tendency to fall into a mini-waterfall anti-pattern.

Comment by Greg Eales on October 17, 2009 at 22:59

I give us a 5 too.
To be honest I dont think most companies have the skill level involved to implement SCRUM. The discipline and trust required for it to work is only seen on senior dev levels.

Comment by Quinton Parker on October 9, 2009 at 15:02

My teams scrum implementation gets a 5 /10. hehe

We're working on it :/

Scrumsense doing CSM courses in December '09

http://www.scrumsense.com/training/public-certified-scrum-training-courses-for-2009

I wanna be there! Peter, this free advertising gets me a discount, right?

Comment by Bridgetti Lim Banda [CIO FORUM] on October 9, 2009 at 2:47

Hi Everyone,

I know it's a tad late to be posting an invite for tomorrow, but if you are available, come along for this one.

KNOWLEDGE MANAGEMENT THROUGH VISUAL MODELING AND CAFÉ CONVERSATIONS

KM through Visual Modelling_CafeConversations 9Oct09.JPG

Comment by Carlo Kruger on October 7, 2009 at 16:44

A quiz based on James Shore's "Art of Agile Development", has a fairly comprehensive survey with radar chart and suggestions for practises at:

http://www.abetterteam.org
The team I am coaching at the moment barely registers the implementation is so poor...

• ‹ Previous
• 1
• 2
• Next ›
• Page