Category Archives: Recommended Reading

Pointers to articles or blogs posts of interest elsewhere on the internet.

Recommended Viewing: Impact Mapping with Innovation Games by Gojko Adzic

If you have never watched one of Gojka Adzic’s presentations, you really should.  This one is about 3 months old and in the first part is one of the best discussions I have seen on why so many projects and requirements efforts, including those that are “Agile”, fail to deliver value.  He also some valid comments on Business Analysis at around the 32 minute mark, and provides some suggestions on addressing some common pitfalls with Impact Mapping starting at around the 37 minute mark.

In my opinion, this one video has more value to Business Analysts than any webinar I ever attended.  If you have the time, give it a watch.

Keynote – Impact Mapping – Gojko Adzic from Italian Agile Days on Vimeo.

Recommended Listening: The Value Proposition of the BA Role

Back in January I was interviewed by Dave Saboe for his Mastering Business Analysis podcast.  The interview came about as a result of the LinkedIn discussion that resulted from my “The Role of the Business Analyst – It’s Time for a New Perspective” article that I had posted on this site.

The podcast episode has some discussion of that article, this site, and my own background (briefly).  If you are interested, the Mastering Business Analysis link above leads directly to the episode page on Dave’s website, as does the image below.  Or you can download the episode via iTunes.  This was episode 114 of Dave’s excellent podcast, so there are lots of back episodes for you to listen to as well.

Feedback and comments are always appreciated.  🙂

Recommended Reading: CrossTalk Journal – Beyond the Agile Manifesto

The November/December 2016 issue of CrossTalk is up and the subject of the issue is “Beyond the Agile Manifesto”.  CrossTalk is “The Journal of Defense Software Engineering” and as a U.S. Government publication is freely available.

Of the six major articles in the issue, five of them are focused on Agile in one way or another.  And one specific article I recommend everyone read is “The Heart of Agile” by Alistair Cockburn.

CrossTalk often has very good articles in it, and this issue in particular seems worth reading.


Recommended Reading: Painless Functional Specifications

Way back in 2000, Joel Spolsky wrote a series of articles on his ‘Joel on Software’ blog (highly recommended) that discussed Functional Specifications.  Now, given that this was written back in 2000 a lot of people will say it is out of date and no longer applicable.  But I think there are many valid points in his set of articles that any BA should think about.

Below I have provided a link to each of the four different articles in the series, along with a sample quote from each.  You may find that what Spolsky has to say resonates for you, whether you follow an ‘Agile’ or ‘Non-Agile’ process.
Continue reading

Recommended Reading: Why I’m not a big fan of Scrum

This blog post from July 11, 2016 was trending upward on Hacker News a few weeks ago and I thought it would be worth sharing.  The blog post is titled “Why I’m not a big fan of Scrum” and I am recommending it so that BA’s can get some insight into one engineers perspective on Scrum.  He emphasizes that his comments are directed towards ‘standard Scrum as described in the official guide’ and says:

After two extensive workshops, more than five years, and a couple hundreds of sprints working in Scrum, I have some points of criticism about it. I think it’s not naturally conducive to good software, it requires too much planing effort on the part of the developers, and it inhibits real change and improvement. In the following, I will try to put these into more detail by organizing them around more concrete topics.

I am always against dogmatic thinking of any sort, and whether you are a fan of Agile in general or Scrum in particular, I think the author here makes some interesting and valid points.  But if they are not valid from your perspective it is always a good idea to widen the horizons of your perspective.  While you may not feel this way, some engineer you are working with might and it would be good to understand their perspective.


Recommended Reading: Modern Agile

An article I was recently reading that was surfaced on Hacker News included a link to this November 2015 blog post by Joshua Kerievsky titled “Modern Agile“.  In it he lays out the four disciplines he see’s that make up the core of ‘Modern Agile’ and then maps many agile practices to those disciplines.  His four disciplines are probably the best concept I have seen for taking the concept ‘Agile’ away from its technology orientation, even if most of the specific agile practices he later discusses are almost all technology and software development specific.

It’s still a great blog post that I recommend any BA read.

Recommended Reading: What Great Listeners Actually Do

Jack Zenger and Joseph Folkman have a good article on the Harvard Business Review site that was published originally in the July 14, 2016 issue.  The article is titled “What Great Listeners Actually Do” and presents the results of their analysis of nearly 3500 participants in a development program designed to help managers become better coaches, and what specifically those who were identified as the best listeners (top 5%) were doing and how that compared with others.

There are a number of take-aways for business analysts here, as being good listeners is something I consider critical to our job.


Recommended Reading: The Problem with Requirements – Why is there still a problem?

I came across a white paper today called “The Problem with requirements: Why is there still a problem?“.  It was done by The Performance Institute and was sponsored by Robbins-Gioia and BluePrint (of BluePrint Requirements software).  I remember hearing about this when it came out in 2014 but for some reason or other didn’t read it at the time.

You may not find the results to be too surprising, but I think it is definitely worth a read if you are a business analysis.  It’s available from the Robbins Gioia web site and the link above goes directly to the report.

Happy reading.

Recommended Reading: The Breakdown Model Software Lifecycle

There is a short but interesting article in the January/Februart 2016 issue of CrossTalk magazine titled “Breakdown Model” that I thought was worth sharing on this site.  The link is to the mobile version of the article so if opened on your desktop you may need to ‘swipe’ with your mouse to flip pages.

The abstract describes the focus of the article like this:

“Here we present a variant of the Harmony process, the breakdown model which focuses on not only developing software but deleting all possible scenarios for failures in each phase of the development process.  This framework is adaptable with existing software development lifecycles.”

The article is actually quite short at about two pages.  The idea it presents is quite interesting I think even if you don’t have a dedicated team as they propose, because it presents a different way of thinking that a BA can take to all of their requirements work.


Recommended Viewing: Agile Product Ownership in a Nutshell

A co-worker shared this video today and I thought it was so good I would share it here.  It’s not just an excellent overview of the role of the Product Owner in Agile, it also provides a good ‘business-oriented’ overview of Agile itself.

It’s only 16 minutes long so it’s well worth your time.  Or if are already familiar with the Product Owner’s role in Agile you still might want to view it to see if you want to share it prospective Product Owners on your projects that are using Agile processes.

Recommended Reading: Agile is Dead

Matthew Kern wrote an article on LinkedIn titled “Agile is Dead” that seems to be going somewhat viral among the project and development communities.  As of the time I am posting this it has almost 150,000 view and is up over 20,000 views just since this morning.

In it he says (among other things):

“All these hyped trends have a lifespan.  Management fads especially have a lifespan.  In the modern environment these waves are closer together, and closer, and closer.  The end of the curve can mean unpopularity, few sales, reduced margins i.e “death”.

“Who said Agile is dead?  The founders of Agile and its practitioners said it, not me.  Don’t go thinking I made this up.  (I claim nothing myself regarding its current death, I just report the claims of many developers.  It’s dead with or without me or my post. “

The article is full of links to supporting content and it’s definitely worth a read in my opinion.  You may not agree with him, but the article and its many links may change your views a bit.  Or not.  🙂

Recommended Reading: Minimally Viable Deliverables

There seems to be a trend going on in the business analysis world for relabeling things that were previously done with new “agile” labels.  Bob the BA has done that in this recent article for Modern Analyst where he took what we used to call “tailor your communication to your audience and their needs” and put it under the “Minimally Viable Deliverable” name.  However, he makes a lot of good points in this article and if you aren’t familiar with the principle already maybe attaching an agile-like buzzword will make you curious enough to read it and learn.

Besides, how could not want to recommend something written by someone who describes their job as “provid[ing] badass business analysis training, consulting and mentoring services”.  🙂

Recommended Viewing: Disciplined Agile Business Analysis – Lessons from the Trenches

I’m part of a group at my employer that is piloting the Disciplined Agile Delivery (aka DAD) process and while they have hired a coach from Scott Ambler’s firm to help us out with implementing the process for our project, I still look for resources to help me learn more when I have the chance.  While doing so I came across a video posted to YouTube on February 5, 2016 that was a recording of a presentation Scott Ambler did at the “Adventures with Agile Meetup in London” that talked specifically about the BA role in the DAD process.

Roughly the first 45 minutes are mostly an overview of DAD, with some BA-related comments before that; but the majority of the BA-specific info comes after that point if you want to skip the DAD overview.

One of the interesting comments in the presentation occurs at the 1 hour 23 minute point where Ambler says (roughly), “The Agile people have gotten really good at building race-car engines….  So we take these really great race car engines and we drop them into an organizational tractor and we try to run a race.  And it’s a surprise why we aren’t succeeding.”  I thought it was a great point about organizational readiness that is often overlooked.  He emphasizes this point when he says (again, roughly) “The Agile Community is in this danger that we are sub-optimizing on software development and that is not the full picture.  We need to optimize the organization… It’s not just about software development.”

As a warning, the audio for Scott Ambler is very clear and consistent.  However, the audio for his occasional co-presenter and the audience is incredibly low and difficult to hear.

I found it interesting and worth listening to, as Scott presents DAD as a more “pragmatic” approach to Agile.  Enjoy!


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