RylandLeyton

Ryland Leyton

Ryland Leyton recently released his book, The Agile Business Analyst: Moving from Waterfall to Agile. Over the years, Ryland has provided training and mentoring for events and individual members of the Greater Atlanta Chapter of IIBA, so I was thrilled to see him take pen to paper and share his insights through a medium with broader reach.

Ryland agreed to provide some additional information and background on the thought process behind the book for Practical Analyst readers, via the Q&A provided below. Written especially for business analysts operating in, or transitioning to an agile delivery environment, I recommend The Agile Business Analyst as a solid candidate for your professional development reading list.

What was your motivation for writing The Agile Business Analyst?

In September of 2014 I had volunteered to give a presentation on the Agile methodology to our Atlanta IIBA chapter at the Boot Camp event, (a professional development day). Agile has been a big topic for the BA community and by this point I’d had some experience working in it with a group that was very invested in staying agile, but in bringing stronger BA practice to the team. Things were going well there so I chose I could speak to the subject for the chapter event. I put a lot of work into preparing for it – the session was planned for 3 hours, and we stretched to almost 4!

People were very responsive to the material – I could really feel the hunger for the information! It seemed to me that the audience was really connecting to the subject, and at several following events people kept asking questions that I just couldn’t answer in a brief conversation.

I was actually in the right place in my personal and professional life for a big project, and I decided to use my original presentation as a foundation for a full book on the subject.

Who stands to benefit the most from The Agile Business Analyst, and how?

The core audience for the book is, as the title says, the BA who is moving from the waterfall approach to the agile approach. They’ll find it speaking to them directly in terms of knowledge about agile, skills the BA should have, and how the BA fits into the agile SDLC and partners with other team members. After reading it they’ll have a thorough grounding in agile, understand the roles & responsibilities of the BA as well as those of their teammates.

The book is also good for product owners, managers, anyone new to the agile space, or scrum masters and development professionals new to working with a BA on their team. If you’re looking for a good practical primer on agile that is written in an easily accessible way, I think this book can cover it for you.

Of all the topics available in solution delivery in general, and business analysis in specific, what drew you to the topic of agile for business analysts?

Really, just the major demand for the subject that was so overwhelming wherever I went. People wanted to know about one agile topic or another every time I talked to a group. Also, the “agile” practitioners weren’t making it easy for BA’s to fit in or acquire knowledge. Most sources seemed to just say “we don’t use BA’s”, and expected the conversation to stop there.

What was the most the most rewarding aspect of writing the book? The most challenging?

The most rewarding thing has truthfully been people reading it and letting me know it helped them in their work – that they got a lot out of it, either a good grounding in agile, or something they hadn’t considered before. It really was written because I felt a calling to add something to our community on this subject, so I feel good when I know I’ve hit that mark.

There were two parts that were really challenging in the process of creating the book. The first was getting the first draft done without editing myself too much. Friends from other fields who have done their own writing encouraged me to just write anything I thought of first, and edit as a completely separate activity. I had to get all the subjects I thought I wanted to cover completed, organized enough with good common threads, and then make myself give an incomplete product to a selection of close friends and agilists who could give me their time to read an unpolished manuscript as well as give me feedback on it! The second most challenging thing was applying the agile principle of “minimum viable product” (MVP) to the book itself. I always found more things I was interested in writing about…but I had to stop somewhere and call the book “done”. At least, for the first edition! I had to remind myself that the book had no value in the community while it sat only on my desktop! I wanted to get it out there, start seeing how it did in the real world, and log some improvements for the future. When you’re writing something that you feel really represents you in your professional life, that can be a hard line to identify.

What have you’ve learned about the topic through your detailed research for the book, that you didn’t know when you started?

The second part of the book has two case studies in it – the same project looked at through the waterfall view, and the agile view. When thinking about the agile view I spent a lot of time considering just how different agile was, and what massive opportunities for interesting BA and project practice, are present in agile. The agile project could have gone in radically different ways than the waterfall one. I deliberately chose to take a mostly “mainstream agile” approach – if there is one – versus the most radical of the choices. I spent a lot of time thinking about the concept of minimum viable product (MVP) in both the case study, and in other projects I’d worked on. Just how minimal can you get before you release something into the world to start the learning cycles? How close to the bone can you make your MVP in a project? It’s something I still think about a lot as I’m working with clients.

Let’s talk about your aspirations for the book. Jumping ahead 5 years – what would you like to be able to look back and say about The Agile Business Analyst?

I would love it if the book were well enough received that it becomes a staple of the agile BA field. I’m expecting to do a second edition at some point in the future to expand on several topics as I receive feedback and continue to have my own experiences in my agile practice, so having that out would by then is also an aspiration.

Any other advice or words of wisdom would you like to share with Practical Analyst readers?

Always keep interested in something in the BA field, and try to do work that aligns with your professional passions. You’ll love your work!