Announcing our latest book: Head First Agile

We’re pleased to announce that our latest book, Head First Agile, is finally here. We’re so pleased with how it turned out… and we’re not alone! Head First Agile has already gotten such a positive response from early reviewers.

In Head First Agile, we answer the question “What is agile?” and go in to give you a deep dive into Scrum, XP, and Lean/Kanban. We also include a complete guide to the PMI-ACP® (Agile Certified Practitioner) certification, so if you’re preparing for the PMI-ACP® exam, this is definitely the book for you!

You can buy the book from Amazon (and other retailers): https://www.amazon.com/Head-First-Agile/dp/1449314333/

It’s also included with your Safari subscription. If you’re not on Safari, you can start a free trial right now: http://shop.oreilly.com/product/0636920022374.do

So if you’re looking for a fun, easy-to-understand, brain-friendly guide to agile, we really think you’ll love this book.

A reader takes a closer look at Head First Agile

 

Announcing our upcoming book: Head First Agile

Head First Agile cover

We are extremely excited to announce our next book, Head First Agile, will be published by O’Reilly Media.

Have you been reading about agile, and want to learn more? Do you think that agile might help you and your team build better software? You’re not alone. Agile has gotten really popular with software teams because the ones that have “gone agile” often talk about the great results they get. The software they build is better, which makes a big difference to them and their users. Not only that, but when agile teams are effective, they have a much better time at work! Things are more relaxed, and the working environment is a lot more enjoyable.

Head First Agile is a brain-friendly guide to understanding agile concepts and ideas. Here’s what you’ll find inside:

  • Understanding the agile mindset: You’ll learn what an agile methodology is, and why agile methodologies that seem so different can still all be agile
  • Managing projects better with Scrum: This popular and effective lightweight methodology can help you build better, more valuable software, and make your team and your users happier
  • Engineering better code with XP: Its focus on code and programming can help you and your team build better systems
  • Continuously improving with Lean and Kanban: You’ll learn how they can help your whole team get better every day

We have two goals for Head First Agile. First and foremost, we want you to learn agile. But we also are focused on our readers looking to pass the PMI-ACP certification, so not only does the book have 100% coverage of the material for the PMI-ACP exam, it also includes end-of-chapter exam questions, a complete exam study guide, exam tips, and a full-length practice PMI-ACP exam—everything that you need to pass the exam.

Head First Agile will be available at retailers in Fall 2016.

A Learning Agile question from a business analyst

business-analyst

Jenny and I love hearing from our readers, and we got this excellent question yesterday from a Learning Agile reader (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 (much of it on the 78th floor of the World Trade Center!). Welcoming changing requirements is a basic principle of agile, so clearly there’s an important place on an agile team for someone with your experience.

So why don’t we talk much about business analysis or requirements management in the first two chapters of the book?

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.

In the last chapter, (“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 — understanding what users need (as opposed to what they say they need today), and building great software that really meets those needs — 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 uncommon)?

Our answer was to introduce the whole topic of requirements management very deliberately, and very carefully. We lay 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, we’ve given that hardcore developer with a somewhat antagonistic attitude towards business analysis the 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 to you — even if you haven’t written a lot of code! — because we laid the groundwork and didn’t just dive into advanced architecture and design from page 1.

I hope this helps to answer your question, and that you enjoy the rest of the book!