Agile development experiences 26 June 2008
Posted by spacebaboon in agile, do-it, technical, v-base.Tags: agile, confluence, do-it, do-it.org.uk, jira, Planning, project management, scrum, teamcity, v-base
add a comment
I’ve been a developer at YouthNet for over 6 years now, and have written much of the code behind the do-it.org.uk website, as well as our other sites, TheSite.org and youthnet.org.
One of the challenges and opportunities of V-Base 3 is greatly improving and expanding how the V-Base client communicates and interacts with the central database and website. We can send much more data in both directions to make V-Base more interactive with the website and volunteers’ profiles, to allow data sharing, and much more.
So I joined the V-Base 3 team a couple of months ago, to work on this area, and it’s been a very interesting time so far!
One of the things about working on one website for a long time is that the work tends to be small and bitty: change the look and feel of a section, add some new functionality to a profile page, that kind of thing. They normally last a couple of weeks, and will just be me working on it, or one other developer at most.
So to work on a very long term project – by the December release it’ll have been in full time development for over 2 years, and the team has grown to 9 people now. This is a first on anything like this scale for YouthNet, and the team have adopted the Agile methodology, a very modern approach to software development.
So, how does Agile compare to what I’ve done before? Is it the revolutionary improvement some say, or more a fashion statement, as others comment?
Things I like:
communication is important anywhere in development, and more so the bigger the team size and project complexity. This is important in Agile, we make a point of a short meeting every day where everyone says what they’ve done, what they are doing and any problems they’re having. I find this really useful, as I know what everyone else is doing, how their progress is going, and lets everyone else offer ideas to the others’ problems.
we’re using modern web-based project management, code building and information sharing tools:
JIRA for project management, work planning and bug tracking.
Confluence as a Wiki, to store and share all the details of our work. This is such an improvement on a local area network full of MS Word documents!
TeamCity for continuous integration, a central place the code is built and tested, great when several developers are working on the same code base.
Good and flexible working conditions. We’re all hard working, the daily standups mean you can’t get away with sitting in a corner and doing nothing but play Scrabulous for weeks. But one of the Agile tenets is that you work your set hours, and not a minute more. I’ve worked in places where the week or two before a big release, half the team is still there at 10pm every night. A happy, relaxed team is going to work better. We’re also using a VPN and Remote Desktop and IRC to be able to work from home occasionally.
Flat structure, design by meritocracy. We don’t have a complex structure of bosses dictating your every move. Whoever knows something the best can take responsibility and do it.
Iterative development. Rather than working out every detail at the start, building a huge timeline and enbarking on months of coding, the work is split out into short stretches, usually a week or two, where you decide which chunks of work need doing, and then code those. at the end of the iteration, you have a review, to see how it went, and what could be done better next time. while this means more deadlines, they’re not as deadly as when you’ve been at it for 6 months and still have half to do.
Things I don’t like:
There’s a lack of planning and design work at the start, compared to the development I’m used to. The attitude seems to be that you just go and do something, and if it’s wrong, then you refactor it based on the knowledge you gained from it, so your next effort will be closer to what’s needed. While this is a nice way to work, it’s not as effective as taking much more time at the start and getting it right first time, and a lot of time is wasted.
It’s very hard to estimate the time scale of a complex project. When you lay out everything at the start, and work out exactly what has to happen, then you can get an idea of how long it’ll take. but if you just iterate until it’s done, any estimate more than a year ahead seems a stab in the dark. Again, as a developer, it’s nice to work in this way, but it must drive management crazy!
Conclusions:
Despite its name, Agile is much stricter and has more rules than how I’ve been working here previously. You must have stand up meetings every day, you must log all your user stories and progress in JIRA, you must make sure the build compiles with every commit, etc. But this is actually a good thing, they all help, especially in a large team on a long project.
It’s not suitable everywhere, if I go back to the bitty, single-developer work after this, Agile wouldn’t be suitable – the rules and practices would be an unnecessary overhead.
Agile isn’t really anything new, and didn’t come out of nowhere. It’s a collection of sensible and practical ideas that software developers have figured out through experience over the last few decades, brought together and given a name – rebranded, if you like. And as such, it’s very easy to pick up and use. Some of the ideas and technologies I’ve used before, and some are new to me, but they really work well together when working on a big project like V-Base 3. If I work on any large projects after this, I’ll fight to use Agile.
So I’m definitely a fan, if not quite a rabid, flag-waving convert 
V-Base 3 joined by a new member 10 June 2008
Posted by Camille in agile, do-it, v-base.Tags: agile, Planning, tracking
add a comment
You might have read Olivier’s post on the joy of recruiting for a new developer.
Sofia joined and not long after her we had another addition to the team. Although the recruitment process was less difficult, we had to define a list of criteria and go through loads of websites. After eliminating unsuccessful candidates, we eventually set our eyes on this particular …. White Board! … aka The Tasks Board.
The Tasks Board has been part of the team for a couple of iterations now and its role is to offer an overview of the tasks to be undertaken during the iteration and to follow our progress as we’re going through. How does it work?
We divide the board in 5 columns and although cards in column 1 won’t move (so that we can identify in a glance the theme the iteration is going to focus on), the tasks cards will progress from columns 2 to 5.
- Story/Area : each user story / area of work we decide to commit to for this iteration
- Tasks/To do: each user story / area is broken down into all the tasks that need to be done in order for it to be completed. One card is written for each task.
- In progress: once a developer picks a task and starts to work on it, the task card is moved from “To do” to “In progress”
- Verify: once the task is completed by the developer it’s moved to “Verify” in order to be QA’d/ tested. If the test is satisfactory, it goes to the next column, Done, otherwise it goes back to “To do”
- Done: eventually, all the tasks that were in “To do” will end up in “Done” by the end of the iteration.
Tasks Board really is a part of the team as we have to roll it (I forgot to say that the Tasks Board is on wheels) from our main working area to the area we gather in for our daily Stand Up Meetings (SUMs). Occasionally one of us might be not being able to attend the SUM but Tasks Board is always there (annual leave: 0, sicky: 0)
So, what are the benefits of having Task Board on board ???
- Everybody from Developers, to Product Owner, QA person or Tracker can have an idea of what people are talking about when they say what they are doing during the SUM,
- We are working in a more transparent environment as everybody in the office can see what we are up to for an iteration and how we are progressing,
- And most of all there is a huge sense of satisfaction when all (most of) the cards are progressing through the columns to ends up in the “Done” one by the end of the iteration.
Finally, Tasks Board is very versatile and that’s a good thing as you can find one that fits your needs. It can even be an opportunity for some DIY-team building.
For more examples of Tasks Board: http://www.informativeworkspace.org/walls.php
Yoga is not the path to Agility, Planning Poker is 6 March 2008
Posted by Camille in Uncategorized.Tags: agile, estimates, Planning
add a comment
Becoming Agile is not an overnight process. That’s at least one thing that Yogi Masters and Scrum Masters will agree on. Yoga was not the path to Agility for us. Our approach was somewhat more intellectual: learning from our successes and errors and undertaking training.
So here we were, back to the classroom.
I had the chance to attend an“Agile Estimating and Planning” course with Mike Cohn as an instructor. We looked at various approaches to estimating and went through techniques for deriving estimates as well as when and how to re-estimate.
One of these techniques is “Planning Poker” and the rules are very simple: (more…)
Agile Planning 29 February 2008
Posted by Camille in Uncategorized.Tags: agile, Planning
add a comment
Before going further into the arcane art of Agile planning, I think I should explain what my role is. As the project Tracker, I have to measure the team’s progress within and across the iterations (each iteration is 4 weeks long). Using these metrics, I’m working with the Product Owner (Tracey), to refine the release plan she defined.
A release plan is a high level plan that covers 6 to 12 iterations and details the features that will be developed and released within that time frame.
My role is to calculate how much we’ve done within the past iterations, then taking into account the resources we have available, try to define how much can realistically be accomplished by what date.
Bearing in mind that change is our -and all Agile teams’ – middle name 
, the release plan is always subject to revision, depending on the customer’s priorities and how those change as we work towards completion of the project.
It sounds a bit scary to try to define a plan in this type of environment but luckily there are some techniques we can use to help us adjust our estimates.
But that’s another story.
