Archive for the 'agile' Category

Talking TDD and Agile on RedMonk Radio with Coté

Coté and I talked Agile the other day for an episode of RedMonk Radio. He was kind enough to invite me into the studio as a result of my recent chapter in an Agile SQA book. We started off covering TDD and the book, but quickly got in more general topics on Agile “in the wild” as Coté would say.

Coté – you self-criticize in your post about editorializing, but you actually do a good job directing a conversation and keeping it moving. Hey man, we’re in the post-modern world and interviewers are allowed to be part of the conversation. Social dichotomies are so 1.0! I did like the setup reference to your secret mental file – a special bonus to listeners who can identify that.

Technorati tags: , , , ,

New Book – Agile Software Development Quality Assurance

The book Agile Software Development Quality Assurance was just published this week:

I contributed a chapter on Test-Driven Development, written from an industry perspective. Many other contributions were academic in nature – interesting in their own right, but I was pleased to add an on-the-ground flavor to the book.

I was shocked at the pricing however – evidently IGI only likes shelf space in select university libraries. My next publishing endeavor will no doubt be more consumer-friendly.

Technorati tags: , , , , ,

Thoughts from Dave Nicolette on Enterprise Agile

Dave Nicolette offered up some phenomenal thoughts in a comment here on the enterprise Agile discussion that Cote’ started. I thought these were worth re-posting at least for the benefit of the aggregator readers who don’t check back for comments…. my thoughts below.

>I’m thinking what you actually had was a single point of representation

Right. “Customer” is a role on the team; there’s no implication that the solution will be used by exactly one individual. In Scrum it’s called “Product Owner.” It’s often a single individual, but there’s no reason it can’t be more than one person depending on circumstances. In “pure” Agile projects the development team is supposed to be colocated with the customer(s). On projects like those, I’ve had direct access to anyone who was to become a user of the new solution. But that’s certainly not always feasible.

It’s ideal in one sense when your users are inside the enterprise because you have a (perhaps?) captive audience, and usually have much easier access to your user base than if you were building a commercial software product. I think co-location is definitely a challenge in enterprises, unless the teams are small and there is some kind of office space glut – not common in my experience. But your’re right on that this makes a huge difference.

>The finances of enterprise IT are one of the most difficult aspects to manage […] annual planning cycles that are difficult to merge with a business-responsive development approach…

I think there’s a widespread myth in our industry that there’s a one-size-fits-all approach to software development. Most IT organizations do at least a couple of different types of software development work. Why assume both types call for the same approach or methodology? One type is user-facing, tactical, vertical business application development. These are projects that have a short list of business goals, a fixed timeline, and an identifiable business customer. They’re usually funded by the business unit that engages the IT department to do the work, and they’re cost-justified on the basis of direct impact to the bottom line. That’s where Agile methods like Scrum, Crystal, and XP really shine.

The other type of development initiative is more akin to product development than project work. Enterprise-scale services are built and maintained on an ongoing basis. Unlike project work, there’s not really an end date and “customers” may be indirect. An example is enterprise SOA development and maintenance. This is likely to be an ongoing effort that has a predictable release schedule, is constrained more tightly by compliance requirements than a tactical app, is funded out of the IT base budget, and cost-justified on the basis of anticipated future savings on tactical projects that are expected to make use of the resulting enterprise facilities. This operation might cull reusable features from various business applications over time, as well, and fold them into the SOA. For this sort of work, a lean development approach is often more practical than a pure Agile approach. Methods like TPS, CMMI, or MSF Agile can apply very well.

Contributing to the general confusion about all this is the fact vendors and consultants tend to use the word “agile” to describe both Agile and lean development methods. Both are aimed at reducing unproductive procedural overhead, but the two are otherwise quite different, and they apply to different classes of problems. Many people say “agile” when what they’re really thinking about is reducing wasteful process overhead, whether through Agile methods or otherwise.

This is an extremely keen differentiation between types of projects in an enterprise, and appropriate approaches. I wish I had come up with that paragraph 😉 I think you are correct that tactical projects and user interfaces lend themselves very naturally to Agile as compared to larger enterprise efforts. (I would add product line practices to your list of approaches.) I don’t mean to sound like a one-size-fits-all thinker (who would sign up for that moniker?).

I would not call myself a methodologist, though I am very interested in methodology. Others will surely disagree, but for me Agile approaches represent more than anything a set of values. I think those values and, now getting more specific, some practices should be applicable across projects using a variety of formal methodologies. A key Agile principle is that teams set their own rules – I think teams should be allowed to pursue a project with the methodology of their choosing, and that might not be Agile, XP, etc. But I do think they would benefit from still using certain Agile practices.

And I will plead guilty to using the Agile term to liberally, especially regarding lean. If I sat down with a methodology therapist, I would probably learn that I am perhaps more of a lean proponent than an Agilist when it comes to fundamental beliefs. I have spoken with Mary Poppendieck on a few occassions, and appreciate a lot of her thinking. Having said that, I think individual Agile practices are again quite portable across various approaches.

>Agile support models…

In a way, you’re making my point about the belief in a one-size-fits-all approach even by raising this issue. Why assume that just because the development teams use Agile methods that the support group must use Agile methods, too? That said, it can be valuable to apply selected Agile practices to production support activities. At our company, we find the XP practice of pair programming works very well in production support. Two brains are better than one, and problems are solved faster. In addition, when two people work a problem together we end up with two individuals knowledgeable about the problem, for future reference. All good.

When supporting applications that were originally built using Agile methods, the support staff has the added advantage of a working, comprehensive test suite. They can run the test suite before making any modifications to code. That way, they can tell whether they are working from a clean starting point. If they write tests for all the changes they make in fixing the problem, then the test suite remains comprehensive and useful for future support issues and for future enhancement projects.

Often, production support teams work down a list of known problems and requested enhancements when they’re not occupied with fire-fighting. They can apply Agile methods in that portion of their work, to gain the same sort of professional satisfaction and the same sort of good results as their colleagues in the development area.

I think you made this point better than I did, but you are saying what I was trying to get at. The fact is that support is not a project, and many of the formal methodologies are oriented around running projects. I think a phrase like Agile Support is intended to indicate that you are applying Agile principles and practices to the support process. You mention some good practices that apply – pairing, TDD. One point I was making is that I just haven’t seen any flesh out a model around applying these practices to support because so much of the conversation is around running development projects – but this is an area of prime concern generally speaking within large enterprises, and I think they would benefit from applying Agile practices – lean approaches – to support.

Thanks for the fantastic comments, Dave, and taking the time to contribute here. I will be subscribing to your blog and look forward to your influence on my thinking.

Agility in Large Enterprises

Cote’ offers up some notes on the practice of Agile techniques at large enterprises, and asks some good questions. I thought I would offer my take here…


What product have you ever built that had 1 customer? 🙂 I’m thinking what you actually had was a single point of representation – and yes that is still a factor in enterprises. The key value at work is customer input – on a frequent basis with very open lines of communication. In our experience, a business analyst or user interface designer helps garden the input; we also hold frequent group meetings with users (more frequent than waterfall, less frequent than purist XP).

The Scrum-of-Scrums Needs Work

This is definitely a difficult point in enterprises, especially because groups are at very different places on the Agile learning/practicing curve (forget the same iteration cycle!), if they are on the curve at all. But I think many other groups appreciate the fact that Agile teams do things like include them as much or as little as they want, communicate with them frequently (rather than dropping a Gantt chart on them 6 months in advance and forgetting to tell them when the rest of the team slips), and give them short but reasonable notice on when to get things done. Yes, the last point is correct – I think a lot of the teams that are just staying afloat with operational activity don’t do well with huge amounts of advance notice. Working short cycles and smaller tasks fits in better with operations.

Sales and Marketing

The finances of enterprise IT are one of the most difficult aspects to manage when practicing Agile, IMHO. Many enterprises have annual planning cycles that are difficult to merge with a business-responsive development approach, where you don’t always know what it will cost up front. So I think the answer here is zone defense – you do what you can to stay traditional for these ceremonial activities, trying to carve out enough room to breathe. I think the proof is in the pudding – you need to demonstrate a lot of success with Agile before these behaviors will change.


Agile support models are the final confrontation in an enterprise. A goal of Agile is to reduce waste in the process, waste here being ceremonial or overhead activities that do not directly add value. Contrast that with compliance needs in an operational environment, and you have some interesting forces on your hands. I think you are right that you can certainly apply the same principles, but where is the actual framework? It’s too fun and cool to talk about development – none of these wonks want to flesh out an Agile support approach. Maybe we should make sure James tackles that in his coming book (again, I’m plugging you for info, James)?

Enterprise Installs Every 2 Weeks?

You had to say installs, didn’t you? I choose to interpret the working-system-at-the-end-of-iteration mantra so it suits my needs. I think what you really need is usable system somewhere – preferable an integration environment – at the end of every iteration, with Production schedules less frequent, but frequent enough to be aggressively useful. The idea behind continuous delivery in my view is to ensure that integration happens sooner rather than later, to make sure the implementation stays integration-friendly (is on people’s minds while coding), and to close the loop with customers. On the last point – that means both ensuring that what you did is correct, but also to let them play around before prioritizing your next amount of work… part of the maximizing the amount of work not done principle (“oh, we can just do it that way? well, let’s forget about that other idea, then…”).

Sure there is hype in the Agile community, but I think a lot of that is not from is promoters, it’s from recently-bitten practitioners. You have to dig an approach that gets people excited about their jobs again. But without being a dogmatist trying to apply Agile to how you fill the coffee filter, there are no doubt ways to solve some long standing enterprise IT practices that are low value.

Diabetic Runner Challenge – 500

Flickr Photos

Creative Commons License
This work is licensed under a Creative Commons Attribution 3.0 License.

Site Meter

RSS Latest Runs

  • An error has occurred; the feed is probably down. Try again later.

RSS Latest Routes

  • An error has occurred; the feed is probably down. Try again later.