This past week I was fortunate enough to be a speaker at the Agile Development Practices show in Orlando, Florida.  I had a great time while I was there.  I was even asked to be part of a 3-member panel sponsored by Borland to speak about agile transitions.  I was honored by the invitation to the panel, and had a great time interacting with the others that were there.

But my primary reason for being in Orlando was to give a talk titled “Agile for Business Analyts.”It was a 90 minute session primarily aimed at helping business analysts understand that the Business Analysis Body of Knowledge (BABOK) from the International Institute of Business Analysis (www.iiba.org) could be interpreted in an agile way.  I must have done something right during the presentation because the 25 people in attendance gave it an average score of 9 out of 10 on their evaluations!  While doing the presentation I felt ratified in my opinion that the agile community is ignoring several important roles when teaching organizations how to use agile effectively.  I’ve said many times the agile community is addressing project managers, some developers, some product managers, some testers, but not enough business analysts, line managers, and others.  In fact, I’m pretty sure most people would say that every position except project managers are basically being ignored.  I still believe Agile For All has the right meaning in today’s agile world.  OK, soapbox mode off now

The business analysts in attendance clearly felt confused by how to function in an agile environment.  The thrust of my presentation was how easy it should be to convert from waterfall to agile for people responsible for requirements definition and management.  The phrase “Just enough, just in time” is a big help.  The pressure to get it absolutely right the first time is no longer present.  Huge requirements documents are a thing of the past.  Elimination of wasteful work (ie, analyzing requirements too far in advance) and deferring of commitment (admitting the detail is unknown until some other events occur) are also important items to keep in mind.

If you are a business analyst, or you know of business analysts that are confused by how the BABOK supports agile, tell them to put on their “agile glasses.”  They need to think iterate, retrospect, and just enough, just in time.  While at the conference I spoke to Ellen Gottesdiener about agile business analysis and we both agreed there is not enough information out there.  Hopefully version 2.0 of the BABOK will take an approach that is more in sync with agile.  I guess I’m not terribly hopeful of that, but who knows.

Have questions about agile and business analysis?  Feel free to contact me and discuss it, or comment here so others can discuss it as well.

Related posts:

1. Agile and various bodies of knowledge (PMBOK and BABOK) In case you aren’t aware, there are at least two international organizations...
2. Are you agile – the Nokia test I’ve been helping lots of clients start new agile initiatives recently.  This...
3. Changing the perception of “manager” In agile it is often counterproductive to use the title of “manager”...

In case you aren’t aware, there are at least two international organizations which have created impressive bodies of knowledge.  The International Institute of Business Analysis (IIBA – www.iiba.org) and the Project Management Institute (PMI – www.pmi.org) have created the Business Analysis Body of Knowledge (BABOK) and Project Management Body of Knowledge (PMBOK) respectively.  Both of these works are impressive in their scope and level of detail, but I believe they both have a fundamental flaw.It is my belief that someone blindly following either the BABOK or PMBOK will end up with a process and result consistent with the waterfall model.  This is interesting to me because both organizations claim their works are process agnostic and simply represent best industry practices regardless of the underlying process.  I actually agree with them – SURPRISE!  But, with a caveat – you have to look at the practices with what I’ll call “agile glasses” in order to end up being consistent with an agile process.   You simply cannot blindly follow what is written because it is too easy to fall into the waterfall mindset when you do things in that manner.  Instead, look at each generally accepted practice through agile glasses and decide if the practice has a useful place in your process, and if it does, how you would use the practice effectively.

Both the BABOK and PMBOK are consistent with an agile approach to software development, but not without interpretation.  Remember, both works are simply guides that clearly define generally accepted practices.  They are not meant to define process, so don’t interpret either one from a process perspective.  Instead examine the practices to determine which fit and how they fit and you will end up with an agile framework which is still consistent with either or both documents.

I guess the Bob-ism here is “Attempting to use the practices in a body of knowledge document is likely to lead to a waterfall implementation if an agile interpretation is not kept in mind.”

If you want a heavyweight process then feel free to follow the documents as written.  If you want to maintain a lightweight agile process then interpret the documents from that perspective and utilize generally accepted industry practices to actually improve your agile process!  You may be surprised how you can improve through the use of generally accepted practices used in an agile appropriate manner.

Related posts:

1. Never have a PMP on an agile team Now that I have your attention, let me be VERY clear I don’t...
2. I’m a Certified Scrum Trainer (CST) – so what? This is a companion post to last year’s “I’m a Certified Scrum...
3. Agile Ponderings: Certification – useful or not? I’ve had to do a lot of thinking about certification recently. Why?...

The software industry today is plagued by long release cycles for important products. That is one of the many reasons why companies are going to agile methodologies. In doing so companies hope to deliver software on a more regular basis. They feel this will make for happier customers. Of course I’m not going to say they are wrong, but it goes far beyond the fact that they get more frequent deliveries of software.

I believe one of the biggest differences comes from how the “feature bus” is different in an agile environment. When using non-agile methods we still try to ask the customer a question like “What would you like to see in our product?” Our problem is that our customers recognize how software development occurs and what they hear is something like “The feature bus is here, so I better pile in as many things as I can think of because this is the only stop it makes this year!” The worst part about this is the recognition that what they hear is probably true. It leads to conversations like this:

Us: What would you like to see in our product?
Customer: (lists 100 items including things they only peripherally think they may need some day)
Us: Wow, that’s a big list! Let’s be real here. What do you really need?
Customer: OK, you’re right, those last 3 items out of the 100 I don’t need.
Us: I don’t think you understood. What do you REALLY need?
Customer: Ok, throw out #96 as well.
Us: Let’s try a different approach. Which items are most important to you?
Customer: Oh, in that case, only the first 90 are really priority 1, the others are priority 2.

As you can see, the conversation is rather fruitless. With good reason. After all, we don’t usually deliver products frequently enough for our customers so we have trained them to behave this way.

Agile changes the model dramatically. With frequent software deliveries and potentially even more frequent iteration demos (you do invite customers to iteration demos don’t you???) the customer gets used to seeing things in a much shorter timeframe. They understand that they don’t have to pile on the useless items where they don’t have much clarity yet. If they concentrate on important things they will get those quickly. The world changes when we can ask the initial question as “What do you want next?” Instead of an open-ended question asking the customer to dump everything on us, we are asking a slightly closed question where the answer may be only a few items. Plus we get a bonus out of this – how hard is it to prioritize a few items vs. prioritizing 100 items?

When we change the frequency of the feature bus we will change the behavior of our customers. Most surveys say the #1 or #2 most critical project success factor is having early and frequent interaction with the customer. This is a great agile practice that often isn’t used to full effectiveness. Start inviting customers to demos and asking them what they would like to see next. You will be astounded at how quickly their trust builds and how quickly you start making better products because of it!

So, what would you like to see next in this blog?

Related posts:

1. Agile pondering: Is it agile to have a “single wringable neck?” In Scrum one of the named roles is that of Product Owner. ...
2. Agile Antipattern: Everything is priority 1 I was just working on some Powerpoint slides for our Agile Product Management...
3. New to agile? Remember to respect people One of the Lean Principles is “Respect People.”  I think it may...