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.
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
- The number of development hours will be directly proportional to the size of the software product
- When acquirers and vendors both guess as to how long a project should take, the acquirers’ guess will always win
- When management compresses schedule arbitrarily, the project will end up taking longer
- When poor quality impacts schedule, schedule problems will end up as quality disasters
- Those that don’t learn from poor quality’s adverse impact on schedule, are doomed to repeat it
- Team morale is inversely proportional to the degree of arbitrariness of the schedule imposed on the team
- Schedule problems are normal; management actions to remediate will make them worse
- Management actions based on metrics not normalized by size will make the situation worse
- Estimating bias will be constant unless steps are taken to eliminate it
- The less you know about a project during development, the more you will be forced to know later
- 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
- The earliest predictor of a software product’s quality is the quality of the development process through code complete
- When test is the principal defect removal method during development, corrective maintenance will account for the majority of the maintenance spend
- 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
- The number of defects found in production use will be directly proportional to the number of defects removed during integration, system, and acceptance testing
- The amount of technical debt is inversely proportional to the length of the agile sprint
- Success of software process improvement depends on the degree of convergence between the organization’s official, perceived and actual processes
- The return on investment in software process improvement is inversely proportional to the number of artifacts produced by the software engineering process group
- Insanity is doing the same thing over and over and firing
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’ve added it to the Links page, but you can find the online magazine here: Requirements Engineering Magazine
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!
Four Techniques for Defining Project Scope
This new white paper by Joy Beatty of Sielevel and Karl Wiegers popped up in a recent Google search I did. It’s short but has some nice info and idea’s in it so I thought I would share. Here’s a link:
Forward Thinking for Tomorrow’s Projects – Requirements for Business Analytics
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.
Here is a link to the article: Defeat Hackers with Biomimicry
I came across the article originally through Bruce Schneier’s “Schneier on Security” blog, which I highly recommend.
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!
HBR – Get Ready to Fail
Nick Malik posted this recent entry on his Microsoft blog, Inside Architecture, and it has stirred up a bit of discussion. I found it interesting and wanted to call it out here.