Toluu

Agile Advice

The Decline and Fall of Agile and How Scrum Makes it Hurt MoreNovember 16

James Shore wrote a great post about the problems he is seeing with agile adoptions that start with Scrum called the Decline and Fall of Agile.  Please please please (pretty please) read it before you read what I am about to write here!  I agree with what James is saying 100%.

Now, let’s hear the truth:

Scrum is really really hard!  Doing Scrum well is like quitting a heavy, long addiction (I think).  Don’t ever make the mistake that because Scrum is simple (lack of complexity) that it is somehow therefore easy (lack of effort).

Doing Scrum properly takes:

sacrifice - sacrifice of our ways of thinking, our habits, our comfort

wisdom - wisdom to see the small improvements while struggling with the humongeous ones

and most importantly,

truthfulness - honesty to see and say the truth, integrity to act on the truth, detachment to avoid believing in what you want instead of what is real, courage to continue even when things aren’t perfect or easy

Scrum depends heavily on commitment both at the small scale of an individual committing to a small piece of work, and at the large scale of an organization committing to real deep cultural change.  Without that entire spectrum of commitment, it is unlikely that adopting Scrum will be anything but the latest fad imposed by management or done stealthily by staff.

But Scrum isn�

Agile in Ottawa - Meetup on the 24thNovember 14

Glenn Waters whom I have worked with in the past, is getting the Agile community in Ottawa up and running again.  Check out the details on his blog: Agile Ottawa.

Scrum Case StudiesNovember 6

Great link from Mark Levison on agile / scrum case studies!!!

Here’s another one from this blog:

A Cautionary Tale.

Yet another misunderstanding of TDD, testing, and code coverageNovember 4

I was vaguely annoyed to see this blog article featured in JavaLobby’s recent mailout. Not because Kevin Pang doesn’t make some good points about the limits of code coverage, but because his title is needlessly controversial. And, because JavaLobby is engaging in some agile-baiting by publishing it without some editorial restraint.

In asking the question, “Is code coverage all that useful,” he asserts at the beginning of his article that Test Driven Development (TDD) proponents “often tend to push code coverage as a useful metric for gauging how well tested an application is.” This statement is true, but the remainder of the blog post takes apart code coverage as a valid “one true metric,” a claim that TDD proponents don’t make, except in Kevin’s interpretation.

He further asserts that “100% code coverage has long been the ultimate goal of testing fanatics.” This isn’t true. High code coverage is a desired attribute of a well tested system, but the goal is to have a fully and sufficiently tested system. Code coverage is indicative, but not proof, of a well-tested system. How do I mean that? Any system whose authors have taken the time to sufficiently test it such that it gets > 95% code coverage is likely (in my experience) thinking through how to test their

The Importance of QuestionsOctober 28

I’m currently doing some coaching work with Negar, a new project manager working with a small team of web developers at a community development organization in Toronto.  We had our first session last week.  Negar was having trouble getting started on a particular project and I shared with her some of the Agile methods of creating a prioritized Cycle Plan, breaking it down into small tasks, etc.

Negar seems to be finding Agile methods helpful in general, but there was a special kind of interaction that we had around removing an obstacle that was particularly interesting for me.  It had to do with an email she received from Peter, a developer working on one of the websites she’s managing.  Negar shared a concern that she didn’t know some of the technical terms Peter was using.  So I had her read through the email and form questions around the points she wasn’t clear about - i.e., “what are buttons?” and I wrote them down as she was speaking.

I then suggested that she compose a reply email containing the same set of questions.  Negar’s eyes opened wide and she exclaimed, “Oh yeah - that’s so obvious!”  I went on to mention that another option would be to go and do some research on her own but that there were some valuable advantages in asking Peter directly, particularly in terms of team-building, that may not be as immediately apparent as asking the questions solely for the purpose of having them answered.  Here are a f