Jenny and I love hearing from our readers, and we got this excellent question yesterday (which I’ve edited a bit for length):
I’m just starting to read Learning Agile however I can’t wait until I’m done to comment on what I have read so far. The first thing I’ve noticed is there is no mention of a dedicated person, like a BA, writing the requirements. One example has the lead developer and architect, team lead, and product owner writing the requirements. No wonder the project failed.
I have been a full time BA for the past 14 years and for 16 years prior to that I was a developer who also wrote the requirements for the systems I built. I’ve only worked on waterfall projects and many of them were successful because of the requirements I wrote. I think there is a place for Business Analysts on Agile projects.
I’m curious why, up to this point in the book, business analysis and business analysts have not been mentioned in writing requirements for waterfall or agile projects.
I want to share the response that I wrote to this reader, because I think it’s a great question, and it really speaks till the goals that Jenny and I had when we wrote Learning Agile.
So first of all, both Jenny and I have a lot of respect for — and experience with — requirements management and business analysis. I even spent several years in the early 2000’s managing a team of BAs. We devoted an entire chapter of our first book to requirements management. One of the core principles behind agile is that we welcome changing requirements, so clearly there’s an important place on an agile team for someone with your experience.
And we do cover the topic thoroughly in Learning Agile. By the end of the book you’ll have read about many aspects of business analysis, and how they fit into an agile project: tools and techniques to gather and manage requirements, ideas to help you and your team understand user needs, ways to integrate that knowledge into the project so it improves the code, values and principles to help the team get into a mindset where requirements are important, and methods for improving all of these things.
So to get to back the question: why don’t we talk much about business analysis or requirements management in the first two chapters of the book?
One thing we point out in chapter 3 is that when a team adopts Scrum, many people who fill a business analyst role — which actually includes a lot of project managers as well — are likely to end up as a Product Owner (one of the prescribed roles on a Scrum team). It’s true that’s a different role, and it can be a quite a change for some people, but I’ve talked with many business analysts who had a lot of success with agile by following this path because while the mechanics change, the core principles, skills, and ideas don’t.
Jenny and I had a lot of long discussions about exactly how to handle this particular issue when we were writing the book, in no small part because business analysis and requirements engineering are very important topics to us personally.
Our book is called “Learning Agile” because we concentrated on teaching agile, and we put a lot of work into coming up with an approach that will work for the largest audience that we could. Because while that topic is at the core of software engineering and is a critical pillar of agile, it’s also very complex and nuanced. Frankly, it’s not easy to teach, and we wanted to get it right and teach it well.
So what does that audience look like? Some readers — like a someone who spent 16 years as a developer and then 14 as a business analyst — have a very strong background in requirements engineering, and certainly don’t need to be taught business analysis basics. On the other hand, many of our readers know very little about requirements or business analysis at all.
In the last chapter of Learning Agile (“Coaching”) we mention an old saying about teaching: “meet them where they are, not where you want them to be.” We’d love it if all of our readers came to our book with the same deep knowledge of and experience with business analysis that you have. But that’s just not where they are.
So here’s the problem we needed to solve: how do we teach, say, a hardcore developer about requirements management in a way that helps him or her to not just understand it, but also care about it and recognize that it’s critical the success of to his or her own projects? And just as importantly, how do we teach such an important topic to readers who not only don’t understand requirements management at all, but actually have negative feelings towards requirements (which, if you search programmer forums, is not an uncommon mindset)?
Our answer was to introduce the whole topic of requirements management very slowly, and very carefully. We put a lot of work into laying down a foundation in the first few chapters, so that by the time we teach about requirements backlogs in chapter 4, user stories in chapter 5, and minimal marketable features in chapter 7, for example, we’ve given that hardcore developer with a somewhat antagonistic attitude towards requirements engineering the intellectual framework to really accept it.
And hopefully we’ll have done the same for you with other topics that we teach, so that when we talk about decoupled architecture and emergent design in chapter 6, it will feel familiar and make sense (because we’ve taken the time to lay out the groundwork for people who need it, and didn’t just dive into advanced architecture and design from page 1).
This does mean that we dodn’t get into the details of requirements management very quickly in the first couple of chapters. But really… you’ve been doing business analysis professionally for a decade and a half, right? How much are Jenny and I really going to teach you about a topic in which you’ve already achieved a level of mastery? Not too much, I suspect. Hopefully it’s okay that we didn’t spend the first hundred pages teaching you things you already know.
Our sincere hope is that people who previously didn’t have a lot of knowledge about business analysis and requirements engineering will read our book and recognize how valuable a skilled and experienced business analyst is to any software project, agile or otherwise.
I hope this helps to answer your question, and that you enjoy the rest of the book.