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 →
If you are a business analyst, you probably use Excel. And if you use Excel, there is a REALLY good chance that you don’t use most of its capabilities and don’t know all of the ways to use it most efficiently. I know that is true for me. 🙂
That’s why I want to recommend you watch this video. It was private session done by Joel Spolsky to employees of Trello, Fog Creek Software, and Stack Exchange. And if you weren’t aware of it already; besides founding or co-founding all three of those companies, Joel Spolsky used to be a program manager at Microsoft back in the early to mid-1990’s and he worked a lot on Excel.
He moves quick in this video, but there are a ton of good tips and tricks for using Excel the way most BA’s do. That is, NOT for rigorous data analysis. 🙂
It’s only 54 minutes long and it might worth your time to watch.
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.