I came across a link on Hacker News to a new web site that describes the Domain Storytelling technique. I haven’t finished reading through all of the content, but it looks like something worth reviewing especially if you work in a Business Analyst-type role in Agile processes. But as always, you might useful ideas even if you don’t work in Agile.
Every once in a while I come across an article that discusses some subject in an incredibly clear and thoughtful way. Issue 2017-02 of IREB’s Requirements Engineering Magazine online contains just such an article. It’s titled “The goal is to solve the problem” and it’s an article that I recommend any Business Analyst or Requirements Engineer read. And if you are relatively new to the field I recommend it even more.
This article is full of highly quotable text and I have included some quotes below to give you a sampling, but it’s just that. You really need to read the whole article to gain the full value.
As the authors state in the opening paragraph, they use to the article to:
“… critically explore the concepts and look into the relation between problems and goals through solutions. We will also pay attention to their recursive nature. We will end up with several (slightly provocative) thoughts on the subject, including practical implications for the work of the requirements engineer.”
The article talks about how BA’s can add value both inside and outside of the project environment. It’s relatively short but it speaks to issues I have seen over and over again; and that other BA’s I have spoken to have mentioned many times as well. So it really speaks to issues that I think are important to all BA’s whether you are a “project” BA or not.
The four main sections of the article give you a good idea of what it covers. Those are:
The ‘First Solution Trap’
What problem are we trying to solve?
What Are the desired outcomes
What is the current state? Understanding the problem (and its root causes)
So if you have a bit of time to spare, give it a read. In my opinion, it’s definitely worth your time.
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.
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.
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.
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 →
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.
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.
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.
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.
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.
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.
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. 🙂
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”. 🙂