Agile software development using Kanban & Scrum. We code Flex & Ruby on Rails in Auckland, New Zealand.

  • Viewing all posts tagged "Agile"

  • Ascending the Ivory Tower is good for everyone.

    I attended the Flash And The City conference last week. It was an amazing experience and I met some of my personal Heroes. People who make the effort to popularise good software, good design, good tools, and good practices.

    Sometimes I don’t see eye to eye with them, but I still respect anyone who puts themselves out there to be criticised so willingly :)

    Funnily, a term started re-appearing that I haven’t had applied to my opinions (or the opinions of those I hold in highest regard) in a long while:

    Ivory Tower

    Ivory Tower connotes a place that’s unattainable. It’s being used regularly in the pejorative when discussing best practices for business, development teams and coding standards.

    Now when I started using Object Oriented concepts like message passing, way back in the day, with Flash 4 and Flash 5, the same Ivory-Tower term was often bandied about by hackers and traditional linear programmers. It was often purported that things like Message Passing, Encapsulation and Polymorphism were too hard to understand and ill-suited to the day to day Flash developers’ work.

    In 2000 I presented at the Sydney FlashKit Conference in an attempt to promote Flash as an RIA platform, all we needed was better coding practices. It was an uphill battle, I was asking people to climb an “Ivory Tower”. I was by no means a purist. I still don’t think I’m a purist.

    So I will mix the Ivory Tower metaphor with the climb Mt Everest Metaphor somewhat from here. I think there is a surmountable slope to lofty standards of Agile and Best Practices.

    Purists

    A purist is someone who attains the summit and pretends they’ve never had to do a day of climbing in their life. A purist wonders, condescendingly, how you could possibly do things any other way. A purist doesn’t care for outside pressures. This kind of elitism can only be found in people who aren’t pressured into making pragmatic choices.

    Pragmatism

    Pragmatism does not mean “embrace the status-quo”. It means when achieving your goals, you recognise the path to attain them and the alternatives, especially the alternatives that bring everyone else to the summit. You will chose alternatives that let you reach important waypoints during your ascent.

    Pragmatism can be applied to your singular ascent, your current team’s ascent, and everyone else’s ascent.

    Our experiences

    2 Years ago we set out to become an Agile development team that:

    • Had continuous integration
    • Automated, repeatable deploys
    • Encapsulated documentation (Knowledge stored in the same place it needed to be applied)
    • Automated Test and Behaviour driven development
    • Automated Integration testing
    • Clean consistent code
    • Software with a great user experience
    • Frequent delivery of improvements.

    That was out lofty peak. We’re still not there, however I would say that we are in sight of our first peak. We got this far not by being purists, but by being pragmatists. Once we are upon the summit, we’ll look for something taller I am sure :)

    Micro-architectures

    Micro-architectures and small prescriptions are a fantastic tool for the worthy climber.

    These are both lightweight prescriptions (easy to follow) that have massive impact:

    • Robotlegs gives you the Single Responsibility Concept, Code by Contract, Testable code etc.
    • Kanban gives you focused work-in-process, release-often, faster feedback etc.

    I consider them both important tools for this ascent, others are Hudson CI, FlexUnit, Cucumber and many many more.

    In closing

    So my only argument with some of my heroes who proclaim “Ivory Tower” is:

    “It’s not healthy to denigrate these attainable best practices”.

    With the greatest respect, I ask that we speak instead in the following terms.

    Find valid, workable stops along the way, and good reasons, not excuses, for stopping short of the summit

    It has a more positive air to it, and it doesn’t devalue the amazing, and often freely given, efforts of the Mountain Climbing Specialists whom I think deserve slightly more respect.

    Hmmm… and those of us who like to think of ourselves as Mountain Climbing Specialists could work harder to be humble. Not to make a stink so often just because someone cut a corner we wouldn’t have.

  • Agile, what it means to us.

    We’re seeing a lot of to-ing and thro-ing about Agile, it’s success and failure. There are a lot of blogs, posts and tweets which let anyone who wants to, throw it away and dismiss it out of hand.

    From our fledgling point of view, the point is being missed.

    To work, Agile must be all about allowing a team to do what it naturally wants to do.

    That’s it in a nutshell. You can’t use Agile to get a team to toe the line. You can only use it to nurture the natural instincts of a team.

    So be very careful about the team you pick. Cultivate a team that will align itself with the business goals, often something like:

    • making money,
    • shortest path to making lots of money
    • doing so sustainably

    The team’s instincts will likely include pride. So your business needs to add to its goals:

    • making product the team can be proud of.

    Then really, Agile is just a matter of trusting people. If your ecosystem cannot support trust, you will probably embrace micromanagement.

    We’re not being cheeky, Agile is not the only way to success or failure. But Agile is our only way.

  • On the benefits of refactoring

    You can’t build an office block and then decide you had better put in some concrete foundations afterwards.

    You can, however build a large scale app and decide you want a different foundation along the way.

    When you start an agile project, you “pitch a tent in dirt”.

    E.g. write a simple app that lets users drag a ‘job’ - which only has a name and id - onto a timeline.

    You then itterate, turning the the tent ever so slowly into the office block ( e.g. vWorkApp ). You get to revisit every aspect, and you must revisit it.

    If you don’t, you’ll have an office block sinking into the mud.