Is agile easy or hard, simple or complicated?

I’m giving a lightning talk Wednesday, 11.feb, on SW2009, Oslo. It’s on a day-track called “Future development processes in a post-agile world (Effective software development)”. What’s your thoughts about that title? Clever? Needed? Provoking? Sad? Happy?

My thought? – Are we even agile yet? I think we’re far away from post-agile, but it’s probably good for us to discuss the subject.

Anyways, my lightning talk title is “You have yet to have success with an agile project” (Du har til gode å ha suksess med gjennomføringen av et smidig prosjekt). Switch You with I and it’s partly true as well, because how do we measure success? Well, that’s a whole other discussion, all I know is that I felt we had a potential to do much better, given the resources and information available at the time.

The objective of my lightning talk is to affect the attitude I feel many people have towards agile. So, is agile easy or hard, simple or complicated?

Most agilists would claim “Agile is simple!”. Maybe they’re right, but herein lies the problem, I think. When we sell simple to the customer (and the developers for that sake!), we risk that he’ll take too lightly on the process. Perhaps key elements are forgotten or simply ignored? The customer plays a big part in both waterfall and agile, but in agile his role is very different. We need the customer (product owner) on-site, continuously providing feedback and steer the project in the desired direction according to the newer information obtained. Sounds feasible, and easy, but this person needs both domain knowledge and the executive rights to guide the projects. Who can spare such a vital person to a development project? It would certainly be an easier decision if the customer new the project would fail dramatically if not.

So, from now on, sell “Agile is hard, but you get the better product”. Then, maybe, agile will become easy

The only good branch is a dead branch

edit: so kill them fast

Smidig2008 – smidig gjennomført

Smidig2008 was a conference about agile methodolog, as was Smidig2007. I participated in organizing them both and we repeated our success from last year, expanding from 300 to 450 participants. I’ll continue this in norwegian as this is the language spoken at the conference.

Smidig2008 gikk av stabelen 9. og 10. oktober i Oslo Kongresshus. Vi hadde lært masse fra fjoråret, og bytte av lokale samt bedre registreringsprosedyrer bidro til en smertefri gjennomføring. Foilene ligger nå ute! Senere kommer også videoene. Jeg skriver her litt om konferansen generelt og mine opplevelser.

Bamboo, sound, X10 and lamp control script

Code is included in this post! I’ve written a small ruby script for polling a bamboo server for (multiple) build results, playing sounds for success and failure. It even controls lava lamps connected to a AM12 power outlet through a CM11 controller using the X10 protocol. You may get these at framtidshuset. To send the signals through your serial port(yeah, I know! serial port) to your CM11 controller, you need a program that takes arguments like this ‘command A1 on’, where A1 is the lamp/AM12 code and ‘on’ is the opposite of ‘off’ I use windows and ActiveHome’s (HomeControl) x10com32.exe (ships with the CM11 if bought from Framtidshuset), and on Linux you would use the free ‘heyu’ program. I’ve used heyu before and promise you it works.

Bamboo must have the Rest API enabled, a property setting you find somewhere in the bamboo settings.

Tests deployed, viewable and runnable for end-users?

My god, eclipse have they’re tests publicly available for you and me to view, and run!

I stumbled across this blog in a hopeless hunt for good articles about FitNesse, test data exhaustion -duplication, -hard-coding and other dreadful things.

Yes, eclipse foundation has executable tests in production. You may view the testflow (and workflow) in the swim framework. Swim impresses me (see eclipse swim pdf). Seems a bit crazy at first, but they’ve got to be doing something right in their testing (and test process) when they can have such automatic tests running in production . See the test result for eclipses election of committers and be stunned!

I’m not the only one curios about this. Repeated, here’s the blog post that I stumbled upon, here

Hope I get to try it, things always tend to look better than they are…

Sharing My Burndown and Burnup Excel Sheet

In this article, you’ll find links to download my burn down/up graphs as xls-sheets also containing formulas for analysis of a given iteration/sprint. It’s been developed in an agile matter, continuously adding new features and improvements as the feature requests and demands arrived.

Summary of a summary on Great Teams

Mike Polen has made a good summary of an hour talk of James Shore on what separates the great teams from the average agile teams.

Note, I recommend listen to James Shores’ own talk. He’s pointed out to me and commented here that there are many misunderstandings. In addition, I both recommend an RSS feed to his blog and reading the book The Art of Agile Development he’s co-editing. However, I will leave the list be (the cause of the “troubles”). It’s up to the reader to reflect on what’s put in it. You try and fail, reflect and learn. There are no universal rule of what a Great Team is, or how to form one, we should all know that by now! See this article on cargo cult agile if you feel like taking the list for a fact.

Summary of the summary (I claim my rights to misunderstand his potential misunderstandings):

Great teams they :

• take time to become great (many months). “Forming-storming-norming-performing”
• sit together. They adapt more of the XP values, especially pair programming. Scrum values as self-organizing teams should also be adapted.
• have no long lived code branches
• focus on preventing defects through TDD and refactoring the code to its intended simplicity.
• deliver features that are truly done, that is, “Done-Done”.
• get real-time feedback on features and priorities.
• avoid technical stories (taking time off to refactor).
• need someone who is passionate about quality and pays attention. This person doesn’t need to be senior but needs courage to speak up when things are going wrong.
• uses agile engineering practices as TDD, continuous design, rigor & mindfulness.
• don’t require A-team members, ordinary people makes great teams with agile engineering.
• deliver often (daily/weekly), short feedback cycles.

maybe…

Note to self: Don’t try more summaries on summaries.

Agile Conference Smidig2007 a Success

It’s been a time since my last writing. I know it’s a bad excuse, but I’ve had so much to do. I got hired for a project from end of September (still there) and I’ve been very busy preparing the Smidig2007 conference.

Smidig is Norwegian for agile. It went really well, I learned a lot and had lots of fun. It was held 27. and 28. November and had over 20 equally aligned sponsors, 260 participants, 86 lightning talks and a 100 open space groups. We wanted to profile the conference as a community of the agile movement of Norway. We were 13 people behind it and really appreciated all the enthusiasm, skepticism and reflections made by the highly active participants.

I had a lightning talk myself “Synlighet – Bidrar til økt produktivitet, fokus og motivasjon i team og prosjekt” (Visibility – Leads to increased productivity, focus and motivation in the team) which is all about all the visual elements one may introduce in a Agile/Scrum/XP environment. Such as Scrum-board, waste snake, retrospectives, post-its with color codes etc. I showed lots of pictures. You may find it here http://smidig.no/smidig2007/talks

I’ve been asked to do the lightning talk at SW2008 in February as well. I’m flattered and looking forward to meet yet another group of enthusiastic IT people.

Methodology blindess

If you’re not yet using agile methodologies and TDD, please please do, it’s really the way to go. To those of you who does, don’t hide behind it. Don’t get methodology blind!

Please stop confusing «do the simplest thing that could possibly work» with doing the fastest thing you can do. For heavens sake, the idea is not to stop using your wits, au contraire! For more, it’s a tool to avoid overdesigning and eliminate «what if I later on need this functionality?»-programming. You and me have wasted too many hours doing that.

My message? Always ask yourself why? you’re doing what you’re doing. Reflect and improve. To me, that’s agile. What’s your opinion?