In the conference, there are quite a number of presentations I could choose to go. Here were the ones that I attended:
- Collecting, Connecting and Correcting the Dots – Roger Burlton, BPTrends
- From Tactical to Strategic: A Business Analysts Path to Leadership – Kathleen Barret, IIBA
- Experience Agile: The Lego Game – Kim Szuta & Chris Lavallee, ThoughtWorks Canada
- That’s what I said but not what I meant or … Getting the Language right, right from the start – Gale Anshelm, Sierra Systems
- Panel – Metrics – What and how do you meansure a BA’s work? How do you know what makes a good BA?
Moderator: Aman Sidhu, Cenovus Energy,
Panellists: Marlene Barker, MLB2 Enterprise Ltd
Andrea Borle, CGI
Murray Laatsch, Enerplus - Agile Requirements: Critical Success Factors for Acceptance Test Driven Development – Jennitta Andrea, The Andrea Group, Inc.
- Requirements Gathering for Business Intelligence and Data Warehousing Projects - Francisco Rios Gascon, RIOSOFT LTD
By all means all these topic are interesting. However, I find that materials presented were general a guideline instead of a “How to”, or “Best Practice”. That is probably the biggest different when compare a technical seminar with a non-technical seminar. Every businesses deal with their own problems. There is no single recipe that would solve the business problems. As a result, a guideline would be more appropriate.
How to Measure a BA Success
As mentioned before in my last post, one of the most interesting topics is how to measure a BA success. A BA may involve in many aspects of a business. Some BAs have direct influences to the business case, some are indirect. These aspects may not be quantifiable. For example, if a BA implements new policy that improve the moral inside a company, what metrics do you use to determine how successful the BA did his/her job? If a BA proposes a new features development for a piece of software, which indirectly drives the sale of the hardware , could you easily relate the sale increase of the hardware is due to the BA decision.
In the world, we tries to come up with “thing” to be measure. Some suggests I heard were: compare the BA with a benchmark, BABOK, PM inputs, objective counts, etc.
Just like everything, we create an abstract of things we want to measure. For me, this is just human nature. In the conference, one of the presenter talks about her company would invest money to figure out how to measure their BA performance. Unfortunately I found that most of the discussion focused too much on tools and methodologies on how to measure a BA, but not so much on how to improve the BA.
If you step back and think about the reason you hire a BA , the basic reason comes down to the fact that you want to make your business more profitable. I hope that companies would focus on improving the BA skills, and performance, instead of emphasising the measuring part.
Agile and ATDD
ATDD – Acceptance Test Driven Development
As a software developer, I probably heard this term “Agile” at least one or twice a week. Just last week my team watched an agile development video.
There are many favour of agile software developments. My team is moving from the tradition waterfall software development to SCRUM development. I can probably spend months and months to talk about agile, but that isn’t necessary since you can easily google it.
In the conference, one of the topics presented is acceptance test driven development. Regrettably, I have to express my disappointment in the content that was presented. The content focused too much on “how to write a acceptance test”, instead of “how ATDD improve your software development” or “how to apply ATDD to your software development”.
Instead of presenting what I learned about how to write an acceptance test, I would like to talk about how ATDD is integrated in an agile development. Remember, ATDD is NOT a requirement in agile development, instead, agile development promotes the use of ATDD.
In agile development, it is very important to have fast feedback, and deploy results. With ATDD, it helps to ensure new development does not break old functionalities, and ensure new functionality works. The test is one of the important feedbacks for the development team, or the BA to know the health or your software product. As your software becomes more complex, more tests will be needed. As a result, your tests need to be maintainable. Many time the tests need to be refactored because the business requirement changes.
Your tests ensure the quality of your software, but you also need to ensure the quality of the tests. Here are some tips:
You want the acceptance tests to be:
- Based on business cases – when there is a business requirement, there should be an acceptance test.
- Readable – BA needs to understand what the tests do, and Developer needs to read the code easily
- Easily to maintain – Business cases changes all the time, the tests need to be easily refactored, or be prepared to toss the tests and write a new one
- Useful – Don’t waste time on writing tests that cover the same thing over and over again. Testing scenarios that never happen is useless too.
- Can be automated – i.e. Continuous Integration, which is another big topic that can’t be covered here.
Ultimately, you want to test your software as much as possible to ensure it works.
Data Warehousing
Another interesting topic that I attended was about data warehousing. I won’t get into the detail of what is data warehousing. However, there are two points that I like to share. When you want to develop a data warehouse, please remind yourself these:
- You need a business case to create a data warehouse
- Use waterfall model, no agile!
The presenter pointed out that data warehouse extracts very specific information from the database. If there is no business case to create, you shouldn’t spend invest resources in creating one. Developing a data warehousing can be expensive, and you want to do it right in the beginning. It is hard to modify afterward. That also lead to the 2nd point, use waterfall model when developing a data warehouse. Data warehouse tends to be rigid, changes are very hard to make once it is created. Therefore the waterfall development model works best.
