Learning Agile

by Jennifer Greene, Andrew Stellman

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. 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 About the Authors Andrew Stellman is a developer architect speaker agile coach project manager and expert in building better software. He has over two decades of professional experience building software and has architected large-scale real-time back end systems managed large international software teams been a Vice President at a major investment bank and consulted for companies schools and corporations including Microsoft the National Bureau of Economic Research Bank of America Notre Dame and MIT. He s had the privilege of working with some pretty amazing programmers during that time and likes to think that he s learned a few things from them. Jennifer Greene is an agile coach development manager business analyst project manager tester speaker and authority on s

Genres: Business, Programming, Nonfiction, Management, Computer Science, Reference, Technology

442 pages, Paperback

First published December 10, 2013

About the author

Librarian Note: There is more than one author in the GoodReads database with this name.

(3)brain-friendly guides

Reviews

[Маріанна Хлівненко · Rating 5 out of 5]

Ця книга розповідає про найпопулярніші agile-підходах - Scrum, ХР (екстремальне програмування), Lean (бережливе програмування) і Канбан. Вона познайомить вас з методами, які працюють в повсякденному житті, а також з базовими цінностями і принципами, які допоможуть вашій команді повністю змінити свій підхід до роботи над проектами. Ви почнете краще розбиратися в конкретних agile-підходах і зможете відразу скористатися їхнім досвідом на практиці. А головне, ви зрозумієте, як перетворити групу співробітників, що додають в свою роботу Agile, в справжню команду, яка дійсно покращує спосіб створення продукту і домагається видатних результатів.

[Jeanne Boyarsky · Rating 5 out of 5]

“Learning Agile” was an awesome book. It introduces Scrum, XP, lean and kanban nicely with good examples an narratives. This was not your serious “animal series” O'Reilly book. In addition to numerous cartoons and diagrams, I even spotted a Head First style image and two xkcd comics.

What's called Chapter 1 introduces agile followed by what would traditionally be the introduction.Interesting seeing those two reversed. It works though as it shows the points of view of different readers. I like how each chapter ends with FAQs, exercises you can today and ideas to learn more. The key point boxes sprinkled through each chapter were helpful as well.

I'm particularly impressed with how they handled the names of characters in Chapter 2. When I saw the characters introduced I groaned thinking it was one of those books where I would have to keep track of who these people are. But there was enough context for it to be obvious. And when they referred to them at the end of the chapter, their titles were restated. The authors even told us at the end of the story that we wouldn't be seeing them again. After that, I trusted that the narratives would be easy to follows and wasn't disappointed.

I liked the phrases “better-than-not-doing-it” and “magical thinking”. For me, the test of an agile or process book is whether I finish with ideas of new things to try. And I do.

---
Disclosure: I received a copy of this book from the publisher in exchange for writing this review on behalf of CodeRanch.

[Peter Vozhdai · Rating 5 out of 5]

Definitely recommended peace of reading on Agile topic. Helps to create right agile mindset. Good work on covering agile Values, Principles and Practices as well as for each methodology mentioned. Full with practical recommendations. Provide solid theoretical basis.

[Anna · Rating 4 out of 5]

Comprehensive and well-rounded :)

[Jung · Rating 3 out of 5]

Learning Agile (2015) is a no-nonsense guide to an often misunderstood concept – agile. The reason for that misunderstanding is simple: all too often, agile is bandied about as a one-size-fits-all solution to every conceivable organizational difficulty. Longtime agile practitioners Andrew Stellman and Jennifer Greene don’t see it that way. For them, agile is a great tool, but you have to know how – and when and why – to use it. And that starts with getting a grasp on agile’s underlying principles.

Andrew Stellman is a developer, architect, speaker, agile coach, project manager, and expert in building better software. He has over two decades of professional experience building software, and has architected large-scale real-time back end systems, managed large international software teams, been a Vice President at a major investment bank, and consulted for companies, schools, and corporations, including Microsoft, the National Bureau of Economic Research, Bank of America, Notre Dame, and MIT. He’s had the privilege of working with some pretty amazing programmers during that time, and likes to think that he’s learned a few things from them.

Jennifer Greene is an agile coach, development manager, business analyst, project manager, tester, speaker, and authority on software engineering practices and principles. She’s been building software for over twenty years in many different domains including media, finance, and IT consulting. She’s worked with teams of excellent developers and testers to tackle tough technical problems and focused her career on finding and fixing the habitual process issues that crop up along the way.

---

An introduction to agile.

Customers don’t always know what they want – or need. As Henry Ford once put it, if he’d asked people what they wanted, they would have said “faster horses.”

Of course, Ford gave them cars. But imagine if he hadn’t. Years would have been wasted trying to satisfy that demand. Chances are, by the time Ford’s product hit the market, someone else would have already started selling cheap, reliable cars. His product would have been dead on arrival.

In this book, we’ll be talking about software development, not cars. But we’ll be looking at the same problem. That problem can be summed up in a single question: How do you deliver a valuable product to your customer, even if they can’t tell you what they really want or need?

One answer is the bundle of practices and principles known as agile. If you’ve heard that word before, you’ve probably also come across some related concepts – like scrum, kanban, XP, and lean. Oftentimes, there’s a temptation to rush into discussing these methodologies right alongside agile.

For Andrew Stellman and Jennifer Greene, the authors of Learning Agile, that risks putting the cart before the horse. There’s no point in getting into the nitty-gritty, after all, if we haven’t shown why you and your organization should even consider agile in the first place. So that’s what we’ll be doing in this book: looking at the why of agile.

To do that, we’ll follow a project from start to finish. Along the way, we’ll see how agile principles can help a team of software developers work more efficiently and effectively – and deliver a better product.

---

You can’t design good software in a vacuum.

Let’s talk about e-book readers for a second.

It’s easy to see why they’re so popular. The object itself is about the size of a regular paperback, but it holds thousands of books. Even better, every text is responsive to you, the reader. You can enlarge the words, change the font, or skip back and forth between the main text and references. With a single click, you can access libraries and catalogs; with another click, you can borrow or download new books onto your device.

In short, this is great software. It’s well designed. Convenient. Intuitive. It satisfies every stakeholder. Readers find it easy to use, and it displays texts accurately, which is important to authors. It also helps booksellers and publishers sell and distribute books.

The first e-book readers didn’t do all these things, though. In fact, it took over a decade of development before the software got to where it is today. Back in the early 2000s, it wasn’t clear what would make an e-book reader valuable. We only know that today because hindsight is 20/20 – which brings us to our little thought experiment.

Let’s go back in time. Imagine we’ve been tasked with developing the software to display electronic books on brand-new handheld devices. How will we approach our task?

Well, we’re actually going to do it in the worst possible way because this isn’t the kind of company that’s exploring new ways of building software. This is an old-school operation, with leaders who lead and followers – that’s us, the developers – who follow. In short, this isn’t the kind of office where you’ll hear the word “agile.” So let’s see how things play out.

The hardware team has already made a prototype. Picture a chunky black tablet with a USB port for loading books and a fiddly little keyboard for interacting with the reader. It’s up to us to build the software that will display e-books on this gadget.

Our company applies what’s known as a waterfall process to its projects. What that means is that projects are front-loaded. All the product requirements are defined at the outset. As we said, leaders lead and followers follow. All the stakeholders – the senior managers, publishing representatives, online retailers, and so on – sit down and and hash out a plan. They outline requirements and come up with a specification that ticks all their respective boxes. Every other stage of the process, from design to development and testing, flows downstream from these decisions just as a body of water flows downstream from a waterfall.

So what’s in the specification? In a word, everything. This e-book reader is going to be revolutionary. It’s going to have tons of features. It’ll capture market statistics for publishers. It’ll have an internet storefront for readers to buy books. Authors will be able to preview and edit their books as they write them. And it’s all going to be ready in 18 months.

Fast-forward a year and a half. Since this is a thought experiment, we don’t have to be realistic, so we’ll say the project is completed on time. And it’s all there – every requirement in the specification has been implemented, tested, and verified. Everyone’s happy.

Can you guess what happens next? The reader hits the market . . . and it flops. Hard. No one buys it.

What went wrong?

The thing is, people’s needs aren’t static – they change with the times. If your only choice is a horse, you want a faster horse. But a horse, no matter how fast, isn’t much use if everyone else is already driving cars. Similarly, the software that people needed 18 months ago isn’t the software they need today. Since our project began, a new industry standard for e-books has emerged. No retailer wants to publish our unstandardized format – it’s too much bother. And so none of our revolutionary features are supported, which means they’re no use to anybody.

This also means we’ve wasted lots of time and money creating software that’s not very valuable. So what should we have done differently?

---

Release imperfect software today, and you’ll end up with a better final product tomorrow.

Here’s where we went wrong: we were unresponsive. We spent 18 months working in a bubble to implement a plan that was out-of-date before it even reached the market. There were no adjustments. We weren’t flexible. Our project, in short, wasn’t iterative.

An iterative design process doesn’t take place in a vacuum. Instead, it rolls out products quickly, getting them to customers as soon as possible and gathering feedback. That feedback is the basis for improvements, which are then sent back to customers – again, as quickly as possible – so they can provide new feedback. At that point, the cycle restarts. To iterate, after all, means “to perform repeatedly.”

This feedback loop is at the heart of agile processes. Think about the word “agility” as we use it in everyday language. It describes a way of moving quickly and nimbly – of being responsive to the environment and engaging with what’s in front of you. An agile climber, for example, responds to every hand- and foothold they encounter. They make rapid adjustments to prevent slips and fumbled grips. It’s the same with agile in software design. Agile teams use iterative processes to respond quickly and nimbly to bugs and mix-ups as they encounter them. They might not build the software they set out to build, but that’s a whole lot better than building something useless.

So there’s the first principle of agile. We can phrase it like this: The highest priority is to satisfy the customer through early and continuous delivery of valuable software.

Now, let’s break that principle down even further.

Software can only be built in the real world – the world of imperfect humans. Even the hardest working teams miss important details. The most talented developers fail to anticipate vital requirements. The only way we can correct mistakes is to put the software we’re building into the hands of customers – the people who’ll actually be using it. As developers, we’re entirely dependent on their feedback. That’s why we need to release software early.

Releasing software early isn’t just an antidote to perfectionism – it delivers value for customers. If they have a single feature today, however buggy, they can do something they couldn’t yesterday. By actually using a product, they can clarify their needs. That means they’ll be able to give us a clearer idea of what they want a product to do. And once we’re locked into this feedback loop, we’re on the road to creating a final product that actually satisfies those needs.

---

Embracing change is all about adopting the right mindset.

So there’s the answer to the question we asked earlier – what we should have done is put our software into the customers’ hands, so they could actually use it and give us feedback. If we’d done that, we would have realized there was a problem and changed course. That would have saved us the time, effort, and money we put into building an expensive dud.

Of course, changing course midway through a project is easier said than done. In practice, it’s usually a painful and unpleasant experience. You’ve made the difficult decisions. You know what you’re building. You know what your customers expect. Your workflow is established. It’s not plain sailing, exactly, but you’re making progress. And then someone from outside the project comes along and says that you’ve been on the wrong path the whole time. That all that planning and work was for nothing. That you have to circle back and start again. Worse, the person telling you to change course is the same person who put you on that path in the first place! They told you to build one thing, and now that you’ve built half of it, they’re telling you to do something else. It’s demoralizing – disrespectful, even. No wonder you get defensive and resist making changes.

Understandable? Sure. Helpful? Not at all. The important question is though, how can you get past this feeling?

Well, it’s a question of mindset, and it has two parts. The first is accepting that it’s really hard to build valuable software if you’re not constantly checking – and revising – your priors. Yes, changing course halfway through a project is frustrating, but it’s nowhere near as deflating as reaching the end of a project and realizing you’ve built a piece of junk.

The second part is about perspective, and it takes the form of an exercise.

This isn’t always an easy exercise – it requires a cool head and more empathy than you might want to extend to the person who’s just ruined your day. But it can be illuminating. Start by asking yourself these two questions: First, did your customer deliberately send you down the wrong path? Probably not, right? And second, how did they feel when they realized they screwed up and cost you months of work? Chances are, they were pretty embarrassed. They probably didn’t want to come to you and admit their mistake. It’s a good thing that they did, though – they’ve just saved you even more wasted time! And it’s not just your deadline that’s been blown. Your client’s timeline is delayed now, too. Their company is spending good money to build software that meets its needs, and this mistake means the project isn’t delivering. In other words, this is frustrating for everyone.

When you get down to it, you’re both in a difficult position. The only way you could theoretically avoid screwups would be to read your customer’s mind. Your customer, in turn, would have to be able to predict the future. In an ideal world, you’d both be able to do those things. But software isn’t built in an ideal world; you won’t be working with telepathic clairvoyants. Accept that, and mistakes – along with the changes they bring – will be much easier to deal with.

---

Iterative processes keep you in touch with your customers.

OK, let’s go back to where we started. How can the agile principles we’ve explored help our troubled e-book reader project? Let’s find out by running the project again.

First, let’s remind ourselves why that reader flopped. It lacked some important features used by competing e-book readers, like supporting an industry standard format. Note, however, that this problem couldn’t have been predicted – or avoided. When our team went to work, there was no industry standard. Our emphasis, then, has to be on the team’s responsiveness to what it finds out once its work has already started.

This time, the project is going to be agile. We’ll start with a big meeting where we’ll hash out the requirements and specifications, but we’re not going to stick to that plan for 18 months straight. Instead, we’ll divide that year and a half into one-month sprints – a single cycle of the feedback loop we discussed earlier. Put differently, we’re going to update our design in response to feedback every month.

There’s not going to be much to test at the beginning, of course, so we’ll fast-forward to the fourth sprint. When the project manager, team, and stakeholders meet, one of the developers reports that there’s a new industry standard for e-book formats. The team incorporates this new information into its next sprint and builds a library that supports the new format. By the sixth sprint, it’s ready to incorporate that format into the reader’s user interface.

As you can see, each sprint roughly maps onto each iteration or version of the software the team is building. So let’s skip to month eleven – the eleventh sprint and the eleventh iteration. We now have a working build, which can be loaded onto the prototypes the hardware team came up with. It’s buggy, but it’s good enough for real-world testing, which is exactly what the team wants. When the project manager talks to the software’s early users, she learns that they’d like to be able to email newspaper articles and PDFs to their devices. That’s the focus for the team’s next sprint.

This approach isn’t just about testing and incorporating new features, however – some features can also be discarded. For example, maybe that internet storefront doesn’t make sense. There’s a standardized e-book format, after all, so we don’t have to create a unique platform of our own. That’s handy because it frees up time to work on other, more important features.

This version of the project is much more likely to end well. We’ve been continuously releasing software for real-world testing and making timely changes in response to those tests. The big difference here is that we’re in touch with customers and users. When we used the waterfall process, we were completely sealed off from these groups once the project’s requirements had been approved. This time, though, we haven’t lost sight of our ultimate aim: building valuable, working software that satisfies real needs. And that’s the why of agile.

---

There are lots of ways of working agile, but every approach rests on the same core principals. The first is responsiveness. Agile processes are all about feedback. You don’t wait until the end of a project to test the software you’ve built – you get it out there as soon as possible. Real-world testing identifies problems early and helps your customer clarify what they need that software to do. The second principle? There’s no such thing as the perfect plan. Every project will require ad-hoc fixes, changes, and redesigns. But that’s a good thing – it’s how the best software gets built.

[Stanislav Mekhonoshin · Rating 5 out of 5]

I've enjoyed reading this book. It is an excellent introduction into Agile for beginners. If you've used some Agile approaches before, but you are not able to explain its formal ideas to other people then this book is for you.
It will not impress experienced Scrum Masters and Coaches, but it will work as an excellent guide into an Agile world for beginners.
Every chapter has a list of related reading, so I've fulfilled my reading list for the next several months for sure.

The Russian edition was not perfect, and I got the impression that translators made it a bit boring. I'd recommend you to read it in English.

[سامح السيد · Rating 4 out of 5]

I already have some experience with agility, but this book added some value to me.
I liked the following topics/ideas:
- The importance of agile values, and principles in achieving astonished results
- We can still see agile "better-than-nothing" results if we follow practices only without having the mindset behind them
- Coaching tips everywhere in the book
- Kanban methods for process improvement
- The authors story-telling style of writing

I think the book will deserve 5 stars if it contains a section/chapter about agile criticism.

[Игорь Громов · Rating 5 out of 5]

В ситуации, когда в компании уже в каком-то виде присутствуют гибкие методологии, Agile очень часто отождествляют со скрамом. Эта книжка очень подробно рассказывает, что полагаться исключительно на скрам в деле внедрения гибких подходов нельзя. Если вы оказались в очаге agile-революции, то прочитать «Постигая Agile» нужно обязательно. Это драматически повысит ваши шансы на успех в деле внедрения гибких методологий и вывода их на максимальную производительность.

[Tung Dao · Rating 4 out of 5]

A good book for fundamentals of Agile. Each chapter goes with format:
- Description
- Example (Act)
- Key notes
- What can I do
- Coach
However book is unnecessarily long. Writer could have written much shorter.

[Paul · Rating 3 out of 5]

Read about half of it, selectively. Good stuff.

[Mila Ley · Rating 5 out of 5]

Эта книга запускает Agile по венам.

Не просто сборник чистых практик, она настраивает на радио волну и учит мыслить по Agile. Предоставляет большое количество тематической литературы, в конце каждой главы ключевые моменты, практики как для менеджеров, так и для коучей. Очень структурировано написано.

После Книги «Думай как математик» я использовала практику с этой книгой выписывая вопросы для самопроверки. Возможно кому-то пригодится.

Постигая Agile
1. Что такое Agile?14
2. Какие области традиционного программирования?14
3. Agile мировозрение включает..14/15
4. Как решить проблему с ежедневными митингами?
5. Что такое спецификация? 32 (BRUF)
6. Составляющие модели водопада? 32 (ТДРеалПО)
7. Почему водопад не эффективен и когда он полезен? 34
8. Test driven development? 39
9. Что такое user story (epic)? 43
10. Основные идеи agile манифеста? 50
11. История о 6ти слепых и слоне? 56
12. Что такое тайм боксинг? 62
13. Что такое agile методологии? 64
14. Что такое роялти?
15. Какие 4 этапа принципов Agile? (ПКВС) 70
16. Каковы 12 принципов гибкой разработки? 70
17. Что такое CYA-среда? 92
18. Основной принцип проектирования KISS? 99
19. Почему зависимость одного кода от другого является пагубным? 100
20. Какие примеры баз небольших автономных единиц для дизайна архитектуры классов ПО? 101
21. Что такое инкрементальный дизайн? 102
22. Какие 3 вопроса на daily scrum-meeting? 110
23. Какие 2 вопроса при ретроспективе? 114
24. Расскажи басню про свинью и курицу? 120
25. Scrum ценности? (ПУСОМ) 133
26. Что такое петля обратной связи? 138
27. Что такое инкрементальная разработка? 148, 156
28. Каким подходом является scrum? 148
29. Что такое итеративная разработка? 148, 156
30. Что такое цикл ОКА во время ежедневных scrum-meeting? 149
31. Что такое коллективная ответственность? 170
32. Как выглядит шаблон пользовательской истории? Зачем нужно оценивать истории в очках? 172, 188
33. Что такое критерии удовлетворённости? 174
34. Что такое диаграмма сгорания? Почему она должна быть открытой? 179, 188
35. Как происходит процесс покерного планирования? 202
36. Какие есть практики XP программирования? 211
37. Что такое модульные тесты? И программирование через модульные тесты? 212
38. Какие есть практики XP интеграции? 213
39. Какие есть практики XP планирования? 215
40. Какие есть командные практики XP? 216
41. Что такое осматическая коммуникация? 217
42. Что значит адаптация к изменениям в XP? 219
43. Как предотвратить изменения? 226
44. Что такое качество приложения? 228
45. Ценности XP? (КПОМУ) 232
46. Принципы XP? (Очень много) 239
47. Сравнение по практикам scrum и XP? 241
48. Практики следствия в XP? (Очень много) 253
49. Масштабная цель XP-практик, ценностей и принципов? 257
50. Что такое читерский клудж? 259
51. Привед�� пример антипаттернов (кода с душком)? 265,266
52. Что такое платформенная ловушка? 269
53. Как избежать платформенной ловушки? (YAGNI You ain’t gonna need it) 270
54. Что такое рефакторинг кода? 276
55. Что такое технический долг? 278
56. Что такое временной запас? 278
57. Влияние рефакторинга на итеративное планирование? 279
58. Что такое система быстрых неудач? 281
59. Что такое монолитная архитектура и чем она характерна? 283,284
60. Что такое инкрементальная архитектура в XP как пример целостных практик? 285, 286,
61. Что такое энергичная работа как пример целостных практик? 288
62. Что такое единая команда как пример целостных практик? 291
63. Перечисли все практики XP? 292
64. Что такое утилиты и какой это вид архитектуры? 294
65. Что такое интеграционные тесты? 297
66. Что такое возникающая архитектура? (Муравейник) 297
67. Ценности Lean? 313
68. Составные ценности «раскрепощение команды»? 316
69. Что такое вариативное мышление в Agile? 317,319
70. Что такое разработка на основе установок и А/Б тестирование? 321,322
71. Что такое «магическое мышление и сознание «героев»? 326
72. Примеры ценности «ликвидируйте потери»? 330
73. Что такое «карта потока ценностей» по «минимальной маркетинговой функции»? 333
74. 2 инструмента внутренней целостности? 335
75. Что такое «воспринимаемая целостность»? 335
76. Что такое «концептуальная целостность»? 336
77. Как вычисляется метрика «времени выполнения»? 340
78. Каково использование метода «пяти почему»? 341
79. Цель теории «массового обслуживания»? 343
80. Что такое «wip-diagrams(work in progress)”? 345
81. Примеры 3х видов потерь «муда», «мура» и «мури»? 352-353-354
82. В чем заключается связь Lean и Канбан? 362
83. Что значит системное мышление? 370
84. Что такое «карта жизненного цикла» и ее отличие от «потока создания ценности»? 372
85. Кто разработал Канбан? 373
86. Что такое WIP-limit? 382
87. Что такое поток? 388
88. Что такое кумулятивная диаграмма потока (cumulative flow diagram,CFD)? 389
89. Отличие CFD от WIP диаграммы? 389, 390
90. По закону Литтла при стабильной системе производства для всех рабочих элементов чему будет равно среднее время производства W (WIP-лимит)? 392, 393
91. Что такое этапы СюХаРи? 431, 433

[Ahmed Hathout · Rating 5 out of 5]

"Learning Agile" is a comprehensive guide to various agile methodologies, including Scrum, XP, Lean, and Kanban. This book is an excellent resource for anyone looking to develop their agile skills and practices.

One of the book's key strengths is how it provides detailed explanations and examples of each methodology, enabling readers to understand how to apply them to their own projects. The authors explain the principles behind each methodology and provide practical advice on how to implement them effectively.

For example, the book covers Scrum in depth, discussing its roles, artifacts, and ceremonies, as well as providing guidance on how to run effective sprints and retrospectives. Similarly, the book explains the key concepts behind XP, such as continuous integration, test-driven development, and pair programming, and how to use them to deliver high-quality software.

In addition to covering specific methodologies, the book also emphasizes the importance of continuous improvement and collaboration in agile development. The authors provide guidance on how to run effective retrospectives and how to promote open communication and collaboration within agile teams.

Overall, "Learning Agile" is an essential resource for anyone looking to improve their agile skills and practices. Its coverage of various methodologies, including Scrum, XP, Lean, and Kanban, makes it a valuable guide for anyone seeking to implement agile development in their projects.

[Synthia Salomon · Rating 2 out of 5]

This rating is based on my interest level… not the authors’ writing skills or knowledge. Learning Agile (2015) is a no-nonsense guide to an often misunderstood concept – agile. The reason for that misunderstanding is simple: all too often, agile is bandied about as a one-size-fits-all solution to every conceivable organizational difficulty. Longtime agile practitioners Andrew Stellman and Jennifer Greene don’t see it that way. For them, agile is a great tool, but you have to know how – and when and why – to use it. And that starts with getting a grasp on agile’s underlying principles.

An introduction to agile.

Iterative processes keep you in touch with your customers.

There are lots of ways of working agile, but every approach rests on the same core principals. The first is responsiveness. Agile processes are all about feedback. You don’t wait until the end of a project to test the software you’ve built – you get it out there as soon as possible. Real-world testing identifies problems early and helps your customer clarify what they need that software to do. The second principle? There’s no such thing as the perfect plan. Every project will require ad-hoc fixes, changes, and redesigns. But that’s a good thing – it’s how the best software gets built.

[Greg Burrell · Rating 4 out of 5]

A good overview of Agile methodologies. Most companies seem to practice their own variation of Scrum or XP with maybe some Lean thrown in. Its easy to pick and choose the practices you like and ignore the ones that seem too hard or don't feel like a good fit for your team. This book explains the practices that go with each methodology, why they're important, and the pitfalls you might encounter if you choose to ignore them. This is a good book if you're looking to review your team practices (and we should all do that periodically). You'll probably discover you may have started out intending to do Scrum but then grew lax in some practices. Those pain points you're feeling may be the result. This book also did a great job of not pitting Kanban against Scrum and XP because its almost orthogonal to those. I did, however, come away unclear on the exact differences between Scrum and XP. I had to go back, reread, and flip back and forth between chapters to get a better picture of that.

[Matheus Marabesi · Rating 5 out of 5]

This is the kinda of book that I wish I had read(or should I say listened?) when I started in the software world.

A well crafted introduction to the most popular ways of structure agile: scrum, xp and kanban. And of course, the lean mindset that brings the idea to eliminate waste whenever possible.

Reading(or listening) this book won't make anyone an expert, but will provide a common ground to understand when and how to use different pieces of each one of them in the daily work - the book is based on story telling, making real scenarios that happened in any day of a software development team.

For non-programmers and the like out there, this is the start point to get the feet a bit out of the "I know agile because I do "scrum" or because I do daily stand up.

This book is the opening door for the values rather than the do's of agile.

[Glenn Schmelzle · Rating 4 out of 5]

In the last 10 years, Agile & associated practices have risen from obscurity to dominate how many businesses manage work. Though written in the early days of Agile, this book gives a thorough explanation of its concepts. Due credit is given in the book to other approaches, and this matters because many companies implement a blend of concepts for their particular workflow.

Just after a theoretical concept is covered, there's a mock-runthrough featuring a recurring cast. They show the pure folly of waterfall project management. These stories highlight how humans react to new work structures, and caution you not to think that Agile will simply work because you start using its techniques. They help show how a team acts differently when they have an Agile Mindset.

[Dmitrijs Prigodics · Rating 5 out of 5]

Прекрасная книга, описывающая в целом систему Agile. Начинает со скрама (куда ж без него?), продолжает extreme programming'ом и уходит в Lean с Kanban. Весьма основательно, с примерами, с литературой для дальнейшего изучения, с отдельными вопросами по теме, повторением ключевых моментов и советами. Читаешь, думаешь о своем проекте, идеи разные в голову лезть начинают, где там что предложить можно команде, самому внедрить, а почему нельзя... Из книги вытащил список на возможное прочтение величиной в 30 пунктов. То есть, "Постигая Agile" - это хороший старт в методологии, одновременно и объемлющий тему, и предлагающий пути для дальнейшего постижения. Вот после этого можно и Майка Кона "Agile. Оценка и планирование проектов" почитать, там уже все о тонкостях настройки Scrum'a говорится.

[Vino Sen · Rating 4 out of 5]

I've really enjoyed reading this book. Primarily, it focuses on Scrum, XP, Lean and Kanban models along with their values and practices. There are plenty of examples and real-time situations to help understand agile development.

Each chapter are well structured and goes with the format:
- Description
- Example (Actors)
- Key Points to take away
- FAQ
- What you can do today
- Where you can Learn more - References
- Coaching Tips

First 3 chapters explain the general phenomenal of Agile and its principles
Chapter 4 and 5 --> Scrum Specific
Chapter 6 and 7 --> XP
Chapter 8 --> Lean
Chapter 9 --> Kanban
Chapter 10 --> Agile Coach Tips

I liked the phrases “better-than-not-doing-it” and “magical thinking.

Highly recommended! Happy reading !!!

[Pablo · Rating 4 out of 5]

I think I'd still recommend Clean Agile above this book but only because it's shorter and showing one way. If you prefer to see a variety of alternatives then this book is better. Most of what I read seemed correct, reasonable, concrete, actionable. A good book with no fluff.

I forgot how much about XP was practices that today we just take for granted as the minimum basics of good engineering. I think it's interesting that XP got adopted so much the name is not even useful anymore, while adoption of other parts of agile (scrum, kanban, etc) come and go in waves (other than having a kanban(ish) board, how did we do anything before it?).

All in all, this is a good solid book and I recommend it.

[Taras Fedorov · Rating 5 out of 5]

Книжка оглядає і занурюються в основні методології Agile: Scrum, XP, Lean та Kanban.
Але основна задача книжки - не описати їх, а подивитися на принципи за ними.

• Чому просте "перетягування" практик приводить до результату "краще чим нічого"?
• Чому команди розчаровуються в Agile і скочуються в "щось схоже"?
• Як принципи та цінності йдуть перед практиками?
• Які кроки на проекті можна зробити вже зараз і що робити потім?
Ось на ці питання відповідає книжка.
А ще є, купа діаграм: burndown, WIP, CFD, карта потоку цінностей. І життєві приклади у стилі O'Reilly.

Рекомендую, хто хоче зрозуміти Agile, а ще більше людям, які "спробували в Agile" але зазнали невдачі.

[Ivaylo Petrov · Rating 5 out of 5]

For me it was a well-structured overview of Agile. You can learn things from it whether you are just trying to see what Scrum and XP are all about or you already have some knowledge about that and want to help your team get "better-than-not-doing-it results". A good number of external pointers can help you get even more information, should you want to dig deeper.

This book helped me fill some gaps and made me think more about my company's current process. Definitely worth the read :)

[franthormel · Rating 5 out of 5]

For someone who has never encountered any sort of Agile knowledge before, reading this book provided in-depth knowledge of the Agile methodology.

It properly discussed different tools to assist in project management, namely: Scrum, Extreme Programming, Lean mindset, and Kanban.

It also contains advice for any individual interested in pursuing to be an Agile Coach at the end of each chapter and a dedicated chapter at the end.

[Simon · Rating 5 out of 5]

Read after six months in a scrum or kanban environment

When you're ready to go back to the fundamentals, this book puts the team level Agile system in perspective.

Very helpful explanations of the most used agile flavours that will give you the mental building blocks to understand them all.

[Oksanalagovska · Rating 4 out of 5]

This book provides you with the good explanation of general Agile philosophy and main Agile software development approaches such as Scrum, Extreme Programming, Lean and Kanban. This well-structured guide, written in a light style, will be useful for those who begin to study Agile or already apply it in practice

[Pablo Margreff · Rating 4 out of 5]

Good book to introduce and give a detailed overview about most common agile methodologies. Gived me a awesome crash course about XP, the methodology which I had the lower domain.

The stories/cases used to reinforce the lessons make the sessions harmful and looks a little bit forced situations. On my point of view we don't need to read them.

Good book.

[Aaron Wiegel · Rating 4 out of 5]

Good introduction to agile

The book goes over several different agile methodologies along with their values and practices. There are plenty of examples and charts to help understand agile development. I did feel like the book was more directed at people who are using a waterfall process, while we already use agile at work and I wanted to just learn more.

[Anastasia Sidorova · Rating 3 out of 5]

Толстая книга, но полезного мало. Если вы уже в принципе знакомы c Agile, Lean и прочими методологиями, то читать нет смысла. Очень много воды, одни и те же мысли постоянно повторяются. Авторы преподносят это как фишку книги - как будто читатель так лучше усвоит мысль. Но факту просто бесит. Практических примеров очень мало.

[Anna Alexandrova · Rating 5 out of 5]

Очень классная книга для тех, кому интересна философия Agile или метод ведения проектов Scrum. Помогает понять не только, что делать, но и зачем с описанием ценностей и способа мышления членов команды. Также хорошо изложены все этапы и ошибки, с которыми вы столкнётесь при внедрении Scrum, XP, Kanban или Lean подхода. Must have к прочтению всех заинтересованных.

[Mims Zainal · Rating 4 out of 5]

Agile is an easy read. I practiced agile but this book gave a better perspective on why we implement the daily stand-up, retrospective etc in place. I had a better overview of agile after reading this one. Now inspired to put all the theory into practive. This is a challenge. All and all a good book to understand Agile in general.

[Preston Burns · Rating 4 out of 5]

Found this really helpful, filled in a lot of gaps (e.g. kanban as a process improvement methodology not just as a type of board). The idea that agile methodologies require both mindset + practice adoption was helpful, and helped me understand that some methodologies have failed in the past because practices were implemented alongside incompatible values and mindsets.