An interview with the man behind Bowie

~ Andrew Stellman ~ Leave a comment

When David Bowie passed away, the world lost a really special musician. The greatest artists rarely achieve everything they’ve done alone, and Bowie was no exception. I sat down with his main producer and collaborator in this interview with Tony Visconti [pdf] from our book, Beautiful Teams. The book is an exploration of what makes teams tick, through interviews and stories from people who worked with both extraordinary and ordinary teams. Being from the world of software, Jenny and I concentrated on software teams. But we wanted to go beyond software to try to discover some basic truths about teams. When I reached out to Tony, I expected interesting anecdotes, but I was really surprised (and pleased!) with how much his stories about working with rock stars reminded me of the other stories in the book.

Here’s the interview in its entirety, along with an introduction featuring another highly insightful mind, Tim O’Reilly. I hope you find this sheds light not just on the mind of a brilliant musician and producer, but also on your experiences with your own teams.

PDF Icon

A Learning Agile question from a business analyst

~ Andrew Stellman ~ Leave a comment

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!

Learning Agile goes to press!

~ Andrew Stellman ~ Leave a comment

After over three years of research, writing, and review, our new book, Learning Agile, is finished! Jenny and I are really excited about it, and we think it’s our best work yet.

We write this book because we really want you to learn agile! Agile has revolutionized the way teams approach software development, but with dozens of agile methodologies to choose from, the decision to “go agile” can be tricky. This practical book helps you sort it out, first by grounding you in agile’s underlying principles, then by describing four specific—and well-used—agile methods: Scrum, extreme programming (XP), Lean, and Kanban. Each method focuses on a different area of development, but they all aim to change your team’s mindset—from individuals who simply follow a plan to a cohesive group that makes decisions together. Whether you’re considering agile for the first time, or trying it again, you’ll learn how to choose a method that best fits your team and your company.

Here’s what you’ll learn in Learning Agile:

  • Understand the purpose behind agile’s core values and principles
  • Learn Scrum’s emphasis on project management, self-organization, and collective commitment
  • Focus on software design and architecture with XP practices such as test-first and pair programming
  • Use Lean thinking to empower your team, eliminate waste, and deliver software fast
  • Learn how Kanban’s practices help you deliver great software by managing flow
  • Adopt agile practices and principles with an agile coach

We’ve already gotten some great praise. Here’s what other people have to say about it:

Another amazing book by the team of Andrew and Jennifer. Their writing style is engaging, their mastery of all things agile is paramount, and their content is not only comprehensive, it’s wonderfully actionable.
—Grady Booch – IBM Fellow

What Andrew and Jenny have done is create an approachable, relatable, understandable compendium of what agile is. You don’t have to decide in advance what your agile approach is. You can read about all of them, and then decide. On your way, you can learn the system of agile and how it works.
—Johanna Rothman – Author and Consultant, www.jrothman.com

An excellent guide for any team member looking to deepen their understanding of agile. Stellman and Greene cover agile values and practices with an extremely clear and engaging writing style. The humor, examples, and clever metaphors offer a refreshing delivery. But where the book really shines is how it pinpoints frequent problems with agile teams, and offers practical advice on how to move forward to achieve deeper results.
—Matthew Dundas – CTO, Katori

Andrew Stellman and Jennifer Greene have done an impressive job putting together a comprehensive, practical resource that is easily accessible for anyone who is trying to ‘get’ Agile. They cover a lot of ground in Learning Agile, and have taken great care to go beyond simply detailing the behaviors most should expect of Agile teams. In exploring different elements of Agile, the authors present not just the standard practices and desired results, but also common misconceptions, and the positive and negative results they may bring. The authors also explore how specific practices and behaviors might impact individuals in different roles. This book is a great resource for new and experienced Agile practitioners alike.
—Dave Prior PMP CST PMI-ACP – Agile Consultant and Trainer

Andrew Stellman and Jennifer Greene have been there, seen that, bought the T-Shirt, and now written the book! This is a truly fantastic introduction to the major Agile methodologies for software professionals of all levels and disciplines. It will help you understand the common pitfalls faced by development teams, and learn how to avoid them.
—Adam Reeve – Engineer and team lead at a major social networking site

The biggest obstacle to overcome in building a high-performance agile team is not learning how, but learning why. Helping teams discover the why is the key to unlock their potential for greater commitment and more creative collaboration. With a focus on values and principles Andrew and Jennifer have provided an outstanding tool to help you and your team discover the why. I can’t wait to share it.
—Todd Webb – Technical Product Leader at a global e-commerce company

You can read the first chapter for free in the Free Sampler PDF.

Learning Agile is available directly from O’Reilly, where you can buy the paper copy, a DRM-free eBook, or a great deal where you can get both for a discount. It’s also available at Amazon.com and all major retailers.