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

Eclipse keyboard shortcuts or shortkeys

I’m not gonna excuse my shortkeys. Or did I just do that? Here are some Eclipse shortcuts that I use regularily and some that I keep forgetting as don’t use them…

Stars	Shortkey	Function and Description
¤¤¤	ctrl+1	Suggest Fix (TDD tool)
¤	ctrl + shift + i	Inspect
¤	alt + ↑ ↓	Move selected lines up or down
¤	alt + shift + L	Extract local variable
¤	alt + shift + M	Extract method
	alt + shift + X, t	Run as test
¤	alt + (shift +) k	Find next match of marked text in file, up/down.
¤¤	ctrl + (shift +) 7	Comment/uncomment
¤	ctrl +d	Delete line
	ctrl + o	Outline
¤	ctrl + (shift+) T	Open Type
¤	ctrl + shift + R	Open Resource
¤	ctrl + shift + G	Find all references
¤	ctrl + shift + O	Organize imports
¤	ctrl + shift + F	Format
	(ctrl +) F11	Run or debug last test
	ctrl + shift + Y/X	UPPERCASE or lowercase marked text
New!	ctrl + shift + L	List all shortcuts. Find your own!

Now you propably now more than I… Please inform me of my lackings!

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.

Birth Date with Jaxb and XMLGregorianCalendar

Lots of googling and frustrated colleagues and no solution to represent a simple birth date without minutes and seconds. In short, jaxb always uses XMLGregorianCalendar to represent dates, how to represent the birth date as
1980-01-01
instead of
1980-01-01T00:00:00.000+01:00

Fødselsdato fra fødselsnummer

Til min store frustrasjon, fant jeg ikke noen kode på nettet som dro ut fødselsdatoen fra et fødselsnummer. Det er verre enn det høres ut, med 18., 19. og 20. århundre, D-numre og H-numre. Men jeg fant denne siden http://no.wikipedia.org/wiki/F%C3%B8dselsnummer (http://no.wikipedia.org/wiki/Personnummer).

Dette er offentlig informasjon og må da være brukt av mange, tenker jeg, men den gang ei. Nå, da jeg har implementert det, skjønner jeg forsåvidt at det ikke er publisert, det er jo bare noen få if-setninger! Men med min frustrasjon friskt i minne, publiserer jeg, sammen med en rekke enhetstester for corner-caser. Om jeg har gjort noe feil, vil jeg gjerne vite det!

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.