A Learning Agile question from a business analyst


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.

Learning Agile goes to press!

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.

Learning Agile gets its animal

Learning Agile is the fifth book we’re writing for O’Reilly (or the ninth, if you include the enormous second and third editions!), but it’s our first animal book. So we were extremely excited this week when our marvelous editor, Mary, sent us the cover to review.

Have a look:

Learning Agile cover


I’m not sure why it only just struck me that the book will be in the same series as Learning Perl, which I believe was the first O’Reilly book that I bought back in 1994 when I was studying computer science at CMU. The animal is a black lion tamarin, a tiny primate that weighs just half a kilogram. Apparently, it’s so endangered that there will be far more pictures of it on our book covers than actual animals in the wild. They do have very agile little hands, and apparently they’re good at working in groups, so it seems like a fitting animal.

Jenny and I are really excited about this book. We’re about two thirds done with it. We’d probably be finished by now, but we had to take a break to push third editions of our bestselling titles Head First C# and Head First PMP out the door. But we’re jumping back into it, and finishing the last few chapters. We’ve also assembled a phenomenal tech review team, possibly the best that we’ve had for any of our books. They’ve already given us some fantastic feedback, and we’re really optimistic that this will be a great way to learn about agile.

The book is due out early next year. I hope you’re as excited about it as we are!

Announcing Head First C#, 3rd edition

It’s a pleasure (and relief!) to announce that after almost two years of work, the third edition of Head First C# is in print and available in bookstores. Head First C# is one of the most effective books on the market for learning programming with C#. Many thousands of readers, some new to programming and others with experience with other languages, have used the first and second editions. And now here’s the third edition, hot off the presses:

A new copy of Head First C#, 3rd edition, fresh from the printer
A new copy of Head First C#, 3rd edition, fresh from the printer

This was a major update of the book. The biggest challenge was finding an effective way to teach XAML. XAML is a fantastic tool for building robust user interfaces, but a lot of developers find that it has a pretty steep learning curve. The Head First C# approach has been to use Visual Studio as a learning, teaching, and exploration tool, and the improvements that the Microsoft IDE team made to the visual designer made it especially effective for teaching XAML. We decided to have the book dive straight into XAML design and exploration, and have the reader build a video game right in the first chapter:

Save the Humans screenshot 600x410
Save the Humans is the first project in Head First C#

The trick to really getting over that XAML learning curve turned out to be going back to WinForms development for a few chapters. WinForms is an older technology, but it’s much simpler to understand. This let us lay down a solid foundation of C#, .NET, and object oriented design concepts, which makes XAML a lot easier to learn. It also gives the reader the opportunity to build projects to solve the same problem in both WinForms and Windows Store (or WPF) using XAML. Seeing the same thing done in more than one way is one of the most effective methods for learning programming, and we’re able to take advantage of that many times throughout the book.

I hope you’re as excited about this as we are! If you’re looking to learn C#, whether you’re new to programming or experienced with another language, you should definitely have a look at Head First C#.

We’ve worked with O’Reilly to make the first three chapters available for free as a PDF.

Download the first three chapters of Head First C# for free here.


Scrum and Self-Organizing Teams

“Grand principles that generate no action are mere vapor. Conversely, specific practices in the absence of guiding principles are often inappropriately used.”

– Jim Highsmith, Agile Project Management: Creating Innovative Products (2nd ed.)

The board game Othello has the slogan, “A minute to learn, a lifetime to master.” This applies really well to a team that’s learning Scrum. The basic practices and mechanics of Scrum are straightforward, and not difficult to adopt. This is why many teams use Scrum as a starting point for going agile.

The basic pattern for a Scrum project is simple, which makes it very attractive for teams who want to go agile. And if that were all it took to adopt Scum effectively, we’d all be running great agile teams! But many teams find that they run into trouble with their Scrum adoption, and usually end up with what feels like an “empty” implementation. We explore this in our new talk, Scrum and Self-Organizing Teams: Openness, Courage, Pigs, and Chickens [pdf].

For a Scrum team to become effective, they need to do more than just follow the basic Scrum pattern. Effective Scrum teams are self-organizing, as Ken Schwaber explains (note the phrase that we emphasized):

For Scrum to work, the team has to deeply and viscerally understand collective commitment and self-organization. Scrum’s theory, practices, and rules are easy to grasp intellectually. But until a group of individuals has made a collective commitment to deliver something tangible in a fixed amount of time, those individuals probably don’t get Scrum. When the team members stop acting as many and adopt and commit to a common purpose, the team becomes capable of self-organization and can quickly cut through complexity and produce actionable plans.

– Ken Schwaber, Agile Project Management with Scrum

The goal of this talk is to help teams “get Scrum” by building on the practices and patterns of Scrum, and through those practices show the ideas behind the principles of collective commitment and self-organization.

In Agile Project Management with Scrum, Ken Schwaber introduced five Scrum values: couragecommitmentrespectfocus, and openness. Understanding these values is an important key to understanding self-organizing teams.

 Self-organizing teams work differently than command-and-control teams because they have different values. Understanding self-organization starts with learning how these values are practical things that can be incorporated into your projects:
  • Each person is committed to the project’s goals. That level of commitment can be achieved when the team has the authority to make decisions in order to meet those goals, and everyone has a say in how the project is planned and executed. For example, sometimes a requirements document isn’t perfect. To make the project successful, a team might have to ignore a documented requirement in order to deliver a product that’s much more valuable. This is only possible once they’re given the authority to make that decision.
  • Team members respect each other. When team members have mutual respect, they’re able to trust each other to do a good job with the work they’ve taken on. But that respect doesn’t always come easily to programmers and other technical people. Many programmers, especially highly skilled ones, often base their respect purely on technical ability. This can be a barrier to effective Scrum adoption. If a programmer doesn’t respect the product owner, he won’t listen to that product owner when they talk about the goals of the project.
  • Everyone is focused on the work. When a Scrum team member is working on a sprint, that’s his only job for the duration of the sprint. He is free to do whatever work is needed to complete the iteration backlog, and handle any changes that are made to that backlog during the sprint. When every team member is focused on the sprint goals and given the freedom to do whatever work is needed to meet those goals, the whole team is able to organize itself and easily redirect whenever a change is needed.
  • Openness. When you’re working on a Scrum team, everyone else on the team should always be aware of what you’re working on and how it moves the project towards its current goals. Many of the Scrum practices are aimed at encouraging openness among the team members. Task boards, for example, allow everyone to see all of the work being done by each team member, and how much work is left to do. Burn-down charts let each person gauge for themselves how quickly the sprint is meeting its iteration goals. The Daily Scrum, when done effectively, is a almost pure exercise in openness, because each person lays bare their tasks, challenges, and progress for the whole team to see. All of these things can help the team to create an atmosphere of mutual support and encouragement.
  • Team members have the courage to stand up for the project. When you choose openness over opaqueness, you make the team stronger rather than making yourself stronger at the expense of the team. It takes courage to do that, but when you do you end up with a better product and a better work environment. Scrum teams have the courage to live by values and principles that benefit the project. It takes courage to ward off the constant pushback from a company whose values clash with the Scrum and agile values. This requires vigilance on the part of every team member, especially the Scrum Master. But it also requires each person to be willing to trust that delivering valuable software will help them overcome resistance to these values. This requires courage too, especially when it comes time to sit down for a review with the boss. It takes courage to say to yourself, “Helping this team produce valuable software is more important to me that how the company sees my own personal contribution.”

Methodologies have built-in values

Every company has its own culture that includes specific values. For example, some companies value separation of duties, where each person has their specific role to play, and is protected from having to be accountable for things that they can’t easily influence or control. Other companies value transparency, where information is shared freely and even low-level employees can influence management decisions. Neither of these is the “right” way to run a company. Every individual company has a culture that evolves over time, based on the way it’s managed and the decisions that are made.

Every methodology has values built into it. Specific agile principles are often tied to (or implemented by) individual practices, and that those practices are an effective way for a team to bring each principle to the project. A team in a company that reserves decision-making for managers only will find it difficult to truly commit to projects. The same goes for any value or principle: if they clash with the company’s values, it presents a barrier to adoption.

But in a company where the culture matches the agile values and principles, an agile team will be much more successful than a command-and-control team. (This is one of the sources of the “astonishing results” that some agile teams report.)

You might be surprised at just how well the agile values and principles match your company’s culture. A good first step in introducing agile to your company is to talk about the values, and how they might impact your company’s culture. If you find that your agile adoption runs into trouble, finding the mismatch between agile values and company culture can help you smooth out the transition (or at least help you feel better by understanding why things went wrong).

So how would you build courage on a team? How would you get a team to believe in themselves, and believe that Scrum will not only help them build more valuable software, but that they company will see the value in their new methodology?