Andrew Stellman

Jan de Boer wrote:Doing your job right is a mindset. You do not have to put a label on it. If you generalize agile to values and mindset, then what is it? This good mindset, and good values exist without agile. They would have existed if no-one ever invented the word agile in the software context. It is like saying socialism is not a certain way to organize your economy, but a mindset of sharing, and the values of caring for each other. Sharing and caring exists without socialism. Replace socialism with agile.

Yes, a lot of people say something like this when they first run into the idea of agile as a mindset and not just a set of practices. Agile values are actually the opposite of generalization – the values of agile and agile methods and frameworks like Scrum, XP, and Kanban are very specific.

A response like the one you gave is especially common when people first see the Scrum values of openness, courage, focus, commitment, and respect. "These things sound so general, vague, and positive. Can't they be applied to any team?" But it turns out that attitude actually holds back an agile team, and becomes a self-fulfilling prophecy. I'll explain why.

Most teams actually struggle with the values—so much so that it's the true root cause of their problems with agile, even if they only see symptoms. When Scrum teams complain that they feel like they're "just going through the motions" (Google for "cargo cult agile"), that's an important symptom of a culture that runs counter to the values that make Scrum effective. We call this "better-than-not-doing-it results" in Learning Agile – it was going agile because the team is better than before, but they're only doing marginally better. Where are the "astonishing results" or "hyperproductivity" we were promised? It turns out that when the team's culture doesn't match the mindset needed for the method or practices, they get much worse results, and productivity is much lower—and it's palpable and obvious as to everyone on the team that there's a problem, even if they don't know what's causing it.

Jenny and I also came up with a little exercise in Learning Agile called "Are you OK with?" to help teams understand whether or not their team has a culture that matches the mindset. For example, when a lot of times, when people first encounter the Scrum values (openness, courage, focus, commitment, respect), a lot of people people think, "Who could be opposed to 'respect' as a value? What does that even mean? Isn't that just a really vague concept?" But it turns out that it's actually something very important that's missing on a lot of teams. So we ask people to honestly answer these questions:

In 'Learning Agile' (p164), Jenny and I wrote wrote:To understand if you’re ready for respect, ask if you, your team, and your boss are OK with:
• Trusting the team to do the right thing, and deliver each feature at the best possible date based on relative value and how the project progresses—even if it causes the project to take longer than you expect?
• Giving the team enough time to do the work, and not demanding overtime of them?
• Trusting the team to choose the tasks that are right for them and for the project, rather than relying on strict roles, RACI matrices, etc.?
• Not being able to ever say again that you don’t know why the team decided to do something the way they did?

Have you been on teams that can honestly say "yes" to all of these questions? I have, and they're much more effective than ones that can't.

Most teams, if they're being honest, will answer "no" to most or all of those questions. That indicates a mindset problem – a clash between the team's culture and the Scrum values – that will lead to friction, delays, and project failures.

I hope this helps to explain the value of putting a label on mindset, and why it's more specific than just saying a mindset is "good" or "bad."

Divya Shiv wrote:Is the Agile concepts in the book is explained  based on the standard tools and processes or all other tools(Kanban/ Zenhub etc) and processes are covered ?

Head First Agile covers three specific frameworks/methods/methodologies: Scrum, XP, and Lean/Kanban. Along with Scrum, it covers many of the generally accepted Scrum practices (GASPs), including task boards, burndown charts, user stories, personas.

We did not cover any specific software tool. We did go into some detail about how version control systems work, but we didn't cover a specific tool like Git or Subversion.

Tim Holloway wrote:I've seen - and been wearied - by situations where you have systems so complex that one or more components could be updated daily (if permitted, this would be one of them). But letting everything slide like this borders on criminal. These are people with large-computer IT backgrounds and they should know better. I'd say that they're just planning to ride until it blows, then bail, but the way they're set up at the moment looks like all that would do is get them sued from every direction at once.

Yes!! This is exactly why we treat technical debt the way we do in Head First Agile – I've run across many teams like this. I absolutely get why Ward Cunningham initially proposed technical debt the way he did, using a metaphor that assumes that not all debt is bad. But the reality is that most teams aren't using debt the way you'd use a home equity line of credit to redo a kitchen and increase your home's value. They use it like they're taking an almost maxed-out credit card on one last shopping spree.

Yes, covering Scrum from scratch is a primary goal of Head First Agile. Scrum is really simple and straightforward if you already understand it. But if you're encountering it for the first time, it's easy to get a little lost. We put a lot of work into explaining Scrum from the ground up, and we don't make any assumptions about the reader's prior knowledge.

And I agree – you are being taught Scrum in a weird fashion. Like this:

Rahul Dayal Sharma wrote:The technical level user stories has multiple acceptance conditions which are then placed on the TODO lane of your kanban board

I don't even know where to begin with that. That's pretty convoluted, and definitely not how most Scrum teams operate.

Yes, Head First Agile definitely covers a bad practices. In fact, that's an important part of how we teach agile. A lot of the ideas and practices of agile make the most sense in the context of specific team problems that they're trying to fix. So we lay out different team scenarios that demonstrate those problems, and then show how various agile techniques, practices, and ideas can help teams get past them.

So, we don't take the approach that certain methods are "good" or "bad" – these things are tools, and some tools are more or less useful in certain situations. That's why giving this kind of context is so important.

Absolutely. We intentionality targeted several decent agile methods, and made no assumptions about any prior knowledge. We did this specifically because we understand that our readers come from many different backgrounds -- developers, testers, team leads, managers, product owners. (It helps that between the two of us, we've done all of those jobs professionally.)

So yes, I think you will definitely find our nook helpful!

They're apples/oranges. I really like Eric Ries' work, and a lot of people have found real success with it, but it's very different from Lean/Kanban. Lean startup is a methodology for developing businesses and products. Kanban is an agile method for process improvement, adapted from TPM  by David Anderson. Like other agile methods, it has a set of values that drive its mindset. These values are summed up really well by Lean Thinking, also adapted (independently) from TPM and manufacturing by Mary and Tom Poppendieck. They do different things.

Yes, definitely. I actually give a talk called "agile antipatterns" every now and then about exactly this topic.

Rather than write a lengthy response, I can just share the slides from the last time I did the talk: https://www.scribd.com/document/362772908/Agile-Antipatterns

Kanban is an excellent choice. I learned a lot about Kanban when Jenny and I were writing Learning Agile. I'd used it for years, and I felt like I had a good handle on it. But then we got some really good feedback from David Anderson, who was really generous with his time in reviewing what we wrote and giving feedback. I had understood how it was used, but it turned out that I still had a bit to learn about its theoretical underpinnings. Long story short, Kanban is really, really worth delving into.

(BTW, for those of you who don't know, David Anderson is pretty much the guy when it comes to Kanban. He originally adapted it for use in software development, and he's done some really impressive work. His book, Kanban, is fantastic – I strongly recommend it. And if you get a chance, you should listen to this episode of the Software Engineering Radio podcast that features him.)

That said, Kanban is widely misunderstood. A lot of people think that it's a system for project management, like Scrum. It isn't. Kanban is a method for process improvement. It combines very well with Scrum, but you can use any process (or no "official" process!) as a starting point. The goal is to experimentally evolve your process by first understanding and visualizing it, and then limiting work in progress.

Jenny and I really made it a priority to explain Kanban as clearly as possible in Head First Agile. If anyone read what we wrote, I'd be interested in hearing what you think.

Jan de Boer wrote:

Tim Holloway wrote:I was doing "Agile" many, many years before the term was invented..

Tim .... Everybody was doing "Agile" before the term was invented. The term "Waterfall", and especially the "Agile" view of what "Waterfall" was, is also invented by "Agile". And THAT is the whole problem.

This actually made me laugh out loud. It's true, everyone was doing agile before the term was invented. Just to be clear, the term agile was adopted in 2001 (at the meeting in Snowbird, Utah), and many of us were doing Scrum and XP in the '90s.

One small nitpick. The term "waterfall" is widely credited to an engineer named Winston Royce, who introduced the concept in a 1970 paper called Managing the Development of Large Software Systems (pdf). Ironically, in that paper he described it like this: "I believe in this concept, but the implementation described above is risky and invites failure."

But reading this thread, I wanted to call out a couple of things:

Jan de Boer wrote:This until finally two years ago I told my brother in law to slow down and let me take notes. Then I made the evil thing called documentation, you could even call it a manual. And to make it even worse…we printed it out on paper. Can you imagine? Paper? The thought alone. We now print out the manual every time we visit and our problem is solved. But, helas, we are so totally not agile. Preferring documents over human contact, we must be autistic!

Anyone who tells you that agile teams never use documentation doesn't really understand agile very well. Like it says in the Agile Manifesto, we value working software over comprehensive documentation – but we still value comprehensive documentation. Not just documentation... comprehensive documentation.

Based on the things that you've said, like this:

Jan de Boer wrote:That is agile, write nothing down, be interrupted constantly, and you can say everything because we are a team and we do retrospective, but if you complain about agile, you are a bad programmer.

it makes me think that you're working on a team that has agile zealots as members. In my experience, an agile zealot is typically someone who found that doing agile in a very specific way solved some problems they've had in the past. Then they think, "Aha! I've found the magic formula that will solve every project problem!" and insist, loudly, that this is the One True Way of doing agile, and loudly shout down any deviation from their way of doing things.

They are very frustrating to work with.

And, worse, many of us have gone through a zealot phase ourselves. It's often part of growing and learning, I think. So I'm sympathetic, but it doesn't keep me from wanting to occasionally wring their necks when I meet them.

I hope you get a chance to work with an effective agile team in the future. I think you'd enjoy it, and find it to be a very different and much more positive experience than the team you're describing.

First of all, Jeff, I'm sorry that you had to put up with that sh*t. Agile practices are just tools, and like any tools they can be abused. Your managers are trying to control the uncontrollable. They fear that they won't deliver what's expected and they distrust the team, so they try to lock them into commitments by assigning durations and closely monitoring everyone on the team. It's a terrible atmosphere – and a highly counterproductive one, because that kind of pressure causes people to take shortcuts and cut corners. The code is probably full of all sorts of hacks because

And it's terrible for the team. A lot of times, people on teams feel like this:



That image is from our chapter in Head First Agile on Lean and Kanban.

A lot of people forget (or never really understood in the first place) that agile is more than just a toolset; it's a mindset too. Scrum, for example, works really well in an environment where the team is trusted, where people feel comfortable being open about their work, where they're allowed to focus on their work and not asked to multitask unreasonably, where they're allowed to openly question things, and where they're generally treated with respect. In an organization where those things aren't valued, Scrum doesn't work so well. It still works, in that the project gets managed, but it feels... well, exactly like you described.

So what do you do? Try to talk about these things with your management. Or... well, honestly, you don't necessarily want to do that, because in a lot of companies it's a good way to be fired. We talk about "CYA culture" in Learning Agile, where there's a culture of blame, where sh*t rolls downhill, and where you need to constantly protect yourself from blame. Agile doesn't work well in an environment like that; a strict waterfall process is a much better choice. ("The project is late, but it's not my fault! I followed the plan and the requirements specification. Someone else screwed up"!)

I'm reminded of the story in which O'Sensei was challenged to a sword duel by a naval officer. The officer attacked O'Sensei repeatedly with his bokken. He attacked over and over again. O'Sensei simply stepped aside for each attack, not allowing any to fall. Eventually, the naval officer got exhausted and dropped his bokken. O'Sensei later said: "Budo (the Martial Way) is not felling the opponent by our force; nor is it a tool to lead the world into destruction with arms. True Budo is to accept the spirit of the universe, keep the peace of the world, correctly produce, protect, and cultivate all things in nature."

It would have been easy to see you as an opponent, and to view what you wrote as an attack or criticism of our book. Some of the readers did, indeed, call it a condemnation. But I decided not to take it that way; I see you as a partner, not an opponent, and your post was just your own way of participating in this forum.

But just as the naval officer learned an important lesson, maybe there are lessons you can learn from this encounter as well. One lesson might be that some of your the forum members have said that it would be valuable to give me and Jenny a chance to reply, rather than automatically replying to every post. Jenny and I are writers; thus, it sometimes takes us some time to reply, as we like to think through our responses before writing them. It is up to you whether or not you want to give us the opportunity to gather our thoughts before adding your own input to each thread.

What a wonderful question! Jenny and I have been writing about use cases, user stories, and requirements for a really long time. This is a favorite topic of mine – we talked all about use cases in our first book, Applied Software Project Management, and if you Google for "user story use case" this blog post from 2009 called "Requirements 101: User Stories vs. Use Cases is one of the first things that pops up! That actually goes into a lot more detail, with examples of a user story and a use case to help you see the difference.

"Software requirement" is a large category. I'm sure you looked up the Wikipedia page for software requirements, which has the IEEE definition of the term "requirement." (That's a good definition—take a seciond and read the very top of the page.)

And now we'll make it really simple: a  requirement is something that the software is supposed to do. Something that we require of the software that we're going to build... hence the term "requirement." But there are a couple of things that we need ti keep in mind about requirements:
* One way to measure quality is to see how well the software your team builds meets the requirements. From this perspective, testing means making sure each requirement is met.
* But there's another aspect to this: fitness to use – what you build actually needs to be usable under the conditions that your users will use it.
* At the most basic level, your requirements have to meet the needs of your users. Requirements are a tool to help you do that,

Use cases and user stories are types of requirements.

So what's the difference between them? One really simple way to think about it is that user stories are about the user, and use cases are about the software.

A user story is a really simple tool that tells you about one specific user need. If you want to see some examples of user stories, here's a handout I used in a training session last month (PDF) that includes a bunch of user stories from a fictitious ATM (cash machine) project. Here's one called "Fast cash withdrawal" from that PDF:



A use case shows one specific interaction between a user and the software, with a series of interactions between a user and the system – and also the system and other systems. For example, a use case that implements this use case might have a set of steps like this (this is off the top of my head, so apologies if it's buggy!) – you'll notice that the ATM is interacting with both the user and other systems:

Precondition: Bank customer has entered her PIN

Step 1. ATM looks up the user's preferred fast cash withdrawal amount from a back-end preferences system

Step 2. ATM provides a set of options that includes a "fast cash withdrawal" option that indicates the amount looked up in step 1

Step 3. Bank customer indicates that she wants to withdraw cash

Step 4. ATM contacts the back-end system that manages the accounts and initiates a withdrawal for the amount looked up in step 1

Step 5. Bank customer takes the money

Step 6. ATM displays a prompt to continue the session, print the receipt and end the session, or don't print the receipt and end the session

Step 7. Bank customer indicates that she wants to print the receipt and end the session

Step 8. ATM prints the receipt and ends the session

Postcondition: ATM resets itself and waits for the next customer

The use case might have alternative paths (e.g. the user continues the session or doesn't print the receipt in step 7). But notice that this use case is mainly about how the system will operate. Ideally, it shouldn't constrain the design – for example, this use case doesn't include words like display a menu, so the developer working on a feature that has an audio prompt for visually impaired people isn't constrained by the word "display."

I know this didn't have a lot of metaphors, which you specifically asked for. But hopefully the examples helped!

To respond to the original questions:

nick woodward wrote:I'm currently learning to develop software and was wondering if this book is good from that perspective rather than from a managerial role? Also what methodologies does it cover? O'Reillys shop doesn't seem to cover either of these. Apologies if these are ill informed questions, I've just started looking into the area and the headfirst books are always a good place to start.

Pete Letkeman wrote:I would also like to know the answer to this as I’ve been a (pretty much the single) developer for a one stop shop.
Does this book give the developer like me a place to start with Agile development?

Yes yes yes! You guys are absolutely who Jenny and I had in mind when we wrote this book. I'm a hardcore developer. I've been writing code since the 1980s, I have a degree in CS from Carnegie Mellon, and I still write code all the time. I spent most of today writing Scala code. One of our books, Head First C#, is entirely about programming.

We try to aim our books at as wide an audience as possible, but I always have developers in mind whenever I write anything. Developers have a really finely tuned BS meter, and Jenny and I really work hard not to set it off.

Our goal with this book is to teach you the basics of agile, covering Scrum, XP, and Lean/Kanban in a way that would give you enough to actually put them in place on a real-world project. We've spend many years working on ways to explain these things, and from the feedback we've gotten so far, I think we've done a pretty good job of it. I really hope you get a chance to read it and judge for yourselves!

Hi Junilu,

It looks like you've been working with XP for a long time. I have, too – I still have the paperback edition of "XP Explained" on my bookshelf that I bought back in 2000, along with a bunch of other books about XP. So I get what you're saying, I really do.

I want to point out something that Alistair Cockburn (another one of my all-time favorite authors, along with Kent Beck) said in "Agile Software Development: The Cooperative Game" (one of my all-time favorite books):

Kent Beck, author of Extreme Programming Explained (Beck 2000), described the use of Extreme Programming (XP) using similar levels. Asked about XP and the five levels of the Software Engineering Institute’s “Capability Maturity Model,” he replied with XP’s three levels of maturity:
1. Do everything as written.
2. After having done that, experiment with variations in the rules.
3. Eventually, don’t care if you are doing XP or not.
(Safari link)

He talked about this in the chapter on shu-ha-ri. You probably already know this, for others reading it, this a really effective model for learning, teaching, and coaching. It tells us that when we first encounter a new concept, we need some basic rules. Eventually we learn the deeper system, and at some point, if we're lucky, we gain a deep understanding and can just do without thinking.

We wrote this book for people who are new to agile. Everything is taught at the "shu" level – we teach rules, and give some hints about the deeper system. Clearly, you already understand XP. But until someone understands the basic practices, principles, and ideas, they'll have no idea how to even process the things that you're talking about.

So... do you have as much expertise in Lean and Kanban as you do in XP? If not, would you like to learn it? If we dove straight into the depths of the mathematics behind measuring and limiting flow, someone who doesn't understand Kanban would be lost. So we start at the beginning, and get far enough so that the reader can actually take what we teach and use it at work.

This is the approach that we took to all of the topics in the book: the basics of agile, Scrum, XP, Lean, and Kanban. I think we did a pretty good job, and people we really respect – like Mike Cohn, who left us an amazing Amazon review – seem to think we did a pretty good job too.

But no, we're not going to plumb the depths of XP to the level that books beyond "XP Explained" do. That's not what we set out to do.

I wanted to respond to two things that you said:

As a developer, my view of agile software development is skewed mostly towards the technical practices like pair programming, test-driven development, refactoring, and continuous integration. Kent Beck, Jeffries, Fowler, Martin, and others like them had a more developer-oriented focus: they wanted to make developers' lives better and work more enjoyable. Software quality and simplicity was definitely something that was highly valued and there was strong focus on technical excellence.

One of the big points that we make is that if you see things just from the perspective of a developer, you miss a lot. Agile is all about bringing together many perspectives. We make this point over and over again. And honestly, from everything you've posted, I think there are some really interesting team-oriented aspects of XP, things that make it really, really effective. You may already have a very firm grasp of them, but even if you do I encourage you to open your mind and try to see things from the perspective of, say, a project manager, team lead, or product owner.

I'm not condemning the book in any way, I'm just giving my honest impressions. The book looks like it covers a wide range of topics from principles, Scrum, XP, Kanban, Lean, etc.

The posts you wrote really come across as condemning to me – obviously I'm biased, and clearly this is just my own opinion! – and from the responses I'm seeing in this thread, I think other people are drawing the conclusion that an expert in agile thinks our book isn't worth reading. That definitely stings. Our past CodeRanch promotions were definitely met with a much warmer reception. Still, I'll do my best to answer the questions and respond to as many comments as I can – mainly because I'm really passionate about helping people to learn agile (which is the whole reason that Jenny and I write these books).

Thanks,
Andrew