Monthly Archives: December 2015

New BA Book List page & Year-End Update

First, I added a new page to the site called BA Book List under the Resources menu (which is also where the Links and Research Papers pages are now).  This is a list of all of the books specifically about Business Analysis and the BA core skills (which IMO are Business Analysis, Business Architecture, Process Improvement, and Requirements Engineering) that I could identify that still seem to be available for purchase.  I am not including any self-published or e-book only options; or any books about BA-related topics like Agile, Project Management, Software Development, or similar topics.  Feel free to recommend additions to the list if you think I missed a particular book.

Second, I would like to thank you the visitors to this site.  I created (and am slowly adding to) this site to be resource for the BA community that is free of advertising, login requirements, or poorly-hidden (or not hidden at all) “paid placement” articles.  2015 has been a great year for site traffic, with a few of the following year-over-year statistics standing out:

  • Unique site users increased from 11,600 in to 33,100
  • Returning users increased from 2150 to 5000 (and really, these are the people I maintain this site for)
  • The numbers of pages viewed increased from 21,400 to 52,000
  • The bounce rate decreased nearly 5% (which means more people are actually staying past the first page they view)
  • The top-10 countries visitors to the site came from were:  1) U.S.  2) U.K.  3) India  4) Canada  5) Australia  6) Germany  7) Netherlands  8) South Africa  9) Brazil  10) France

 

So thanks again to all the visitors, but especially thanks to those who actually stick around for a while and the few who keep on coming back.  Have a wonderful New Year!

Recommended Reading: How to communicate simply, and why

My friend Benedicta (Ben) Makin posted a great little article on LinkedIn that I wanted to share.  It’s on the importance of communicating simply, and it’s something I think BA’s really need to pay attention to.  I know it’s something that even after years of trying I still need to improve upon, so Ben’s article was a welcome reminder.

Here’s a link to the article so that you can give it a read.

The Immutable Laws of Software Development

Back in 2014, CrossTalk magazine had an article titled “If it passes test, it must be OK” – Common Misconceptions and The Immutable Laws of Software by Girish Seshagiri.  In it, Girish provides the list below and talks about all of these in detail.  However, it was the 10th law listed, which I highlighted with bold and italic text below, that struck me as the most relevant to Business Analysts.  What do you think of the “Immutable Laws” below?

The Immutable Laws of Software Development

  1. The number of development hours will be directly proportional to the size of the software product
  2. When acquirers and vendors both guess as to how long a project should take, the acquirers’ guess will always win
  3. When management compresses schedule arbitrarily, the project will end up taking longer
  4. When poor quality impacts schedule, schedule problems will end up as quality disasters
  5. Those that don’t learn from poor quality’s adverse impact on schedule, are doomed to repeat it
  6. Team morale is inversely proportional to the degree of arbitrariness of the schedule imposed on the team
  7. Schedule problems are normal; management actions to remediate will make them worse
  8. Management actions based on metrics not normalized by size will make the situation worse
  9. Estimating bias will be constant unless steps are taken to eliminate it
  1. The less you know about a project during development, the more you will be forced to know later
  1. In a 40 hour work week, the number of task hours for each engineer will stay under 20, unless steps are taken to improve it
  2. The earliest predictor of a software product’s quality is the quality of the development process through code complete
  3. When test is the principal defect removal method during development, corrective maintenance will account for the majority of the maintenance spend
  4. The number of defects found in production use will be inversely proportional to the percent of defects removed prior to integration, system, and acceptance testing
  5. The number of defects found in production use will be directly proportional to the number of defects removed during integration, system, and acceptance testing
  6. The amount of technical debt is inversely proportional to the length of the agile sprint
  7. Success of software process improvement depends on the degree of convergence between the organization’s official, perceived and actual processes
  8. The return on investment in software process improvement is inversely proportional to the number of artifacts produced by the software engineering process group
  9. Insanity is doing the same thing over and over and firing