Latest Updates: Agile RSS

  • With design agility must come design ability

    Duncan 5:00 pm on 13th July, 2010 | 2 Permalink | Reply
    Tags: Agile, , ,

    Why Agile UX is Meaningless without an Agile Attitude

    This is an interesting post by Anders Ramsay.

    I definitely think design agility is an important skill, I think it goes without saying that if you do not have agility then you are not agile, but I also think that design ability is also just as important for agile teams.

    Sometimes when we need to produce ‘presentable’ wireframes to show a client complex interactions in an animatic we’ll spend some time polishing them up; but lately we have just been scanning in rough sketches. It makes it much more obviously ‘unfinished’ and definitely leads to looser design discussions.

    Often when we need to resolve design issues that come-up ‘in sprint’ we will have a quick chat with the team and produce a 10 second sketch to facilitate the design solution, job done. This is design agility to me. It does depend on the development team having at least some design ability though – luckily at Caplin our devs are all cool techreatives at heart.

    (More …)

     

  • SPA2010 conference redux

    Duncan 1:49 pm on 4th June, 2010 | 0 Permalink | Reply
    Tags: Agile, ,

    SPA2010

    I missed the start of SPA2010 on Sunday, I knew it was going to be a heavy week and I needed some time for the family :) Sorry Phil/Adam.

    Monday started with the opening plenary, I think it was good, I’m sure it was… it’s just that I was a bit distracted thinking about our impending workshop – would it work out?

    (More …)

     

  • The beauty of small tests

    Andrew Darnell 12:53 pm on 15th April, 2010 | 0 Permalink | Reply
    Tags: Agile, , , , ,

    When tests are small, a test failure means just one thing – somewhere in these ten lines of code which are being tested, there is an error.  Ok, sometimes this can mean that there is an error in the test script, or a there is a failure, or change of expectation, but fundamentally, it pin-points the cause of the failure to a small target, which usually means that debugging becomes trivial.

    When an end to end acceptance test fails, the failure could be due to any one of a large number of source lines or expectations changes across a large body of code.  Debugging may be quick, but often isn’t.

    (More …)

     

  • Agile – Tests = Fragile

    Andrew Darnell 3:55 pm on 9th April, 2010 | 0 Permalink | Reply
    Tags: Agile, , , , ,

    The nature of agile projects, with lots of small releases mean that there are a lot of test runs to execute if you want to have any confidence in the code and the product.

    Ignoring this testing just generates projects which will fail – not may fail – will fail, categorically will fail!

    There are two sets of tests that are critical here…

    Good unit test coverage and a TDD approach to development ensure that the rest of the organisation is supplied with product that works as developers expect it to.

    Component tests and functional acceptance tests ensure that the product does what the product owner expects it to.

    • Practically, the only way to do solid testing on new features is to have a stable product.
    • Practically, the only way to assure a stable product is to either have solid regression testing on each release or to not make any changes.
    • Practically, the only way to make sure that adequate regression testing is done is to automate the regression tests (unit, component, functional).

    Without these tests in place, iterating quickly places an impossible to meet burden of verification demand on the testers and product owners, which just gives you a fragile process not an agile one.

    Is your process Agile or Fragile?

     

  • Agile Software Development – One Size Doesn’t Fit All

    Ian Alderson 12:01 am on 2nd April, 2010 | 2 Permalink | Reply
    Tags: Agile, , ,

    As I mentioned in part I of this series, Adoption of Agile at Caplin, when we first started following an agile methodology (in our case Scrum) in February 2005 we were desperate to implement it successfully and wanted to adhere to all of the best practices.

    We persevered with this approach for several months, repeatedly referring to the books on Scrum we had purchased and the numerous websites on the subject which were cropping up at the time, to find out ways of improving the process.

    With hindsight this looks a little conservative, however back then we were still getting to grips with agile and didn’t want to make any significant adjustments that hadn’t been tried and proven elsewhere.

    (More …)

     

  • Agile Software Development - Adoption of Agile at Caplin

    Ian Alderson 3:55 pm on 26th March, 2010 | 0 Permalink | Reply
    Tags: Agile, ,

    Back in January 2005 I had been married for a month and was looking forward to taking a belated honeymoon in March. As you would expect, these were significant life events, however little did I realise that something of a similar magnitude was also looming on the horizon of my work life here at Caplin. After five and a half years following a waterfall methodology our then development manager (now CTO), Patrick Myles, introduced us to our first agile software development methodology, Scrum.

    Over the last five years we have learnt that an agile process is agile itself, and the process that we follow now is different in many ways from that which we initially adopted. This doesn’t mean that the process we first had was wrong, although there were certainly some issues. Over time things that were crucial parts of the process have become defunct and have been removed, whilst new ideas and refinements are added into the process to address fresh issues that have arisen.

    (More …)

     

  • Imprecise Accuracy is better than Precise Inaccuracy

    Ian Alderson 2:53 pm on 5th March, 2010 | 0 Permalink | Reply
    Tags: Agile,

    Last week I blogged about how an estimate is not a guarantee. A small, but important, omission from that post was the distinction between an accurate estimate and a precise estimate.

    Frequently accuracy and precision seem to be considered the same thing. The critical difference was highlighted when I went on an agile course run by Mike Cohn. He demonstrated the difference by asking the question of when your birthday was?

    (More …)

     

  • An Estimate is not a Guarantee

    Ian Alderson 12:57 pm on 26th February, 2010 | 0 Permalink | Reply
    Tags: Agile, , ,

    The statement that an estimate is not a guarantee might sound obvious but it often feels anything but. Over the years I have frequently heard managers complain that something has taken longer than was anticipated and have been told to improve the estimates.

    Of course at times the estimates have been inaccurate, with features taking far more time to implement than was initially predicted. The question is how to learn from these experiences to help improve your estimates. This is especially pertinent for software engineers within financial services because this same conundrum is at the heart of pricing financial instruments.

    This article looks at how the Rational Expectations Theory can help you improve your estimates in software development. It starts by looking at estimating something much easier than a software enhancement, your journey time into work, and demonstrates when that estimate should be considered good or bad. It then looks how this can be applied to software development.

    (More …)

     

  • Designing a kanban board - not as simple as you might think

    Adam Shone 2:33 pm on 16th February, 2010 | 7 Permalink | Reply
    Tags: Agile,

    Last month Emin Tatosian posted an article about agile team-board layouts in which he showcases one of our more successful board designs. It’s fair to say that we don’t always get it right first time, so I thought I’d share an example of a layout that seemed to be a good idea at first but turned out to be badly flawed.

    (More …)

     

  • Agile Framework Development

    Ian Alderson 12:58 pm on 2nd February, 2010 | 0 Permalink | Reply
    Tags: Agile, , , ,

    At times it seems that the philosophy of agile software development is at odds with that of framework development. Given the amount of print and web space dedicated to agile methodologies, it’s incredible how little is dedicated to this topic. It’s almost as if this conflict needs to be kept hidden away from view, not to be discussed in public.

    At Caplin we are living proof that framework development can be achieved following agile principles. We have been successfully building frameworks and APIs for the past 5 years using various agile methodologies from Scrum, to a mix of Scrum and XP, to Kanban.

    This article represents the approaches that we have undertaken to successfully build our frameworks.

    (More …)

    Related Posts with Thumbnails
     

Older Posts →