agile

What the Agile Alliance Australia should be

Posted in agile, General on January 29th, 2010 by mark – 2 Comments

The Agile Alliance Australia (A3[*1]) was formed at the Agile Australia 2009 conference with and an interim board. The goal of the interim board, as I remember it, was to setup the foundations for A3 and quickly hold another election (hence ‘interim’) to transition to a fully functioning body. The A3 did start to talk about what it should look like but it hasn’t progressed which is why I’m writing this entry.

I think the A3 should be:

  • a small group of people – until more are needed.
  • have a primary goal of co-ordinating a yearly, national conference
  • have a secondary goal of supporting local chapters.
  • have a tertiary goal of being a centralised point for resources

Supporting local chapters and acting as a centralised point were discussed at the original meeting.

Small Group

Keeping the A3 board small will keep it easy to co-ordinate and should remove some of the burocracy. The downside of a small board is that they’ll be kept pretty busy. I really don’t want to create a large, beurocratic, unwieldy beast.

A National Conference

This is a lot of effort but also has very big rewards. The benefits of having a national conference are:

  • it gives our community a place to congregate for learning and networking. Without it we are an uncollected group of local communities which would make it harded to achieve larger goals. We have a lot of very talented individuals in Australia and we should be proudly showcasing them. Agile Australia 09 and Agile 09 were two of my favourite events because it humanised my community. Sure, I’ve interacted with them over mailing lists, but meeting someone and having a face-to-face discussion is much more rewarding.
  • gives us a forum to introspect over the past year and set goals for the upcoming year for our community.
  • it is a lot of fun – surely that counts!

Support Local Chapters

The local communities have lots of advantages.

  • They are natural congregation points.
  • They *are* the agile community
  • They should already be talking about what agile is and how it is evolving.

A3 should not look to replace these groups, but should look to augment and encourage them.

Centralised Point for Resources

At the very least I think the A3 should provide a central Australian point for discussing local issues. This can be done very simply with a mailing list/google group (like this one!) and perhaps a wiki. I would see us central point for visiting and local agile enthusiasts to find out what is going on and get in touch with their local chapters. I don’t see a mailing list for this group replacing other, more authoritative lists, such as Ken Schwabers yahoo mailing list (just to pick one off the top of my head).

Money, Money, Money

It depends on how we want to run this thing but I can see money being kinda useful! The two big items are support for local chapters and running a national conference.

Have a pool of cash would allow A3 to support the local chapters so they can put on some food at a local event, hire a venue or buy other sorts of expenses (I’m not in favour of purchasing assets such as equipment, books, video cameras, etc).

The other advantage to having money is that we could properly co-ordinate a national conference. Up front money is needed to hire a venue and get the conference ball rolling and I think it is unreasonable for an individual to be out of pocket for that sort of expense (even if it *theoretically* only temporary).

How do you get money? Sponsorship? Membership? They all have their pros and cons. I’m in favour of charging a corporate membership fee (but not for individuals). This way corporates can show their support of Agile community and we get some money for it. Most likely a corporate would use their support as a way of validating to their customers they are serious about agile in Australia.  This is only slightly different to the original discussion.

If we feel that individual paid memebership is deemed useful, then I’d like it to get members a discount to the national conference.

I’m expecting this to be the most controversial part of my proposal.

What is shouldn’t be

I’d like to note what I do not thing the A3 should be:

  • only a group of large corps – I’d hate the only way to get represenation on the board to be via a large corp that doesn’t speak to individual’s interests
  • a certification body

Relationship to *the* Agile Alliance

I see A3 as an entirely separate entity to the Agile Alliance. It may be useful for both groups to have reciprocal benefits, but in their essence they are separate bodies with no jurisdictional overlap.

Why and what now?

If we don’t act now I’m worried that a non grass root group will claim to be a centralised body. I don’t want an unauthentic body being set up to dilute what “I” think an agile body should be.

Rich Durnall has setup a meeting of the Melbourne Chapter of A3 and some of these topics are coming to the surface. I’m going to be at the meeting on Tuesday to talk through my proposal. At the moment it is all booked out (120 people have signed up).

Feedback

This is my vision of what I think A3 should be. I’m ready and waiting for you feedback. Let’s co-orinate the feedback over on the A3 mailing list.

*1 – I thought A3 sounded better than AAA

Is the Product Backlog an Idealog?

Posted in agile on April 10th, 2009 by mark – 6 Comments

What is a product backlog?  I think most people who are working to the agile ethos will agree with the Scrum Alliance’s Guide description as “… the master list of all functionality desired in the product.” This definition is open to interpretation.

It’s that bit about “all functionality desired” that gets me.  Does this include everything that your product owner says they want?

Approach A – All ideas live in the backlog

The most common viewpoint I’ve come across is that the product backlog is everything the product owner has expressed an interest in.  I don’t know about you, but not everything this type of backlog is estimated in points.  You know the deal, the backlog gets big quickly with an enthusiastic product owner waxing lyrically about their dreams for the system, making the cost of fleshing out all stories pretty expensive.  There is nothing wrong with the product owner doing this, after all they are telling you want the want which should be a good thing.  To deal this the barrage of information we end up with epics and themes.  Both of these concepts will be decomposed into many user stories as we discover more about their purpose, but in the mean time they are placeholders of functionality to be built “later”.  The other side affect of a long backlog, epics and themes is that your backlog is strictly prioritized at the top and loosely prioritized at the bottom.  The advantages of this style is that you have all of your ideas in one place – a complete view of what the product owner has requested.

Approach B – The backlog represents commitment

The alternative is that your backlog only contains user stories that your product owner has committed to.  Commitment means that the product owner is prepared to pay for these stories.  Paying means spending the time and effort to think through each of the stories in detail and go through the estimation process.  It also means prioritizing all of the user stories.  “Nice to haves” and “maybe one-days” don’t end up there.  Instead another bucket is needed to hold future thoughts, I call this and Idealog.  In there you put features, epics and stories that wont make it in because of resource constraints (time and money) that you want to get to but you are not not ready for yet.

I think these two views of the product backlog have evolved for projects with different drivers.

When you are project oriented

Well defined projects have a specific goal they are trying to achieve, usually withing a fixed time or price.  The projects I’ve worked on end up with all of your ideas in the backlog, i.e. approach A.  If your product owner is very enthusiastic and generates lots of features it will become quickly apparent what will roughly fit within your constraints.  This means you can have a long list of everything your product owner desires and you can draw a line through the product backlog where you run out of resources.  It doesn’t matter if items at the bottom of your product backlog are a bit fuzzy.  This is how the “Big Businesses” I’ve worked for (like banks) work.  i.e. a business case is created, you get funding to create the business case, and you satisfy the goals within your budget and wind down the project.

When you are product oriented

Sometimes though you work on a product which does not have an end.  It, like your project, has a goal but the goal is usually nebulous or grander in vision.

Many start-ups I’ve worked at have a business model that is continually evolving.  Not only do they not know what they need in two months, they want to continue development for years (if all goes well of course).  In this case your backlog looks very different.  If you add every feature your product owner has contemplated, then your product backlog can become enormous.  One company I worked in had accumulated 2,000 stories after two years (including features and bugs) – the result was to delete the entire backlog and start again.  The logic was that if it was important then it wouldn’t take long to resurface (yeah, it was out of control and shouldn’t have got to that state).  Seriously, who can manage a backlog with so many ideas in it?  This is where an Idealog comes in.

An idealog should contain high level ideas to be debated, analyzed and decided whether they show enough merit for the product owner to commit to.  Until then, let them swim around in the primodial soup until they grow legs and walk into the backlog.  The backlog contains the details which are ready to go and the Idealog contains longer term plans which may or may not be done.

Who cares about a definition anyway?

The Agile Manifesto says nothing about a product backlog.  XP talks about a release plan but nothing more.  As I’ve mentioned earlier, Scrum talks about a product backlog pretty loosely.  But really, what does it matter?  If you can deliver what your product owner needs in a way that makes them happy then your doing something right.  Choose the right approach for your needs.

Personal experience

I’ve used a product backlog in both ways and they both have merit.  I prefer using an Idealog, I think it keeps the backlog clearer but I’ve used both methods effectively.

What do you do?  What do you think?