Adopting or Adapting Agility

I often come across people who wonder how they can adopt agile practices. This is a fair question and I often spend some time explaining that agility is not really an important goal. Agility is just a means to an end and that end is to deliver better business value. I like this goal because it is can never be fully realized – there are always ways to get better.

I recently listened to a webinar by ThoughtWorks on agile readiness assessment and I am reading Agile Adoption Patterns: A Roadmxap to Organizational Success, by Amr Elssamadisy, © 2009 Pearson Education Inc.. Both of these are excellent resources and I decided to write a white paper that combines agile assessment with adoption and adaption. I included adaption because some agile teams reach a plateau and need an approach that pushes them through to the next level.

Adopting or adapting agile practices requires a strategy that aligns your team’s agile goals with your overall business goals.

Please feel free to download the white paper and let me know what you think!

Agile Product Design and Development Workshop with Jeff Patton

I am really looking forward to helping Jeff deliver his workshop on Agile Product Design and Development on September 10th in Kitchener.

Jeff brings a fresh perspective on agile development focusing more on product definition and user experience; areas that are not usually well covered in agile books and training materials. He advocates passionately for end users and weaves insightful user experience practices with agile practices to arrive at a solid approach to agile product design and development.

If you would like to find out more about the workshop or register for it please check out the event website at:

If you can’t make the workshop but would like to hear Jeff, he will also be providing a 90 talk entitled Embrace Uncertainty:Strategies for an on-time delivery in an uncertain world which you can register for at the Communitech Events web site.

PostRank – A .NET API for AideRSS PostRank

AideRSS provides a service that ranks online content such as RSS feeds, blog posts and so on. I have always been impressed with AideRSS and wanted to educate myself with writing REST interface logic, ASP.Net and Web 2.0 in general. AideRSS also provides a PostRank API to their service so I decided to write a .NET client wrapper for this API to make it easier to use. You can download the API including source and binaries from here:

Why Did I Write This?

My goal with the API beyond learning some new stuff was to leverage TDD and allow emergent design to surface an underlying domain model. I wanted to avoid a simple static functional wrapper for the API and instead provide a design that would allow more powerful usages of the PostRank API. I wanted TDD to help evolve a reasonable domain model which would include classes to represent feeds, posts and so on. To do this I systematically applied the XP rules of simplicity:

  1. Testable – has a test
  2. Communicative – classes and methods are intent revealing
  3. Factored – no duplication of logic or structure
  4. Minimal – minimum number of classes and methods

While I am not an expert on RSS or the PostRank API I am quite happy with the resulting API. The classes that emerged make sense, at least to me! There is also a safety net of 105 unit tests that I can use for future refactoring and enhancements.

What Does it Do?

The API provides full access to the underlying PostRank API. Besides creating unit tests for the code I also included a demo command line application and a demo ASP.Net project.

The demo command line program takes a single command line argument which is the RSS feed you are interested in and defaults to Ilya Grigorik’s blog:

PostRank Command Line Output

The ASP.Net project provides an interactive UI allowing you to enter an RSS feed and see AideRSS PostRank features such as top posts in a given time period. The screen shots below show some of the features of the API:

Top Posts of the Year Top Posts of the Month Great Posts

Note that there is an alternate .NET API written by William Spaetzel that you can get from

I welcome any feedback you may have on this API.

Zoomii – A Refreshing Way to Buy A Book Online

I recently bought a book at (in the US you can use and it was the most refreshing online purchase I ever made. This is because of the elegant simplicity and usability of the site.

The goal of the website to emulate a bricks and morter bookstore. Other online  bookstores that have attempted this went for a 3D virtual reality approach. Zoomii took a different approach. Instead there is a large zoomable image of all books in the store arranged into sections and bookshelves.

You can easily zoom in and out and pan around. Of course, you can do the normal search and checkout stuff but it is the simple metaphor that grabs your attention. Since the site was developed by Chris Thiessen, a local software developer in the Waterloo area that I had run into a few times, I decided to call him up for lunch and find out how he built Zoomii.

Chris has a simple vision: to reproduce the bookstore experience with an online bookstore. And he chose a simple business model; namely a referral fee through the Amazon affiliate program. Next is the interesting part: Chris built the entire site single-handedly using Java, JavaScript and the Amazon Web Services stack. And the result is a revenue generating site with a compelling user experience. Despite rendering over 20,000 titles the site is responsive and smooth.

Now what did I get out my experiences with Zoomii and my lunch with Chris?

  • Smaller teams are better. Now, Chris is an exceptional developer, extremely disciplined and stubborn and and a team size of 1 would not work for developers lacking these attributes.
  • Choose your technologies carefully. Chris selected Amazon Web Services but everything else was built in-house using Java and JavaScript.
  • Above all, focus on simplicity. Chris had a simple vision, a simple business model and was able to deliver a simple but powerful user experience.

Truthfulness on Software Teams

A short while back I invited Mishkin Berteig to come to Waterloo to talk about agility. I was looking for something that would have a broad appeal to developers, testers and so on but would also have depth. Mishkin drew a full house and gave a great presentation on delivering successful agile projects. He covered the agile bases with a good overview of agile values and practices. Things got deeper and more interesting when he talked about truth. I know he is sincere about this because of the Scrum Master training I received from him. Mishkin’s email signature is:

“Truthfulness is the foundation of all human virtues” – Baha’u’llah

Mishkin pointed out that agile methods rely on people speaking the truth and acting with integrity. I thought this was very insightful since most agilists focus on either technical aspects of agility such as TDD, refactoring or they focus on team and leadership issues. But what Mishkin is talking about is a deep personal honesty to see things how they really are and to act accordingly.

You see, I have from time to time in my career told little white lies to my peers and managers. And I almost always got away with it. For example, once when I was developing a financial application I made what I thought was a good design decision but really struggled to get it to work. I did not want to appear as if I had made a mistake. I basically lead everyone to believe all was well and meanwhile I worked insane hours to get it all working. I was letting pride get in my way and was lying to cover up a bad technical decision. And this lack of truthfulness prevented me from seeking help. I resented the long hours I had to put in and I was unhappy. It was unfair of me to hide the reality from my peers and managers. I suspect I am not alone.

Now, I think it should be obvious that on an agile team you simply could not get away with such behavior for any length of time. There is collective code ownership, daily stand-ups, task and story tracking, sustainable pace; all of which make the whole process much more transparent. So, on the one hand I agree with Mishkin that agile methods rely on people speaking and acting truthfully. But in practice agile methods make it hard to say anything but the truth!

But we are devious creatures and so I would like to leave you with some questions to ponder:

Developer with halo

  • Are you honestly expressing your doubts and concerns in retrospectives?
  • If something is bothering you with another member of the team do you act in a direct but respectful way to resolve it?
  • Are you able to freely admit when someone has a better idea or design than yours?
  • Are you willing to admit when you make a mistake?
  • Do you say the same things about someone when you are face-to-face with them to do you say something different behind their back?

If you can’t honestly answer yes to the above questions then maybe you’re not as honest as you should be. Start by being honest with yourself. Pick one apsect of your behavior that that is not as truthful as you would like and strive to be more truthful.

Truthfulness really is the foundation of all human virtues … and agile teams.

Agile Coaching and Leadership Retreat

The need for a more enlightened leadership style was drilled home to me at one client’s site. I was continually frustrated when brainstorm sessions and meeting that I planned were complete failures. I had a hard time getting the team to come out of their cubicles let alone participate in retrospectives. At the peak of my frustration the team was profiled using Myers-Briggs personality typing. I was typed as an extrovert and every other person on the team was typed as an introvert. Well no wonder I was getting nowhere, I was trying to get the team to work like I did, as an extrovert rather than adapting to how they wanted to work. So, I made a real effort to prepare information ahead of meetings so the team had time to reflect, used more democratic techniques for retrospectives and so on. The result was a much improved team interaction. I realized then that effective agile teams require enlightened coaching and leadership to steer the team through challenges like this.

When I ran into Deb Hartman at AgileCoachCamp it was clear that her focus is very much on coaching and leadership for agile teams. I find this refreshing because there is a lot of focus on the technical aspects of agile such as TDD, refactoring, continuous integration and so on. I sometimes feel this “software” side of agility gets short shrift. She ran some great workshops on effective listening, powerful questions and agile games.

Now Deb has put together an agile coaching and leadership retreat with Michael Spayd and Lyssa Adkins:

Co-Active Coaching Fundamentals for Agile Leaders is designed to provide Agile Coaches with fundamental professional coaching skills. Based on the “Co-Active Coaching Fundamentals” course of The Coaches Training Institute, it is taught through participation, using practical skills you can apply right away,and offers extensive opportunities to coach and to receive feedback on your own coaching.

In particular, you will learn to:
   •   Use the four cornerstones of Co-Active Coaching
   •   Communicate with clients using the 5 contexts of Co-Active Coaching
   •   Use the Professional Wheel of Life assessment tool with clients
   •   Distinguish and use the three levels of listening
   •   Demonstrate the most often used coaching skills

The retreat is planned for August 1-3, 2008 in Toronto to accommodate agile coaches and leaders planning to attend Agile2008. Learn more at

FitNesse with Finesse

I like to make agile training as realistic as possible by having the team build working software in a realistic agile setting. So I like to use the game of TicTacToe because everyone knows how to play it and the team can quickly be productive in building and enhancing it.

It recently occurred to me that the requirements for TicTacToe could be readily explained through tables. It seemed very natural to use Fit/FitNesse as the vehicle to describe the game functionality. As a result I wrote some Fit fixtures and FitNesse pages to describe the TicTacToe game for my most recent training session.

And I think it worked out rather well …

Fit & FitNessse Background

Fit is a tool for enhancing communication and collaboration on agile teams. It does this by describing how the software should work through examples written in tables. There are many different types of tables which are backed by “fixtures” which serve as a bridge between the tables and underlying production code. Fixtures are quite easy to write.

FitNesse is a Wiki front-end for Fit providing an easy way to write, manage and execute Fit tests.

The diagram below shows a high level architecture for Fit and FitNesse:

Fit FitNesse Architecture

TicTacToe FitNesse

The page below describes the winning combinations for TicTacToe as described in FitNesse:

Winning Combinations

Grey cells are inputs or descriptive text and the green cells are passed assertions. Failed assertions would be shown in red and any exceptions would show up as yellow. The Fit engine uses reflection to instantiate fixtures which then act as a bridge between the Fit tables and the production code. Fit handles all the table parsing

So What?

I find Fit to be a great way to express and radiate business intent. When I look at the above page it is easy for me to understand what the winning combinations are and the green cells let me know that the software understands too. Perhaps the “Turn” row which indicates whose turn it is shouldn’t be there so I should remove it. But other than that, the above does a great job of describing the winning combinations.

Fit story tests are a primarily a great collaboration tool between your product owner and the rest of the team. Ron Jeffries talks about the the 3 C’s of a story: card, conversation and confirmation. Fit story tests are the confirmation. The product owner and the team can collaborate and clearly define what “done” means for a story. This focuses the team on getting story tests to pass and helps avoid scope creep and getting side-tracked with other distractions.

Another benefit of Fit story tests is that they help drive ubiquitous language. The terms used in the story tests should be domain terms that are used consistently through the Fit fixtures and on into the production code. The need to express working examples in the constrained language required by Fit and the underlying fixtures requires the team to think carefully and consistently about the terms they use. I would expect the TicTacToe production code to have classes named “cell”, “mark”, “player” and so on.

What makes Fit even more powerful is that story tests can be run individually or as a suite. Tests can be run from build tools like Ant and NAnt and from continuous integration tools like CruiseControl and CruiseControl.Net. In other words, you can build up a regression suite of story tests and run them many times a day.

What Next?

If you have tried Fit or FitNesse I would be interested in hearing how it worked or did not work for you.

If you haven’t either one why not take them for a test drive? No doubt about there are challenges setting it up and getting it part of the team’s culture … hmmm sounds like a good idea for another blog post ….


Web 2.0 and Agility – Brothers in Arms?

I recently attended AgileCoachCamp and convened a discussion on whether Agile values, principles and practices would be applicable to Web 2.0 projects. Being relatively new to Web 2.0 from a developer perspective I suspected that the answer would be something like “Duh, of course Declan!” But I was really interested in exploring this intersection and I was not disappointed…

Mark Scrimshire led the discussions by suggesting we adopt Tim O’Reilly’s Web 2.0 definition. We summarized it with:

  • Harness collective intelligence
  • Web as a platform
  • Data (it’s all about the data)
  • End of the release cycle (i.e. continuous release)
  • Lightweight programming and business models
  • Software above a single device
  • Rich user experience

And Mike threw in his own equation …

Web 2.0 = (You + Me) to the power of Us

Responding to Change

It turns our that Flickr updates its web site software as frequently as every 30 minutes. They release to a limited audience and collect feedback. They use these metrics to determine whether to roll out the changes to a wider audience.

I know a lot of agile teams struggle with getting timely end-user feed because of organizational and technical obstacles. Web 2.0 uses the web itself to amplify end-user feedback.

Test Driven Development

I have always thought that the core agile practice is TDD so I was interested if Web 2.0 technologies posed any unique TDD challenges. There are certainly Web 2.0 technologies out there such as rSpec for Ruby and various xUnit frameworks. Seems like there could be a weak spot with some of the RIA products such as Flex and AIR although there is TDD support for Silverlight. And the architectural separation of data in REST interfaces seem to makes REST applications inherently testable by mocking out REST interfaces.

So Web 2.0 seems to provide a suitable platform for test driven development. I wonder how prevalent TDD is in Web 2.0?

Hacking vs Sustainability

One miconception I constantly run up against is that agility is a licence to hack. It is hard to appreciate the discipline that is required to honestly do agile development until you try it. And early in a project it is often faster and easier to hack something together. But you pay for this many times over as the technical debt accumulates and cost of change rises and rises.

It seems that time-to-market pressure and rapid technological change might push companies to make rash decisions that impact their longer term sustainability.

Brothers in Arms

The panel seemed to agree that agility is tailor made for Web 2.0 projects. They truly can be brothers in arms.

I have a nagging fear that some in the Web 2.0 space regard agile practices as being too much process? If true, the irony would be truly breath-taking!

This is a topic which I will dig into deeper – I will be working with a Web 2.0 startup in the next few weeks and hope to learn much more …

Taking Stock of Your Software Inventory

Do you have inventory piling up between your development team and QA?

This inventory of unconfirmed functionality limits your team’s agility on a few fronts:

  • your software is not always potentially shippable
  • deferred ROI
  • delayed feedback from QA

One of the main goals of your agile team is to build potentially shippable releases every iteration. When QA testing is done after development releases your team can no longer achieve this goal.

This deferred testing also creates an inventory of unconfirmed features that need to be managed. And just like any manufacturing system, inventory is wasteful and costs your company time and money. Every day that your software is not shipped decreases the ROI.

The longer your software remains untested the more costly any corrective action becomes. The cost arises from many factors including the ramp-up time for the developers, context-switching time, overhead with issue tracking and so on.

Finally, feedback from good testers is invaluable. They think differently from developers and tend to have a more outward-looking customer perspective. If you get this feedback earlier in the process you will see a reduction in defects and less rework.

If you find your team in this situation here are a few things you could might consider doing:

Track Metrics

Select metrics such as defect counts or time to close that you feel best highlights the obstacles your team faces. Chart these metrics in big visible charts

Consider translating technical metrics into bottom-line financial data. For example, you could use daily expected revenue of the product to calculate the revenue loss due to each day of delay.

Get Developers and Testers Working Together

There has been much talk about getting quality assurance infused throughout the product cycle. Agile teams are tailor-made for this transition. Get a tester on your team and allow her to contribute throughout the iterationAside from traditional testing, the tester can bullet-proof the story tests, suggest testing tasks, pair with developers on testing and so on

This inter-personal contact will do more to promote quality within your team than any formal QA process ever will.

Stagger Iteration Testing

Staggered testing

If you must maintain a separate system test phase, consider having the QA team test the previous iterations release. This way, the QA team has a stable release for testing and feedback is delayed at most one iteration

Over time, you may be able to move additional QA activities into the development iteration.

Is Software Development Just a Game?

Agile Software Development: The Cooperative GameI am reading Alistair Cockburn’s book Agile Software Development: The Cooperative Game 2nd Edition.

I definitely buy into the game analogy – it provides an opportunity for deeper insight than the more traditional analogies to engineering processes, house building and the like. Alistair settles on rock climbing as his choice of good analogy. But for me, a team sport like soccer, hockey or basketball hits closer to home.

One thing I have to say right off the bat is that the word “game” as an analogy bugs me. The name suggests a lack of seriousness. It reminds me of how the writers of the agile manifesto selected “agile” rather than “light weight” (See pp 382-383). I think we need to play the name game and come up with a more serious name than game.

Alistair suggests that software development is a goal seeking, finite, cooperative game. Let’s deconstruct this with a team sport analogy:

Goal seeking:  A team sport always has the ultimate goal – to win. But the analogy is stronger. Teams can have other objectives like improving our rebounding, winning the next quarter, making the playoffs and so on. Good software teams should similar objectives like improving our test coverage, completing all the stories in the next iteration, and getting out a functional release by the end of the quarter. Notice how all these objectives can be SMART.  

Finite:  Almost all team sports have well defined limits including playing conditions, duration, team size and so on. Except possibly for cricket which still baffles me.

Cooperative:  Winning teams require personal inter-dependence. You need to trust your teammates and be able to count on them. When I think of really great team players like Sidney Crosby or Steve Nash what amazes me is their total awareness of where everyone is and where they are going.

But the main reason I like a sports team analogy is that you can quickly use it to point out the futility of detailed plan-driven software projects.

Stanley CupImagine you are a coach setting out to win game 7 of the Stanley Cup finals and planning each line change, each play, every face-off, fight and so on in advance. I think you would be having some lonely summer rounds of golf. As a winning coach you would make sure every player embraces the strategy that you feel can win. You count on the training, experience, skill and judgment of your team to adapt to whatever the other team throws at you.