Dusting off Rework
My current contract ends in a few more days so I'm taking the opportunity to dust off my worn copy of Rework by 37 signals. I have to make a long overdue thanks to Craig Davidson, an outstanding agile developer I encountered in a previous engagement.
It's not a traditional agile book by any means, but the facts that are presented within the book resonate strongly with my agile values and I find it has helped me immensely to keep grounding myself between contracts. I am now constantly surprised just how many paper-cuts I have personally accepted at each engagement and am equally surprised at my own personal level of intolerance now. I'm actually thinking of requesting a discount from the authors since I now use this book as a gift I give almost routinely...
I challenge anyone not to find the book invaluable at challenging their own current view of the world.
So, once more, and I must apologise profusely for the tardiness, thank you so much Craig...
Concordion Plus
I've written in the past about Using English to write Acceptance Tests and the tool I choose/advocate is without doubt Concordion. Customers love seeing their stories come alive, but I've found developers can sometimes struggle to differentiate these from JUnit tests, particularly since JUnit is used to provide the execution mechanism.
I've also found that in many of the situations/organisations where I have introduced Concordion, a single story has required several tests and although the Concordion guide does present some excellent techniques to deal with this, teams new to writing acceptance tests will be uncomfortable capturing stories in this format and customers might not be happy that all their acceptance criteria are being met. I am therefore pleased to be releasing Concordion+ to the wild. At the moment it is a simple extension to Concordion which allows developers to create individual scenarios (or test cases) within a single story and also to ignore the scenarios they are actively working on. In addition, a new JUnit runner captures the state of each of these scenarios independently and reports them in the common IDEs while also allowing developers to use the JUnit @Before and @After annotations. This should simplify adoption by developers since they now have a JUnit lifecycle they understand.
I have to send a huge thank you to Nigel Charman for the concordion-extensions project which helped immensely with my development. And of course I can't dare not mention the excellent work by David Peterson on Concordion itself and particularly the facility to write extensions 😉
I hope you enjoy using it as much as I enjoyed creating it...
Could Agile Have Evolved?
DNA
I've been researching material to support an article on my company blog entitled "Agile Dictators" and it left me thinking about how Agile started in the first place.
The more I reflect on this, the more I am left feeling that Agile is actually a mutation in software development and this is one of the major reasons why Agile is so difficult to master. I'm wondering whether agile would ever naturally evolve in a small team left to their own devices and I simply can't envisage it. Of course, this will now remain an academic hypothesis since Agile has now stamped it's influence indelibly on the DNA of software development.
Software development as a craft suffers from unnecessary complexity and I fear that Agile, which initially thrived in simplifying (or removing) this complexity, is now becoming itself encompassed in unnecessary complexity. Despite agreeing with much of the sentiment of the software craftmanship manifesto I just can't bring myself to sign up to it yet. I struggle to see the benefit of more fuzzy aspirational statements and would prefer to see a clarity of vision and roadmap to achieving it.
Fundamentally Agile is fantastic, but sadly the passionate discussions, raging debates and conflicting methodologies don't clarify anything. If Agile doesn't clearly define itself soon I fear yet another mutation may take centre stage and Agile will end up being just a blip (albeit a very significant blip, where we gained sight) in the evolution of software development.
Information Overload
The internet has now pervaded my life to such an extent I'm going to soon be looking to get a direct connection to my brain. But before I do, I'm in desperate need for a way to organise the constant, chaotic stream of information that is radiating from it...
Here's my list of basic requirements.
I want to be able to
- view all messages in a single application, regardless of source (rss, google reader, twitter, etc).
- post messages to any of the applications I use (twitter, blog, facebook, etc)
- Should also be able to post to multiple applications at once
- search and filter the content
- filtered messages, should still be available for future search/display
- use multiple platforms (phone, web, laptop, desktop) with them all kept in sync
- specify multiple ways of notifying me if anything relevant appears
- particularly important for mobile platforms
- switch between different modes (professional, private, meeting)
But MOST IMPORTANTLY
I DO NOT WANT TO:
- create YABA (yet another b****y account) to use yet another free online tool
- wait for hours while it downloads everything before I can view a single message
If anyone knows of such a tool, I'll be extremely happy to hear about it...
Emotional Agile – Weather Poker
Ever since I attended a session by Rachel Davies on Project Mapping at SPA 2005 I have been interested in simple ways to use emotions to engage teams. On a recent gig for exoftware I introduced weather poker at the end of the daily stand-ups as a way to measure the feelings of the team.
Weather Symbols from edupics
In essence, each member of the team was given cards with weather symbols ranging from thunder to sunny. We would then take a vote on what yesterday felt like and average out the results. A larger image was then made highly visible on our information radiator for all to see. Despite this being a small experiment, it did look like this was a very quick and effective way to allow the team to express how they were feeling. Indeed, the one day when the team decided to display the thunder symbol lead to an intense interest from the on-site customer.
If you would like to try this in your team, I have attached a pdf with the cards ready to print and laminate.
PDF: weather-poker