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!
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.
I’ve been busy lately with efforts unrelated to this web site, including studying Disciplined Agile Delivery and brushing up my knowledge of Agile in general (a project of mine has been chosen to pilot DAD within my employer); increasing my knowledge of Business Architecture in general and studying for the TOGAF certification specifically; and trying to read several books that others have asked me to comment on.
While engaged in the Agile studies I mentioned above I came across an article on the CrossTalk Magazine web site titled Hybrid-Agile Software Development – Anti-Patters, Risks, and Recommendations by Paul McMahon that I thought was worth recommending. It’s relatively short yet has a lot of good info in my opinion. Especially if you are rolling out Agile in your workplace and are transitioning with some Hybrid-Agile methods.
CrossTalk is “The Journal of Defense Software Engineering” and is an approved U.S. Department of Defense Journal. As such, it’s content is generally freely available and I recommend you give it a regular read. Or at least check out the article titles. 🙂
As often happens for me, while researching one thing on the internet I came across something else so interesting I stopped what I was originally doing in order to take in more about the new thing I came across. In this case, I was looking into the technique of “Issue Trees” (this will probably be one of the next few wiki pages) and came across a 2007 McKinsey Staff Paper titled “The McKinsey Approach to Problem Solving“.
In those 27 pages I found not some dry discussion of problem solving techniques, but rather some of the best and most concise information on what a Business Analyst should be doing (IMO) that I have ever come across. They might as well have titled the paper, “Business Analyst Work Process – First, Understand the Problem”. The paper includes not just a solid overview and process for defining, analyzing, and solving business problems; but some detailed work artifacts, techniques, and suggestions as well.
I can’t recommend you read this paper enough, and believe that every person working as a Business Analyst (whether that is your title or not) should read it. To entice you to do that a bit, I am going to include some select quotes below:
I’ve been working on several projects lately (only one for this site) that have collectively meant that there have been less frequent updates to this site than there has been in the past. But I came across something today from Nancy Duarte that I really thought was worth recommending.
Nancy Duarte is a well-known expert on presentations, whose books I HIGHLY recommend. On her web site she has a 160+ page presentation that discusses her SlideDocs concept in depth. This presentation on SlideDocs is actually a SlideDoc itself. So what’s a SlideDoc? In her words:
“A slidedoc is a document created using presentation software, where visuals and words unite to illustrate once clear point per page. The result is a medium that can be read and digested more quickly than either a document or a presentation.”
This SlideDoc on SlideDocs has an extensive discussion of the use of the SlideDoc concept, their creation, best usages, the scenarios when they are most useful, and more.
I’m still re-reading and digesting the concept she presents, but I can see that BA’s could find this document structure very useful in their work. A lot of BA’s have experience with visual communication, but many tend to favor the written word for precision and clarify. This format let’s BA’s take advantage of both skills.
However, I would add that it might be worth looking at other software than just those designed for Presentations (such as PowerPoint) and to also consider software designed for more visually-enhanced documents than Word is capable of, especially desktop publishing software such as Microsoft’s own Publisher and open-source applications like Scribus.
But no matter what tool you decide to use, I recommend giving Duarte’s SlideDocs concept a good look and solid consideration. It’s the type of communication method I think BA’s should be adding to their repertoire if it’s not already there.
I came across a reference to this SlideShare presentation by Yasith Abeynayaka on LinkedIn. I liked it so much I though I would recommend it here.
To quote his description:
One of the most common myth related to business analyst career is that, the natural career path for business analysts is becoming a project manager. This presentation encapsulates 3 key points elaborating business analysts have better options than just changing track as a project manager. Further, it manifests 3 natural career options that a BA could consider.
Here is a view of the presentation. Be sure to send comments to Yasith.
An article in the current version of Requirements Engineering magazine (offered for free online by the IREB) caught my eye earlier today and I thought it was definitely worth recommending here so that others could give it a look. The article is called “TORE – A Framework for Systematic Requirements Development in Information Systems” and is written by several people who work at the Fraunhofer Institute for Experimental Software Engineering.
I had not come across TORE before, but it’s interesting in that it presents a list of decision points that have to be made in a Requirements Engineering effort at several different levels. It’s nice because it does not specify any particular techniques or methodologies, but rather is something you can drop into your existing process to help ensure you have made all the necessary decisions before moving on.
It’s a relatively quick and simple read and I highly recommend it.
I’ve been a bit busy lately and haven’t posted anything new to the site, but over the weekend I came across a white paper titled “How Do I Know What Questions to Ask?” that I thought was worth recommending. It’s from Roxanne Miller over at Requirements Quest and it’s a nice 20-pages or so discussion of planning for interviews as part of requirements elicitation. There are a couple of pages of example questions, tips on planning what questions to ask, and information on identifying the stakeholders you need to be involved.
It’s a nice piece of writing that I recommend, especially to more junior BA’s. But I think any BA could probably pick up at least a few valuable ideas.
And the nice thing is that the White Paper is freely available, no registration required, no email required. Those are generally the only ones I recommend, so give the article a look. And hey, since Roxanne is offering some freely available reading that isn’t just some useless marketing fluff piece; if you like her stuff, think about buying her book. 🙂
And if you like the white paper, she’s got a few more free goodies on her web site here.
NOTE: This isn’t a paid endorsement or anything like that. I’m a fan of people who offer useful, free, and openly accessible knowledge for BA’s. I mean, have you looked at this site? So I wanted to point out when someone is doing just that. And the article is actually quite good. 😉
In case you missed it, I wanted to point out that the International Requirements Engineering Board (IREB) recently launched an online magazine aimed at Requirements Engineering professionals called (appropriately enough) “Requirements Engineering Magazine”. As stated on the magazine home page:
The Requirements Engineering Magazine is an independent online magazine, published quarterly by IREB.
The Requirements Engineering Magazine shall serve as a platform for the active exchange of professionals on Requirements Engineering (RE). It is cost free in order to motivate as many professionals as possible to read the articles and thus give them the opportunity to expand their range of knowledge. Articles around the RE-topic are contributed by international professionals from the fields of BA and RE. Everybody is welcome to submit articles, may she/he be IREB member or not!
That part in bold above was highlighted by me, because it’s a very notable difference from the IIBA’s “Best Practices for Business Analysis” magazine. The IIBA wants to force you to be a member in order to read their online magazine. The IREB is putting it out there for everyone who might benefit to read for free. It’s the sort of difference that tells you a lot about the respective organizations IMO.
The first two issues have some good articles (or what look like good articles, as I am still reading through them) on such topics as the Product Owner in SCRUM, the “Innovation Arena” agile prioritization technique, a couple of articles on requirements re-use, and quite a bit more. Please consider contributing if you are inclined. There is even a link (at the top of the magazine page) to receive an email notification whenever a new issue is published. So far, it seems like the magazine is off to a great start and I highly recommend you give it a look.
I came across another white paper that Karl Wiegers wrote today, this one sponsored by Jama. For a white paper, it really isn’t specific to a particular software package or methodology, which I liked. It’s just a nice, short (but not too short) discussion of four different techniques for defining project scope. The four techniques are Context Diagrams, Use Case Diagrams, Feature Roadmaps, and System Events (triggers). The last couple of pages are about managing scope creep.
It’s a short, practical article that I think is worth pointing out. So enjoy!
So, why post a link to an article about defending against hacking in a Business Analyst reading list? First, because it’s a really good article. Second, because there are some potential lessons that apply well beyond the field of information security.
“Barriers — be they cell walls, border walls, or firewalls — are at best a temporary imposition to an invader. In the same way that tightly controlled unicellular life eventually evolved into more open and distributed multi-cellular life, the rapid evolution of cyber threats has outpaced the evolution of defensive barriers. The lesson is simply that modern organizations should work under the basic assumption that almost anything electronic is now open source.”
“A full-spectrum approach favors generalized health over specialized defenses, and redundancy over efficiency. Organisms in nature, despite being constrained by resources, have evolved multiply-redundant layers of security.”
“Provided you want your organization to grow and innovate, you can’t reject technology altogether and you can’t wall yourself off from all threats. The best bet is to do what the most successful organisms on Earth do — accept the risk and adapt to the changes. ”
From a business analysis perspective the take-away (for me) is that we should strive to define a more adaptable solution (be it a technological system or a process), even if it’s not the “best”, or most efficient, solution. That could be a very controversial suggestion though and I’m curious what others think.
I’ve often had issues with the way the “Waterfall” development methodology is portrayed by the rabid (or not so rabid) agile proponents (or “Agilista’s” as I sometimes call them). The way it’s described has never matched the way it’s practiced at my employer, or where any other BA I have spoken to has worked. That’s not to say that some places don’t practice it that way, but that is not the fault of the methodology; any more than the frequent complaints that businesses who adopt “agile” and fail “aren’t doing it right”.
A while back I came across a couple of blog posts that triggered my research into the Waterfall method, and I wanted to pass them both on. They are:
Rather than write a Rant about it, I decided to write up a wiki page that tries to just cover the information without too much opinion creeping in. I have never gotten around to adding some of the final details on Waterfall variants, but the full history and mis-perceptions of “Waterfall” are covered I think. Give it a look if you are interested.
I came across a post on the HBR Blog Network (part of the Harvard Business Review web site) that was directed at business leaders, but which I think applies to business analysts just as well. The blog posts talks about 5 steps that you can take when failure has occurred in order to adjust, learn, and hopefully not repeat the mistake. It’s a simple lesson that applies to much more than your professional career, so I thought it worth sharing. Enjoy!