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?...

Have you ever considered how requirements can be routinely misinterpreted by developers?  I’ve spent considerable time analyzing this phenomenon.  It is obvious to even casual observers that inexperienced and lower level developers routinely make this sort of mistake.  However, my research has shown that experienced and very good developers make this type of mistake at the same rate!  This leads to the first Bob-ism on the blog:

A good developer will recognize they have a choice in how to implement something and ask themselves “What would the customer want?”  THEN they will make the wrong choice!

Think about it – if the developer could think like a customer why would we need Product Managers and others that perform those duties?  If you are a developer, I’m sorry for the generalization, but as an industry we need to get better at recognizing our limitations.  DO NOT TRY TO THINK LIKE A CUSTOMER!  Instead, ask someone who should know the answer.

No related posts.