19 January 2009

B2T's thoughs on Agile

B2T are a training organsation that focus on the BA skill set.  They have a BA blog which is worth reading.  This week Kimberly published some thoughts on Agile - a reassurance that the BA role is still important, even with the rapid growth of Agile methods for projects.

It stimulated some thoughts of my own.

1. BAs are not required for all types of agile projects.

In fact if the developer team have the skills, why not let them out of the back room onto the shop floor? Why put middleman into the conversation?

How you address requirements management depends on the project, the people and the organsiation. BAs are not always required. (Nor are programmers.)

2. Iterations mean you don't work to a product blueprint.

If you are a BA assigned to an agile project your most likely mistake will be to model an end state (at least in your head) and then work towads that. This is pretty much contrary to the whole iterative approach.

There is a fundamental value in the agile philosophy that says if we design a product today we will probably get it wrong. So don't. (The phrase that is disparagingly used is BRUF.)

In many stable markets - such as governement - this is not true, but in environments where thre is significant shift in business requriements over time, it is very important to understand.

3. You will probably not work on a pure agile project.

The world isn't black and white. And you don't just pick Agile or Waterfall approaches. In the real world you usually mix it up, pulling techniques and tools from a range of methodoloies and frameworks to address the specifics of your project.The approaches us enterprise workers will usually take is a compromise - some of the strengths of agile and some of the strengths of a plan diven approach.

Part of this creation of a hybrid approach is because we think about the situation and design an approach that is appropriate to the cirumstances. Part of it is becasue of a natural conservatism in large organisations.  (And I think that at this stage of the Agile methodology maturity we don't know whether this will be a compromise or an enhancement to the agile models.)

And lastly, I think when people talk about Agile as a methodology is smacks of a certain lack of understanding. (Maybe on my part?)  Agile is a value set which underpins several (dozen?) methodologies.  As a BA, when you talk about Agile I expect you (readers of BetterProjects) to be more specific.


  1. Anonymous12:24 am

    BA role is no different than other whet it comes to agile methods. If you want to work with agile everyone have to change their mindset to drive into best possible solution instead of solution which fulfills initial requirements best.

    The most tricky part is to make stakeholders making this mindshift. They feel secure with the old-school methods which reuires some work up-front (requirements gathering) and at the end of the process (verification of ready product).

    With no support from stakeholders the whole thing becomes harder.

    On a side note: I like your approach with leaving BA aside as far as a developer has right skills to do the job.

    And as far as we talk about software products development is the only role which actually is required. You went a bit too far with that one.

  2. Yup,

    but not all projects end up witha software soluton :)

    Thanks Pawell.