Author: Stan

Update from the Agile 2008 conference

I’ve spent a lot of time in the Borland booth the last few days, explaining our new BMS software to passersby. It’s actually been a lot of fun, as I’ve had the opportunity to talk with lots of people about our own agile experiences at Borland.
The most interesting conversation was with an agile coach from Sweden. If I understood him correctly, he believes that scrum has reached the point of being just another buzzword, and that many organizations are pursuing it just for buzzword-compliance, not understanding the fundamentals and value of scrum. I’m sure there’s a certain amount of that, but I don’t think it’s widespread enough to warrant his sharp opinion.
He did raise interesting one point, though: fork out a couple thousand dollars, attend two days of training, and you, too, can call yourself a certified scrum master. He believes that scrum masters should have much more training than that. He said that the agile coaches he’s working with have developed a year-long process for learning how to facilitate agile.
This guy’s thoughts on what it takes to be a qualified scrum master meshes with a conversation I had yesterday with some of my Borland coworkers. One of them was suggesting that scrum masters could benefit from facilitator training since facilitation is an established discipline that’s very similar to the role of scrum master. I would love to get some facilitation training.

Greetings from Agile 2008

Unfortunately, I didn’t get to attend any conference sessions on Tuesday. Several Borland employees got hung up in Chicago due to bad weather, so I spent most of the day working the Borland booth. I plan to attend some sessions today.
Borland booth at Agile 2008

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.

Agile 2008 Conference

I’ll be attending the Agile 2008 Conference in Toronto next week. Among other things, I’ll be working the Borland booth a few hours each day. Drop by and see me. And while you’re there, watch our ‘Day in the life of an agile team’ video, in which I star as … wait for it … an agile team member. I have a speaking role and at least a couple of minutes of screen time!

Form field validation zaniness

My coworker who has a two-letter last name has complained of applications that require a longer string in the ‘last name’ field. Somehow, I think most applications I’ve ever tested would have the opposite validation error for this guy.

Exploratory testing

Lately, I’ve been thinking a lot about the role of conventional QA engineers on agile projects. In my earlier post on this topic, I concluded that there is less need for non-coding QA specialists on agile teams, but that the skills that such a person brings to the table are still necessary.
In a recent column over at StickyMinds.com, titled Does Exploratory Testing Have A Place On Agile Teams?, Johanna Rothman writes the following:

Agile projects require true generalists as testers: people who have requirements-, design-, and code-understanding skills. Without those skills, they can’t think critically enough about the product under development, and they might not be able to create enough variety of tests. If they understand the requirements, design, and code, they can turn that understanding into crafty tests. Some of those tests will be exploratory. Even some of the exploratory tests will need to be automated in order to repeat them. And, I’ve seen great testers on agile projects who can quickly create automated tests to do some of their exploration.

I read that as a confirmation of my thinking. Coders can indeed do testing, but it takes someone on the team who has the big picture in mind in order to do good exploratory testing. QA generalists are needed to do this work.

Can distributed teams be agile?

In a recent blog post, Tobias Mayer observed that one of the hottest topics around is how to do agile with geographically distributed teams:

Many Scrum practitioners these days are working hard to come up with the best way to make Scrum work in distributed (usually off-shore) environments. There are many articles being written on this topic, and many submissions to the major Scrum and Agile conferences. They all say something similar, we know that co-location is ideal, but the reality is… and then go on to offer “solutions” (read work-arounds) for the non-ideal, real world situation where team members are scattered around the globe.

Tobias’ main point is that we should question the assumption that we have to work with distributed teams:

It is interesting how the phrase “the real world” is used almost as a weapon to wield against the idealist: yes, it is all very well to say that teams should be co- located but that is not how people actually work in the real world. We seem to forget that reality is not something that is imposed on us. Reality isn’t just there; we create it. The phrase “the real world” is akin to the phrase “it’s just the way we do things around here”. Both should be challenged with a healthy dose of skepticism and a steady barrage of “why” questions. Just because it is, doesn’t mean it has to be.

From my experience, I think Tobias is absolutely correct on both counts. Whenever I’ve heard someone ask about making agile work with distributed teams, the first response is that it can’t; teams need to be collocated. And invariably, the person posing the question replies that the decision to have a distributed team is out of their hands. And in my experience, most of the time, the decision to embrace off-shore resources really is out of the practitioner’s hands. The practitioner can question the wisdom of distributed team all he wants to no avail.
But you know, this is just a subset of the general issue with offshore development. The exec who makes the decision sees money: I can hire two engineers in X for the cost of one engineer in Y. But the practitioner has to deal with the reality: two engineers geographically removed from the rest of the team are hardly as productive (or less so) than one collocated engineer. Plus, the company is paying gobs of money to fly people around the world to manage the arrangement.
As the outsourcing situation matures, my prediction is that decision makers will begin to understand the actual value proposition of outsourcing, and we’ll see more collated teams again.
If the problem lies with distributed teams, not with some fundamental disadvantage of off-shore development itself, then the people advocating collocation had better be prepared for this eventuality: their company may just decide to collocate teams by moving an entire development effort off-shore. I know of one company in Austin that has moved all of its development to India, and my own company has relocated all development for one product from the US to Singapore.

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.