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’t the only “agile” method.  As James points out, the engineering practices of Extreme Programming such as pair programming, test driven development, continuous integration, evolutionary design and refactoring are all critical.  Do they have to be done and perfected first?  No.  But eventually, if you are using Scrum to build software (not everyone is), they do have to be done.

As a Certified Scrum Trainer, I have always emphasized how Scrum is hard, and how being a ScrumMaster is very very very hard.  This is why my training class is three days instead of two.  This is why I don’t encourage anyone to come to it, only people who will be ScrumMasters.  This is why after the first day of my course, most students are actually feeling quite discouraged!!!  It takes three days minimum for people to understand and process the incredible shift in mental model.  And of course, even after three days, it is oh so easy to revert back to our normal thinking habits.

So what should people do?  Do Scrum by the book.  Yes that means putting a whole team in a single room.  Yes it means that you have to really remove obstacles, and fast!  Yes that means that your teams actually have to be cross functional (and not just in the weak sense of multi-skilled developers).  Yes that means that it - will - take - a - long - time - to - get - it - right!!!!

And please, it is so worth getting help beyond just the training!  If you think that I’m just trying to promote my own coaching services, please go check out:

www.ccpace.com

www.rallydev.com

www.outformations.com

www.lithespeed.com

www.mountaingoatsoftware.com

www.controlchaos.com

www.bigvisible.com

www.kittyhawkconsulting.com

They all have great coaches and I would absolutely way rather see you succeed than believe that I am just trying to promote my own business.

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.

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

Here’s another one from this blog:

A Cautionary Tale.

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 system in order to fully express its happy paths, edge cases, etc. However, the code coverage here is a symptom, not a cause, of a well-tested system. And the metric can be gamed. Actually, when imposed as a management quality criterion, it usually is gamed. Good metrics should confirm a result obtained by other means, or provide leading indicators. Few numeric measurements are subtle enough to really drive system development.

Having said that, I have used code-coverage in this way, but in context, as I’ll mention later in this post.

Kevin provides example code similar to the following:

String foo(boolean condition) {
    if (condition)
        return "true";
    else
        return "false";
}

… and talks about how if the unit tests are only testing the true path, then this is only working on 50% coverage. Good so far. But then he goes on to express that “code coverage only tells us what was executed by our unit tests, not what executed correctly.” He is carefully telling us that a unit test executing a line doesn’t guarantee that the line is working as intended. Um… that’s obvious. And if the tests didn’t pass correctly, then the line should not be considered covered. It seems there are some unclear assumptions on how testing needs to work, so let me get some assertions out of the way…

1. Code coverage is only meaningful in the context of well-written tests. It doesn’t save you from crappy tests.
2. Code coverage should only be measured on a line/branch if the covering tests are passing.
3. Code coverage suggests insufficiency, but doesn’t guarantee sufficiency.
4. Test-driven code will likely have the symptom of nearly perfect coverage.
5. Test-driven code will be sufficiently tested, because the author wrote all the tests that form, in full, the requirements/spec of that code.
6. Perfectly covered code will not necessarily be sufficiently tested.

What I’m driving at is that Kevin is arguing against something entirely different than that which TDD proponents argue. He’s arguing against a common misunderstanding of how TDD works. On point 1 he and I are in agreement. Many of his commentators mention #3 (and he states it in various ways himself). His description of what code coverage doesn’t give you is absurd when you take #2 into account (we assume that a line of covered code is only covered if the covering test is passing). But most importantly - “TDD proponents” would, in my experience, find this whole line of explanation rather irrelevant, as it is an argument against code-coverage as a single metric for code quality, and they would attempt to achieve code quality through thoroughness of testing by driving the development through tests. TDD is a design methodology, not a testing methodology. You just get tests as side-effect artifacts of the approach. Useful in their own right? Sure, but it’s only sort of the point. It isn’t just writing the tests-first.

In other words - TDD implies high or perfect coverage. But the inverse is not necessarily true.

How do you achieve thoroughness by driving your development with tests? You imagine the functionality you need next (your next increment of useful change), and you write or modify your tests to “require” the new piece of functionality. They you write it, then you go green. Code coverage doesn’t enter into it, because you should have near perfect coverage at all times by implication, because every new piece of functionality you develop is preceded by tests which test its main paths and error states, upper and lower bounds, etc. Code coverage in this model is a great way to notice that you screwed up and missed something, but nothing else.

So, is code-coverage useful? Heck yeah! I’ve used coverage to discover lots of waste in my system. I’ve removed whole sets of APIs that were “just in case I need them” APIs, because they become rote (lots of accessors/mutators that are not called in normal operations). Is code coverage the only way I would find them? No. If I’m dealing with a system that wasn’t driven with tests, or was poorly tested in general, I may use coverage as a quick health meter, but probably not. Going from zero to 90% on legacy code is likely to be less valuable than just re-writing whole subsystems using TDD… and often more expensive.

Regardless, while Kevin is formally asking “is code coverage useful?” he’s really asking (rhetorically) is it reasonable to worship code coverage as the primary metric. But if no one’s asserting the positive, why is he questioning it? He may be dealing with a lot of people with misunderstandings of how TDD works. He could be dealing with metrics bigots. He could be dealing with management-imposed-metrics initiatives which often fail. It might be a pet peeve or he’s annoyed with TDD and this is a great way to do some agile-baiting of his own. I don’t know him, so I can’t say. His comments seem reasonable, so I assume no ill intent. But the answer to his rhetorical question is “yes, but in context.” Not surprising, since most rhetorically asked questions are answerable in this fashion. Hopefully it’s a bit clearer where it’s useful (and where/how) it’s not.

(This article is a cross-post from “Geek in a Suit”)

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 few:

First, it’s a way for Negar to remind Peter that she does not have a technical background and that he should not assume that she is familiar with web-lingo.  Second, it also reminds him that she is a different person from the last manager he was working with and subtly reinforces that it’s important that they get to know each other as two individual human beings and learn to work together effectively.  Third, and perhaps most importantly, it gives Peter an opportunity to help someone else on the team learn something new, and by doing so, contribute to the culture of learning on the team.  Fourth, and perhaps most obviously, it promotes open lines of clear communication on the team.

(Of course, if the team was colocated, which it is not, lack of communication would be much less of an obstacle!)

Asking questions in the interest of learning makes it visible to others that you don’t know everything.  For some people, this presents a dilemma.  What makes it a dilemma is that asking meaningful questions is something that many people aren’t able to do well.  The ability to ask meaningful questions is a learnable skill requiring the capabilities of truthfulness, humility and courage.  Such capabilities - let’s call them moral capabilities - can themselves be developed through conscious, focused effort.

Someone in the position of a newly hired manager, or a veteran manager with a new team, who lacks these capabilities may feel that it is important to present to a team a persona of all-knowingness.  But, of course, this is false and the truth of one’s degree of knowledge and capability, or lack thereof, soon becomes apparent anyway.  Clearly, this person needs to do some honest hard work to develop some humility, but truthfulness and courage are still often major factors.

Or maybe you’re the kind of person (like Negar) who just doesn’t want to bother anyone.  In this case, humility is not necessarily lacking, but truthfulness - and perhaps most of all courage - may need some attention.  Concepts around moral capabilities deserve much more elaboration, but for the sake of brevity, I’ll leave it at that.

To sum it up, if you are open and clear in the way you ask questions, people will tend to appreciate it and will trust you more in the end.  Moreover, it can have a transformative effect on the environment of the team.  When your team members realize that you are not afraid to ask questions and be truthful about your lack of knowledge in a certain area, it will encourage them to be more truthful about their own capabilities.  Not to mention that most people feel good when they are able to help others.  When your team members feel safe to ask for help and free to help each other, it is empowering for everyone.

Asking meaningful questions, therefore, is an essential aspect of learning together, and nothing is a more powerful contributor to the success of an organization than a team that learns as a team.

Here is the link, check it out:

http://www.notesfromatooluser.com/2008/07/journal-of-agilescrum-failure.html

If you are currently or have recently worked on an agile team that completed a project or a delivery of software, I encourage you to participate in a study being conducted.  Here is a link to the study information.  And here is a link to an online survey that is part of the study.

Okay, global markets are in turmoil.  Consumer spending is dropping.  Economists are forecasting recessions or extremely small growth.  Businesses are adjusting revenue and earnings forecasts.  Bad news all around.

Actually, no.  This is the perfect time to be in business.  This time of crisis can actually be the opportunity that your business desperately needed, you just didn’t know it.

The way to get through this is simple: focus on value, remove waste and obstacles.  The trouble is, simple though this sounds, it’s actually very hard for many businesses.  Why?  Because one of the first responses to financial crisis is to cut costs, and the easiest, most obvious cost in most businesses is staff.  Cutting staff is not the same as focusing on value and removing waste and obstacles.  In fact, cutting staff is almost the exact wrong thing to do.  Why?  Because you still leave in place all the old policies, procedures, checkpoints, systems, role definitions, chokepoints, logjams and wasteful activities that were hidden because we were riding through “good times”.

It’s true, of course, that staff are a substantial cost for most businesses.  However, we sometimes lose sight of the fact that in any business where staff is a substantial cost, it also probably means that staff are responsible for a large proportion of the value your business generates.  Cutting staff therefore means reducing value, and that just puts your business into a vicious cycle. Cut staff, deliver less value, customers and clients don’t get as much value, they start looking elsewhere, you get more revenue pressure, you cut more staff, etc.  Not only that, but if you cut staff, but leave the bureaucracy in place, then the ratio of bureaucratic overhead to staff is increased leading to even worse productivity!

Okay, so where does agile fit in?  Simple: agile methods such as Scrum for software work and OpenAgile for business management are designed to help you find waste, remove it, focus on value, learn from both successess and mistakes, and do better next time all in very short cycles which allow you and your business and your teams to adapt to changing (market, economic, competitive) conditions very quickly, always delivering the highest value fastest and at the best price.

Recent case studies in the Scrum community are showing revenue gains of 200 to 400 percent in less than a year for companies that are rigorously adopting Scrum, not as a “solution” or a “methodology” but as a powerful, principle-based, learning framework applied universally.  Scrum and other agile methods, when used properly, cause substantial, deep changes in an organization’s culture and habits.  These changes all center around the idea of delivering high value, high quality, quickly, and always getting better and better and better at doing this.

Teams using agile methods become super-teams.  Organizations using agile methods become super-organizations.

Feeling the fear of recession?  Feeling the need to cut costs?  Anxious if your job, your team or your business is going to survive this crisis?  Use agile - Scrum, OpenAgile, Extreme Programming, Lean Software Development, Crystal - to not just survive the crisis, but to thrive while your competition struggles and succumbs to the challenges.

Some Other Reasons Agile is Good in a Recession:

“customers will start asking about iterative deliveries (to control spendings(sic))” - (agilerevolution.net)

“Agile can drastically improve time to benefits, quality and efficiency, team morale, the relationship between IT and business staff, and responsiveness to change.” - (thoughtworks.com - PDF)