Category: Agile

The end of demoware

Damon Poole points out a benefit of agile development that I hadn’t given much thought to:

…the reason I enjoy Agile development is because it made my job more fun. Today, thanks to Agile development, I interact with customers more than ever before. As a product owner, I do more demos and am able to provide new features that hit closer to the mark faster and more frequently than ever before. This in turn means more oohs and ahs from customers which is more fun for me and more profitable for the business.

As I mentioned in an earlier post, I’ll be working the Borland booth at the Agile 2008 conference in Toronto next week. We will be showing the integration between SilkCentral Test Manager and a popular open source testing tool. (The marketing people won’t let me say be more specific here; come by the booth at the conference to find out more!) The guy who’s preparing the booth demos and materials for the integration just sent me the following email:

I’ve been working . . . on our Agile Test Strategy for SCTM [SilkCentral Test Manager] and how it relates to our other solutions. I’m putting together the PowerPoint for the ‘demo loop’ in the booth based on the information I was able to gather over the last couple of days.
Also, I have a VMWare image of the integration . . . I plan to have screen shots of the demo . . . but have the VMWare image available for those who’d like more info on the integration.

The integration that we will show at the conference was developed very recently but will be released later. Due to our internal use of agile, we have this functionality working now, and we will be able to demo it. Without agile, I would have been stuck in the booth with the slide deck and other published materials only.

Fake it till you make it

In an earlier post, I compared agile to 12-step programs, and I listed 12-step slogans that could also apply to agile.
Since I posted that, one slogan that I missed keeps coming to mind: Fake it till you make it.
In AA, ‘Fake is till you make it‘ is “a suggestion often made to newcomers who feel they can’t get the program and will go back to old behavior. The suggestion implies that if the newcomer acts according to the steps and teachings of the program, then the program will begin to work and the anxiety will fall away.”
In his book Agile Software Development, agile guru Alistair Cockburn applies the Japanese martial arts concept of ‘Shu Ha Ri‘ to agile adoption. Mr. Cockburn writes of the first phase: “In Shu, the student should be working to copy the techniques as taught without yet attempting to make any effort understand the rationale of the techniques of the school/teacher” (p. 18). In the second phase, Ha, “the student must reflect on the meaning and purpose of everything that he has learned and thus come to a deeper understanding of the art than pure repetitive practice can allow” (p. 18).
To me, that sounds an awful lot like ‘Fake it till you make it.’

Borland on Borland: Enterprise Agile Transformation

Borland just released a white paper that discusses our move to agile: Borland on Borland: A Case Study in Enterprise Transformation. The section on agile testing briefly covers the first phase that I’ve helped to define and implement:

One area where Borland was particularly challenged was around test automation. According to Agile principles, every feature that gets developed within a sprint must have associated test cases that have been run. Unfortunately, automating the tests is not always possible – and sometimes creates waste. For instance, if the user interface of a release is going to change significantly in a given sprint, any test cases that are created and automated will have to be scrapped and redone.
To overcome this issue, Borland made a slight adaptation to this Agile practice. In “Borland Agile” a feature or story is completed in a given sprint if the team has designed the test cases and run them to ensure they work. The automation is then completed in the next sprint. There are many risks involved in taking this approach. One of the tenets of Agile is that there is a clearly defined set of deliverables that must be met before a user story (or feature) is considered complete. By changing the completion criteria, and signing off on a feature or user story pending an action that will take place in the following sprint, there is the risk that the team will forget to complete the action – automate the tests – when they get focused on the next sprint.

The white paper only discusses one of several concerns with this ‘one sprint behind’ approach. The biggest concern, of course, is that the outstanding automation or enterprise testing tasks may uncover quality problems in the otherwise completed functionality. Therefore, at the end of the sprint, the teams that use this approach are careful to qualify what ‘done’ means. Typically, at the end of the sprint, the code is ready for user acceptance testing in specified environments, but we do not call it enterprise (release) ready until all outstanding quality tasks are completed.

Agile and AA

I just ran across a blog post by Tobias Mayer that compares scrum to Alcoholics Anonymous. Like scrum teams, AA groups are self-organizing with no formal leadership, and the participants of the group work closely together on a focused, shared goal. And of course, both AA and scrum require constant re-evaluation and change. Tobias goes into more detail in his blog post.
To extend this line of thought, I reviewed AA slogans and found many that would apply to scrum. Among them:

  • One day at a time
  • First things first
  • If it works, don’t fix it
  • KISS–Keep it simple, stupid!
  • Live in the now
  • Be part of the solution, not the problem
  • Decisions aren’t forever
  • Let go of old ideas
  • Change is a process, not an event
  • Courage to change
  • Principles before personalities

A social animal?

Jon Williams makes the following observation:

Agile development practices require a developer to be social. There’s a daily scrum, pair programming, end-users on team, kaizen meetings and the like, all situations which require high social interaction.

I can agree with that. He then follows with these questions:

(a) Does Agile push developers out of their comfort zone to be more social, OR (b) Did Agile come about because developers want to be more social?

My answer is neither one; for me, context is the deciding factor in my sociability. Like many software engineers, I’m an introvert. Put me in a large group of people whom I don’t know well, and I will clam up and try to escape as soon as possible. But if you put me in a small group of people I know well, I seem like the life of the party.
For this reason, I love working in an agile environment! I’m part of a small team who I know well and trust. I thoroughly enjoy interacting with my team. In fact, at my current job, I’ve taken on the role of social organizer and of helping others to form more personal relationships. My wife finds this role amusing since I’m pretty closed down in many mixed social settings with her.

They think they’re ‘doing agile’

In my discussions and reading, I hear a lot of people declare that so-and-so group thinks they’re agile, but they aren’t really. I don’t think this type of either/or judgments are very useful–there isn’t really a checklist of criteria for judging whether a group is truly ‘doing agile’ or not.
I think there’s a more useful question to ask: has a group understood and embraced the principles of agile or have they viewed it as just a set of practices to be adopted (e.g., short iterations, daily stand-ups, etc.)?
It doesn’t do any good to tell a group, for instance ‘To be agile, you need to do X’ without explaining the principle behind the practice.
Unfortunately, this sounds like a group that doesn’t grasp the principles of agile. I really feel for the tester who posted the frustrated message to the forum. He seems to be trying to embrace the principles with team members who don’t see them too clearly.