What do you think?
Rate this book
Zwinny samuraj. Jak programują mistrzowie zwinności
Podręcznik zwinnego zespołu!
- Czym wyróżniają się zwinne projekty?
- Jak działa zwinne planowanie?
- Co dają testy jednostkowe i ciągła integracja?
Konkurencja na rynku oprogramowania, oczekiwania klientów oraz tempo życia wymagają zmiany podejścia do wytwarzania aplikacji. Klienci nie chcą już czekać miesiącami na pierwszą wersję zamówionego produktu - chcą zobaczyć cokolwiek już za tydzień! Niemożliwe? A jednak! Jeśli zastosujesz zwinne praktyki, masz szansę błyskawicznie pokazać klientowi działające zręby aplikacji, a w kolejnych (krótkich!) iteracjach kolejne efekty. Zobacz, jaki wpływ na efektywność może mieć zwinność. Sprawdź, jak dobrać ludzi do zwinnego zespołu oraz jak nim zarządzać.
Jonathan w swojej książce zaprezentuje Ci wszystko, co musisz wiedzieć na temat zwinnych praktyk. Dowiesz się, jak ważny jest zespół, co go napędza i jakie role pełnią jego członkowie. Najpierw poznasz największe zagrożenia dla projektu i zalety tablic koncepcyjnych oraz przygotujesz się do rozpoczęcia fazy realizacji. Kolejne rozdziały zawierają niezbędne informacje poświęcone planowaniu, szacowaniu oraz zarządzaniu iteracjami. Dodatkowo na własne oczy zobaczysz, jak ważne są testy jednostkowe, refaktoryzacja oraz ciągła integracja w procesie wytwarzania oprogramowania. Książka ta jest idealnym źródłem informacji dla członków zwinnych zespołów oraz osób, które kolejny projekt chciałyby zrealizować z wykorzystaniem właśnie tej metodologii.
- Cechy charakterystyczne zwinnych projektów
- Role w projekcie
- Wskazówki w kwestii tworzenia zwinnego zespołu
- Tablice koncepcyjne
- Identyfikacja istotnego ryzyka
- Definiowanie celu
- Zbieranie historii użytkowników
- Szacowanie
- Planowanie
- Zarządzanie iteracjami
- Plan komunikacji
- Codzienny miniprzegląd
- Testy jednostkowe
- Refaktoryzacja kodu
- Programowanie oparte na testach
- Potencjał ciągłej integracji
Poznaj nowoczesne metodologie wytwarzania oprogramowania!
- Czym wyróżniają się zwinne projekty?
- Jak działa zwinne planowanie?
- Co dają testy jednostkowe i ciągła integracja?
Konkurencja na rynku oprogramowania, oczekiwania klientów oraz tempo życia wymagają zmiany podejścia do wytwarzania aplikacji. Klienci nie chcą już czekać miesiącami na pierwszą wersję zamówionego produktu - chcą zobaczyć cokolwiek już za tydzień! Niemożliwe? A jednak! Jeśli zastosujesz zwinne praktyki, masz szansę błyskawicznie pokazać klientowi działające zręby aplikacji, a w kolejnych (krótkich!) iteracjach kolejne efekty. Zobacz, jaki wpływ na efektywność może mieć zwinność. Sprawdź, jak dobrać ludzi do zwinnego zespołu oraz jak nim zarządzać.
Jonathan w swojej książce zaprezentuje Ci wszystko, co musisz wiedzieć na temat zwinnych praktyk. Dowiesz się, jak ważny jest zespół, co go napędza i jakie role pełnią jego członkowie. Najpierw poznasz największe zagrożenia dla projektu i zalety tablic koncepcyjnych oraz przygotujesz się do rozpoczęcia fazy realizacji. Kolejne rozdziały zawierają niezbędne informacje poświęcone planowaniu, szacowaniu oraz zarządzaniu iteracjami. Dodatkowo na własne oczy zobaczysz, jak ważne są testy jednostkowe, refaktoryzacja oraz ciągła integracja w procesie wytwarzania oprogramowania. Książka ta jest idealnym źródłem informacji dla członków zwinnych zespołów oraz osób, które kolejny projekt chciałyby zrealizować z wykorzystaniem właśnie tej metodologii.
- Cechy charakterystyczne zwinnych projektów
- Role w projekcie
- Wskazówki w kwestii tworzenia zwinnego zespołu
- Tablice koncepcyjne
- Identyfikacja istotnego ryzyka
- Definiowanie celu
- Zbieranie historii użytkowników
- Szacowanie
- Planowanie
- Zarządzanie iteracjami
- Plan komunikacji
- Codzienny miniprzegląd
- Testy jednostkowe
- Refaktoryzacja kodu
- Programowanie oparte na testach
- Potencjał ciągłej integracji
Poznaj nowoczesne metodologie wytwarzania oprogramowania!
272 pages, ebook
First published January 1, 2010
138 people are currently reading
1861 people want to read
Ratings & Reviews
Friends & Following
Create a free account to discover what your friends think of this book!
Community Reviews
Displaying 1 - 30 of 132 reviews
May 27, 2017
For some context, I'm writing this in 2017. This book was written at the height of the 'Agile' fad in 2010. Naturally, a lot has changed since then and somewhat unsurprisingly, this book hasn't aged that well. Most people have either moved on or improved upon many of the practices described in this book. If you've never worked in an 'Agile' environment before (which is highly unlikely by now, but still possible), this book is quite a good resource for seeing where many of the more modern practices evolved from and how the old folk used to work.
That's not to say that there aren't any more problems in the way software development is handled that this book actually addresses. Some issues like an overreliance on specification documents and treating estimates as anything other than a rough guess are still common frustrations that come up more often than they should. Even the way it suggests starting a new project with the use of an inception deck has some good ideas that I'm surprised aren't used more often, even if a lot of the steps themselves are unnecessary. The book does mention that every team is different and should take and adjust the practices and ideas as they need to which is another thing I find managers tend to forget, thinking implementing certain practices will result in overnight improvements.
The main issue I have with 'Agile' and even more modern approaches to software development is that it treats it like menial labour which can be reasonably accurately estimated and has almost no mental fatigue cost. So tools like velocity and burn down charts are a nice visual representation of how work has been progressing, but using them to extrapolate future progress is naive and overly optimistic in most cases and is why I almost never hear of anyone using them anymore. The one major thing that this book did remind me of is that 'Agile' is actually a project management tool and not techniques to make actual software development easier, efficient or more productive. There are some practices that try to improve on software quality, but they're either overly optimistic about their benefits, like TDD was, or get quickly sacrificed in favour of faster turnaround time, like refactoring and to some extent unit testing.
Some other issues I had with the book were things like the amount of unnecessary admin it advocates for, the lack of emphasis on team dynamics, implying that these practices in themselves are enough to deliver good software and calling certain statements 'truths' when they're far from that. This isn't a bad book by any means, it's just outdated and maybe a tad too optimistic. There's still a few things that one can gain from it, but I suspect there are newer books out there that are a lot more beneficial in getting the most out of delivering great software.
That's not to say that there aren't any more problems in the way software development is handled that this book actually addresses. Some issues like an overreliance on specification documents and treating estimates as anything other than a rough guess are still common frustrations that come up more often than they should. Even the way it suggests starting a new project with the use of an inception deck has some good ideas that I'm surprised aren't used more often, even if a lot of the steps themselves are unnecessary. The book does mention that every team is different and should take and adjust the practices and ideas as they need to which is another thing I find managers tend to forget, thinking implementing certain practices will result in overnight improvements.
The main issue I have with 'Agile' and even more modern approaches to software development is that it treats it like menial labour which can be reasonably accurately estimated and has almost no mental fatigue cost. So tools like velocity and burn down charts are a nice visual representation of how work has been progressing, but using them to extrapolate future progress is naive and overly optimistic in most cases and is why I almost never hear of anyone using them anymore. The one major thing that this book did remind me of is that 'Agile' is actually a project management tool and not techniques to make actual software development easier, efficient or more productive. There are some practices that try to improve on software quality, but they're either overly optimistic about their benefits, like TDD was, or get quickly sacrificed in favour of faster turnaround time, like refactoring and to some extent unit testing.
Some other issues I had with the book were things like the amount of unnecessary admin it advocates for, the lack of emphasis on team dynamics, implying that these practices in themselves are enough to deliver good software and calling certain statements 'truths' when they're far from that. This isn't a bad book by any means, it's just outdated and maybe a tad too optimistic. There's still a few things that one can gain from it, but I suspect there are newer books out there that are a lot more beneficial in getting the most out of delivering great software.
January 27, 2014
A very interesting read. I've been looking for ways to better manage my workload and get more out the door quickly; my mom's workplace has been agile from the start while my own follows a more traditional waterfall methodology.
This is by design; when your software mistakes might mean lives at risk or losses to a business in the hundreds of thousands, you tend to be cautious. It's also a product of a software company that's 30 years old- we have been building on our development methodology for a long time, and it's rare that processes get removed- they are generally only added. Our dev process is also very tightly coupled with our dev management software (in-house), which is useful for compliance issues but also ensures less flexibility. In my own role, I've dealt with many of the problems endemic to software development (though in my case it pertains more to report/warehouse dev and project management):
1) Too many bosses going in different directions
2) Difficulty managing workload and prioritizing appropriately; as a result- many projects 75% or 80% finished but struggling to get over the finish line.
3) Scope creep.
4) Poorly defined, ephemeral, constantly changing requirements.
In addition, a few specific to our situation:
1) Data integrity concerns when moving between hierarchical networked databases and relational models
2) Poorly designed data models
3) Lack of testing
4) Lack of developer resources.
I have been trying in the past to fix these problems by more rigidly adhering to certain development practices (e.g. insisting on a complete design prior to working on a report, trying to do thorough code review of legacy reports even when the QA note calls only for a cosmetic fix, etc.), but i have found that it hasn't helped as much as I liked. My main takeaways from agile then are more project management type insights than technical ones.
How you break down projects matters. It's not enough to just break stuff down into smaller pieces, you each project chunk should be relatively atomic and provide value. I often breakdown my projects, but they aren't organized like "user stories"- they're pieces that make sense to me as the dev.
Provide something of value every iteration. There's no such thing as 1/2 or 3/4 done. It's either done and usable by customers (in my case, internal customers), or it's not. It is better to deliver the minimum acceptable version of something and then iterate than to strive for perfection but never ship.
Requirements change. Thoroughly documenting doesn't prevent them from changing, it's just a tool for obstructing progress. Rather than saying, "Well, you asked for a report that did *X* six months ago, so that's what I gave you.", seek constant feedback and adjust requirements as necessary. Agile says, don't make your design to rigid to adjust (hence emphasis on "stories" rather than "requirements").
I'm particularly enamored of the Kanban method. Pioneered by Toyota, it is a visual project management tool that helps you understand your process flows and bottlenecks. It also helps achieve delivering something of value every week by limiting Work In Progress (WIP). I've known for a while one of my biggest costs was context switching. I exacerbate the problem by allowing more things to creep onto my "active" to-do list than I possibly have time for. Instead, I need to focus on relatively fewer things and get them done, rather than start a bunch of things but not drive them to completion. This is also a great tool to use externally and gives transparency to a role like mine, where I have many people giving me assignments and/or requests: I can clearly define what it is I'm working on, what state it's in, and where any new project is prioritized.
I'm excited to try out these methods in my work and especially to see if they can help us produce higher quality internal reporting tools in a faster and less painful way.
PS- I'm not going to comment on the cultural appropriation involved in the Samurai trope (as well as the dialogues with the agile Sensei). It's very clearly an homage to the style of zen teaching, and the Samurai is meant to convey a certain discipline, economy, and effectiveness, and it's probably, you know, not the most objectionable use of the trope, but I'm not sure it added value to the book and so seems like an unnecessary callousness.
This is by design; when your software mistakes might mean lives at risk or losses to a business in the hundreds of thousands, you tend to be cautious. It's also a product of a software company that's 30 years old- we have been building on our development methodology for a long time, and it's rare that processes get removed- they are generally only added. Our dev process is also very tightly coupled with our dev management software (in-house), which is useful for compliance issues but also ensures less flexibility. In my own role, I've dealt with many of the problems endemic to software development (though in my case it pertains more to report/warehouse dev and project management):
1) Too many bosses going in different directions
2) Difficulty managing workload and prioritizing appropriately; as a result- many projects 75% or 80% finished but struggling to get over the finish line.
3) Scope creep.
4) Poorly defined, ephemeral, constantly changing requirements.
In addition, a few specific to our situation:
1) Data integrity concerns when moving between hierarchical networked databases and relational models
2) Poorly designed data models
3) Lack of testing
4) Lack of developer resources.
I have been trying in the past to fix these problems by more rigidly adhering to certain development practices (e.g. insisting on a complete design prior to working on a report, trying to do thorough code review of legacy reports even when the QA note calls only for a cosmetic fix, etc.), but i have found that it hasn't helped as much as I liked. My main takeaways from agile then are more project management type insights than technical ones.
How you break down projects matters. It's not enough to just break stuff down into smaller pieces, you each project chunk should be relatively atomic and provide value. I often breakdown my projects, but they aren't organized like "user stories"- they're pieces that make sense to me as the dev.
Provide something of value every iteration. There's no such thing as 1/2 or 3/4 done. It's either done and usable by customers (in my case, internal customers), or it's not. It is better to deliver the minimum acceptable version of something and then iterate than to strive for perfection but never ship.
Requirements change. Thoroughly documenting doesn't prevent them from changing, it's just a tool for obstructing progress. Rather than saying, "Well, you asked for a report that did *X* six months ago, so that's what I gave you.", seek constant feedback and adjust requirements as necessary. Agile says, don't make your design to rigid to adjust (hence emphasis on "stories" rather than "requirements").
I'm particularly enamored of the Kanban method. Pioneered by Toyota, it is a visual project management tool that helps you understand your process flows and bottlenecks. It also helps achieve delivering something of value every week by limiting Work In Progress (WIP). I've known for a while one of my biggest costs was context switching. I exacerbate the problem by allowing more things to creep onto my "active" to-do list than I possibly have time for. Instead, I need to focus on relatively fewer things and get them done, rather than start a bunch of things but not drive them to completion. This is also a great tool to use externally and gives transparency to a role like mine, where I have many people giving me assignments and/or requests: I can clearly define what it is I'm working on, what state it's in, and where any new project is prioritized.
I'm excited to try out these methods in my work and especially to see if they can help us produce higher quality internal reporting tools in a faster and less painful way.
PS- I'm not going to comment on the cultural appropriation involved in the Samurai trope (as well as the dialogues with the agile Sensei). It's very clearly an homage to the style of zen teaching, and the Samurai is meant to convey a certain discipline, economy, and effectiveness, and it's probably, you know, not the most objectionable use of the trope, but I'm not sure it added value to the book and so seems like an unnecessary callousness.
May 24, 2017
Really enjoyed the simplicity of the explanations of what needs to be done to be agile, and why.
One mostly knows these things, but there are key points that was spot on.
Things like:
- When you say work is done, it is done. Tested & Ready for production
- You take ownership of your own work
- Writing tests to avoid things breaking, and to know that your change isn't breaking anything else
- Continuous integration & Deployment. Work must be Production ready at any point in time
- Engage / Communicate with Customer
- Engage with peers (Work with your neighbours in your neighbourhood)
- If something cannot be delivered in a week, then it is not scoped small enough
Don't do things because of the methodology, do things because they add value.
This book is a recommended read for everyone in the development pipeline Developer, Tester, BA, Manager, Ops, IT.
One mostly knows these things, but there are key points that was spot on.
Things like:
- When you say work is done, it is done. Tested & Ready for production
- You take ownership of your own work
- Writing tests to avoid things breaking, and to know that your change isn't breaking anything else
- Continuous integration & Deployment. Work must be Production ready at any point in time
- Engage / Communicate with Customer
- Engage with peers (Work with your neighbours in your neighbourhood)
- If something cannot be delivered in a week, then it is not scoped small enough
Don't do things because of the methodology, do things because they add value.
This book is a recommended read for everyone in the development pipeline Developer, Tester, BA, Manager, Ops, IT.
June 25, 2020
I went through this book as a professional development effort to obtain a greater understanding of Agile. I myself am not in an Agile environment (thankfully), but I do have counterparts that I work with who are. As such, I wanted to give this a go to learn more about it.
I really have mixed feelings about the Agile development process. One thing this book does is absolutely highlight the fact that Agile was created for software development. Which perplexes me as to why so many organizations that do not develop software, have adopted this as the one size fits all methodology for best business practices.
I feel like Agile is kind of like a 2nd Lieutenant (LT) (O-1) in the Army fresh out of ROTC/OCS. The LT has been through training, has read through numerous field manuals (FMs) and can tell you all about how "through his experience" things should be done... but when it comes down to it, he lacks the irreplaceable in-person experience of actual combat. Then, when his soldier's try to push back and say, "No Sir, that is not going to work." The LT is absolutely confused... because he read it in a manual, or was trained that way at West Point, or it looks so perfect on paper... how could it not be nothing but absolute truth?
Aside from that personal opinion and analogy above about what I think of Agile, I have heard numerous feedback comments from individuals who live Agile every day... and it's not pretty. Things like:
"We were actually more efficient using Waterfall."
"The point system is broken, it breeds laziness, as you can just accept not meeting deadlines and it is okay to just push things off to the next iteration... thus, things just keep getting thrown over the fence over and over again."
"Too many meetings."
"Agile was designed for software development.... why are we using it for our mission which has absolutely nothing to do with software dev?"
So on and so forth.
I don't understand the appeal of a string of buzzwords and constant short daily meetings throughout the day that interrupt workflow. A point system that is easily broken by "pop-ups." And why so many organizations are trying to make a software development methodology be a one size fits all solution for everything.
I will try my best to be open minded, and if I am ever directly part of an Agile working environment, to not come in with a sour attitude.
I really have mixed feelings about the Agile development process. One thing this book does is absolutely highlight the fact that Agile was created for software development. Which perplexes me as to why so many organizations that do not develop software, have adopted this as the one size fits all methodology for best business practices.
I feel like Agile is kind of like a 2nd Lieutenant (LT) (O-1) in the Army fresh out of ROTC/OCS. The LT has been through training, has read through numerous field manuals (FMs) and can tell you all about how "through his experience" things should be done... but when it comes down to it, he lacks the irreplaceable in-person experience of actual combat. Then, when his soldier's try to push back and say, "No Sir, that is not going to work." The LT is absolutely confused... because he read it in a manual, or was trained that way at West Point, or it looks so perfect on paper... how could it not be nothing but absolute truth?
Aside from that personal opinion and analogy above about what I think of Agile, I have heard numerous feedback comments from individuals who live Agile every day... and it's not pretty. Things like:
"We were actually more efficient using Waterfall."
"The point system is broken, it breeds laziness, as you can just accept not meeting deadlines and it is okay to just push things off to the next iteration... thus, things just keep getting thrown over the fence over and over again."
"Too many meetings."
"Agile was designed for software development.... why are we using it for our mission which has absolutely nothing to do with software dev?"
So on and so forth.
I don't understand the appeal of a string of buzzwords and constant short daily meetings throughout the day that interrupt workflow. A point system that is easily broken by "pop-ups." And why so many organizations are trying to make a software development methodology be a one size fits all solution for everything.
I will try my best to be open minded, and if I am ever directly part of an Agile working environment, to not come in with a sour attitude.
October 17, 2017
Nothing special. Book touches upon most of the aspects of agile project planning, easy to read and has plenty of examples in each chapter. As a developer who never worked with agile process, I expanded my understanding in some aspects but no revelations to be found in this book. If you read at least one book or couple of blog posts about agile, probably you are not going to learn anything new. But presentation is nice and somewhat entertaining so you may still like it.
June 30, 2017
I quite enjoyed this. It gave me some background to Agile processes that I haven't had before.
The master-student thing was really cheesy, but I managed to look past that.
The master-student thing was really cheesy, but I managed to look past that.
June 26, 2016
One of the best books on Agile software development that I have read. Its beauty lies in its simplicity: clear, down-to-earth guide through the Agile principles, planning, estimating, analysis, development, communication with clients, and testing. Some overall principles like honest communication with clients as early as possible, just-in-time and just-enough analysis, visualising your project and your pace of development are covered well throughout the book.
The book is also well illustrated: graphs and cartoons are helpful and make the point of the author even clearer.
The general "story wrapper" of the book - that a novice student is learning the Agile principles from a Samurai - was not very insightful, yet not disturbing. It could by and large just be ignored.
The book is also well illustrated: graphs and cartoons are helpful and make the point of the author even clearer.
The general "story wrapper" of the book - that a novice student is learning the Agile principles from a Samurai - was not very insightful, yet not disturbing. It could by and large just be ignored.
September 23, 2017
With Agile methodology, there's basically a template of ideas, rather than a set process that has to be followed. I do find Agile books are often a boring read or have deviated from the subject - and I have to say this is the best one so far. The content is good, and it is presented in a fun, easy to read style; I found myself whizzing through it. I also found it refreshing that some of the examples were situations that didn't go well for the author, rather than boasting about his achievements like authors often do. I've never heard of an “Inception Deck” but I think there is great value in this technique.
December 2, 2018
lots of interesting tidbits - as somebody using agile it was interesting to see how it 'should' be implemented and which things aren't 'really' part of it but my teams may have made up. It seemed mainly geared towards though who go through shorter project lifecycles. How to apply agile to consulting.
January 18, 2020
I can see the value from some of the agile methodologies. The continual focus on the customer is a necessary component of any product development and is vital to ensuring you don’t get stuck in “solving irrelevant problems” land. unit tests are great and save a lot of time preventing problems and with identification when things go wrong.
A couple of the things I’m not so sure about. Fluidity of roles. It seems to leave a lot up in the air, if everyone on the project is an expert in their field, leaving the final decisions of testing and whatnot up to “whoever” seems nice. Having worked on a variety of projects with a wide variety of teams, I know it to be a lot messier than that. A lot comes down to feelings and vague motivations. I’m still skeptical of the effectiveness of this. Also, there seems to be quite a bit of Jedi hand waving for problem solving in Agile. Maybe it’s specific to this book? I’m just exploring this concept. But “Go solve whatever needs to be solved” works well until it doesn’t.
A couple of the things I’m not so sure about. Fluidity of roles. It seems to leave a lot up in the air, if everyone on the project is an expert in their field, leaving the final decisions of testing and whatnot up to “whoever” seems nice. Having worked on a variety of projects with a wide variety of teams, I know it to be a lot messier than that. A lot comes down to feelings and vague motivations. I’m still skeptical of the effectiveness of this. Also, there seems to be quite a bit of Jedi hand waving for problem solving in Agile. Maybe it’s specific to this book? I’m just exploring this concept. But “Go solve whatever needs to be solved” works well until it doesn’t.
August 19, 2018
Super Valuable & Fun. With Agile Samurai you can have a really fun & precious introduction on Agile and also, really nice resources to explore more.
What I really enjoyed was the cool writing, technical books don't need to be boring & serious to be valuable, and the super useful tips.
Thanks Jonathan, for the tips and all the dialogues between Master and Student!
What I really enjoyed was the cool writing, technical books don't need to be boring & serious to be valuable, and the super useful tips.
Thanks Jonathan, for the tips and all the dialogues between Master and Student!
November 26, 2019
It’s a good book to understand the agile methodology, not only following the “book rule”, is more hands on showing real cases, I really liked this book.
April 23, 2022
book's written in a lighthearted manner, the visuals as well as allusions on martial arts, zen and dojo rooms helps making the concepts discussed more comprehendible. It is a good introduction that covers the basics in an easy to follow way. however, unlike many author popular reads its more on the XP (if not solely XP-centric) side rather than Scrum. here are some excerpts from the book I picked for future reference:
1. How Agile Masters deliver great software
2. Techniques should be proved in the trenches
3. The agile Samurai a fierce software-delivery professional capable of dispatching the most dire of software projects and the toughest delivery schedules with ease and grace
4. Agile is framework, attitude and approach to software delivery that is lean, fast and pragmatic
5. Inception deck – expectation – setting device in arsenal one should have
6. Deliver something of value every week
7. Start looking at software delivery from your customers point of view
8. Break big problems down into smaller ones
9. By delivering value every week you’re forced to get lean and drop everything that doesn’t add value
10. Make sure that everything works
11. Look actively for the feedback
12. When reality messes with your plan, you change your plan – not reality
13. You own quality, schedule expectations
14. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software
15. Master story list – is in essence to do list
16. Tasks – user stories
17. Master story list is the basis of the project plan
18. The engine for getting stuff done is iteration
19. Team velocity – measure and know how much you can get done in iteration
20. Being flexible and adaptive planning is a cornerstone of agile delivery
21. You don’t perpetuate the myth that things will magically turn around
22. Working software is primary measure of success
23. Three simple truths:
1. Impossible to gather all the requirement at the beginning
2. Requirements will surely change
3. There will be always more to do
24. Terms differ between XP and Scrum
1. Iteration – sprint
2. Master story list – product backlog
3. Customer – po
25. Agile team works like mini startup – people pitch in and regardless of title and role do whatever it takes to make startup work
26. Analysis coding design and testing are continuous they never end
27. There’s no QA dep, you’re it
28. Co-location – make team sit together
29. On-site customer and PO position demonstrate the importance of engaged customer
30. The Pixar Touch – buying spot for office helped them a lot
31. Win customer’s attention by making small deposits in the trust bucket
32. Self-organizing – look for people who can take initiative, who don’t sit back and wait for orders
33. Build projects around motivated individuals
34. Make team to demo their software to raise accountability
35. When recruiting for team, generalists are of a great value
36. Agile development team is a cross-functional group including analysts, developers, testers, DBA’s etc. who can make any feature into working soft
37. Analysts are needed to get how nitty-gritty details of desired features should work – the one asking deep probing questions
38. Analysts help write user stories, does detailed analysis makes sure we’ve done homework
39. Rubber hits the road when you code
40. Programmer turns user stories into working software
41. Tester helps write tests for upcoming stories – thinks of integration, exploratory, stress, load and security test
42. Project manager tracks how we are doing and communicates the state of the project, removes roadblocks
43. Start every project with 4 questions
1. What am I good at
2. How do I perform
3. What do I value
4. What results do you expect me to deliver?
44. Designers overlap with analyst and with collection of tools and techniques help creating compelling user experience
45. DBA’s and SA’s are also part of the team
46. Scrum masters are sort of agile coaches
47. Look for generalists, people comfortable in ambiguity people who can check their egos at the door
48. Assumption of consensus when none exists kills the projects most of the times
49. 10 questions to ask for inception deck
1. Why are we here
2. Elevator pitch
3. Product box
4. Not list
5. Meet the neighbours
6. Show solution
7. Up at night
8. Size it up
9. What’s going to give
10. What’s going to take
50. One has to discover commanders’ talent – masters go and see
51. I would have written you a shorter letter
52. Your project community is always bigger than you think – blind men and the elephant
53. Build relationships before you need them
54. Draw the board of the technical solution
55. You pick architecture when you pick team
56. To a team with big hammer everything looks like a nail, team strong in DBs will do most heavy lifting in SQL
57. Co-located teams, engaged customer, desired development environment
58. The time to talk about risk is now – at the beginning
59. Two types of risks worth sweating and those that aren’t
60. Randy Mott of Wal-Mart insisted that no development cycle should take over 6 months
61. Uat – user acceptance testing
62. Furious four of the project: (interwoven and connected)
1. Time
2. Budget
3. Quality
4. Scope
63. Timebox-fix time
64. Reducing quality is like juggling flaming machetes on a cold winter day
65. This 4 forces not all can be No.1
66. Try to name other forces too
67. Assemble you’re a-Team UX designer, PM, Developers, Analyst, Customer, Tester
68. 8 px3 ¼ months @$100/hr = $416k budget (160 hr/month)
69. Think if you were a head honcho and decide whether this project is a go
70. User story – makes every agile project
71. Premature upfront analysis is a great waste of time
72. Only documenting has downsides – volume, lack of communication and misinterpretation
73. Face-to-face communication is best for conveying information
74. Agile user stories are more profound than it seems
75. INVEST – user stories
1. Independent
2. Negotiable
3. Valuable
4. Estimable
5. Small
6. Testable
76. For story gathering workshop one has to get a big open room
77. Ten to 40 good user stories should be enough for 3-6 months planning
78. Spend more time talking to your customer about requirements than writing it down
79. Concentrate on understanding on your customer
80. Estimates can never give accurate predictions
81. Estimation is needed to determine whether project targets are realistic
82. Initial estimates can vary by as much as 400%
83. Stories sized relatively to each other and a point based system to track the progress is needed to make planning work
84. Estimating relatively is something we humans are very good at
85. Use point based system and don’t tie to elapsed time on calendar
86. Triangulation is about taking a few sample reference stories and sizing our stories relatively to these
87. Planning poker a game where development team estimates stories and then comparing together – wisdom of crowds
88. Planning poker isn’t voting system where 3 juniors outweigh one senior
89. Reality will always mess with your GANTT chart
90. Murphy’s law takes no prisoners when it comes to disrupting the best-laid plans
91. Another late over-budget IT project
92. Planning should be visible and honest
93. How many points per iteration and how many iterations to cover all master story
94. Treating initial plans as hard commitments is what kills projects before they started
95. Welcome changing requirements even late in development
96. Simplicity the art of maximizing the work not done
97. Stories should be minimal and marketable
98. Most people only use 5% of the features from MS Word
99. Team velocity means both stories completed/iteration story points/iteration
100. Done means story was analyzed, tested, designed and code
101. Be hard on dates but flexible on features
102. Burn down chart:
1. Work done
2. Work left
3. Velocity
4. Expected completion date
103. Burn up shows how many new features were added in backlog
104. a small, co-located team, with an on-site customer, isn’t’ going to need a lot in the way of formal documentation
105. medium sized and little spread out team will need a bit more description
106. when it comes to actual design world is our oyster
107. just in time and just enough are key to success
108. pair programming is useful because programming isn’t merely typing rework time is saved
109. high level smoke screen tests automate what you can
110. to-do->analysis->Dev->Test->Delpoy->Done
111. find root causes, create quality at place
112. analysis, development and testing all rolled up into one to deliver something of value every week
113. spm-story planning meeting
114. itm – iteration planning meeting
115. just in time analysis checkpoint meeting is spm
116. itm is sprint planning
117. mini retrospective at regular intervals team reflects on how to become more effective
118. retrospective prime directive is that we know everybody did their best job it’s not a witch hunt
119. ask what we’re doing really well and where do we need to do better
120. daily stand up – quick daily sync to get on same page
121. Old:
1. What you did yesterday
2. What you’re doing today
3. Is there anything slowing you down
122. New:
1. What you did to change the world today
2. How you’re going to crush it today
3. How you’re going to blast through the obstacles unfortunate enough to stand in your way
123. Declaring what you’re going to do dramatically increases the chances of you doing it
124. Get flight status boards: what’s coming what’s going and what’s being canceled
125. Usual workspace can help you set expectations with stakeholders
126. Story wall, release wall, velocity and burn down chart, inception deck should be making deck usual workspace
127. Inception deck is good to remind why the team is there
128. Dedicate 10% of iteration to bug squashing
129. Xp’s pair programming is controversial
130. Automated unit testing, refactoring, test driven development, continuous integration are so called no-brainers of agile software engineering
131. Before fixing bug write failing unit test
132. Unit tests lower the cost of regression testing
133. Tests everything that could possibly break
134. Unit testing becomes common in soft development there are frameworks almost in every language
135. Refactoring is paying down a technical debt
136. Like a house with a mortgage, software has debt that continuously needs to be paid down
137. Technical debt is continuous accumulation of shortcuts, hacks duplications and other sins we regularly commit against our code base in the name of speed and schedule
138. Technical debt- spaghetti code, excessive complexity’
139. When we refactor our code, we just improve code, make it more comprehendible and amenable to change
140. Treat big refactoring as any other user story
141. Refactoring isn’t rework, avoid thou shalt not refactor, do it as you go
142. Big end of project refactorings usually aren’t worth the pain because you won’t have the time to reap rewards
143. Writing tests first aids us as we stare at our blank canvas of code and wonder where it should all begin
144. Test driven development TDD
145. Write a failing unit test first what your code would like to do, think of design critically
146. Tdd circle of life – test fails, test passes, refactor
147. Don’t write any new code until you first have a failing test, this helps us to avoid over-engineering, not write more code then necessary
148. When writing test imagine the code you need to test already exists
149. One stroke may contain 6 design decisions – developers face complexity
150. Continuous integration is about being able to demo to anyone anytime anywhere
151. You want building integrating and deploying to be non-event
152. CI is taking changes devs made and integrating them altogether throughout a day
153. To set up CI you need:
1. Source code repository
2. Check in process
3. Automated build
4. Willingness to working in small chunks
154. Git or subversion for repository
155. A check in process involves:
1. Get latest and greatest code from repository
2. Making changes into it
3. Run tests make sure they pass
4. Get another update from repository to make sure it includes others’ if done
5. Run test again making sure your change works with others
6. Check in as all tests pass
156. Respect the final build, ensure it always runs and create automated build use tools like cruise control
157. Many languages have their automated test environments NAnt or MS-build for .NET, rake-Rails, Ant-Java, Dos bat files or UNIX script can help you to build your own
158. Willingness to work in small chunks is key to CI by minute
159. Production readiness is an attitude – software has to work today
160. Without unit testing, refactoring, TDD and CI you’re getting back to caveman days of code and fix
161. Are we delivering something of value every week?
162. Are we striving to continuously improve?
163. if both yes, you’re being agile
1. How Agile Masters deliver great software
2. Techniques should be proved in the trenches
3. The agile Samurai a fierce software-delivery professional capable of dispatching the most dire of software projects and the toughest delivery schedules with ease and grace
4. Agile is framework, attitude and approach to software delivery that is lean, fast and pragmatic
5. Inception deck – expectation – setting device in arsenal one should have
6. Deliver something of value every week
7. Start looking at software delivery from your customers point of view
8. Break big problems down into smaller ones
9. By delivering value every week you’re forced to get lean and drop everything that doesn’t add value
10. Make sure that everything works
11. Look actively for the feedback
12. When reality messes with your plan, you change your plan – not reality
13. You own quality, schedule expectations
14. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software
15. Master story list – is in essence to do list
16. Tasks – user stories
17. Master story list is the basis of the project plan
18. The engine for getting stuff done is iteration
19. Team velocity – measure and know how much you can get done in iteration
20. Being flexible and adaptive planning is a cornerstone of agile delivery
21. You don’t perpetuate the myth that things will magically turn around
22. Working software is primary measure of success
23. Three simple truths:
1. Impossible to gather all the requirement at the beginning
2. Requirements will surely change
3. There will be always more to do
24. Terms differ between XP and Scrum
1. Iteration – sprint
2. Master story list – product backlog
3. Customer – po
25. Agile team works like mini startup – people pitch in and regardless of title and role do whatever it takes to make startup work
26. Analysis coding design and testing are continuous they never end
27. There’s no QA dep, you’re it
28. Co-location – make team sit together
29. On-site customer and PO position demonstrate the importance of engaged customer
30. The Pixar Touch – buying spot for office helped them a lot
31. Win customer’s attention by making small deposits in the trust bucket
32. Self-organizing – look for people who can take initiative, who don’t sit back and wait for orders
33. Build projects around motivated individuals
34. Make team to demo their software to raise accountability
35. When recruiting for team, generalists are of a great value
36. Agile development team is a cross-functional group including analysts, developers, testers, DBA’s etc. who can make any feature into working soft
37. Analysts are needed to get how nitty-gritty details of desired features should work – the one asking deep probing questions
38. Analysts help write user stories, does detailed analysis makes sure we’ve done homework
39. Rubber hits the road when you code
40. Programmer turns user stories into working software
41. Tester helps write tests for upcoming stories – thinks of integration, exploratory, stress, load and security test
42. Project manager tracks how we are doing and communicates the state of the project, removes roadblocks
43. Start every project with 4 questions
1. What am I good at
2. How do I perform
3. What do I value
4. What results do you expect me to deliver?
44. Designers overlap with analyst and with collection of tools and techniques help creating compelling user experience
45. DBA’s and SA’s are also part of the team
46. Scrum masters are sort of agile coaches
47. Look for generalists, people comfortable in ambiguity people who can check their egos at the door
48. Assumption of consensus when none exists kills the projects most of the times
49. 10 questions to ask for inception deck
1. Why are we here
2. Elevator pitch
3. Product box
4. Not list
5. Meet the neighbours
6. Show solution
7. Up at night
8. Size it up
9. What’s going to give
10. What’s going to take
50. One has to discover commanders’ talent – masters go and see
51. I would have written you a shorter letter
52. Your project community is always bigger than you think – blind men and the elephant
53. Build relationships before you need them
54. Draw the board of the technical solution
55. You pick architecture when you pick team
56. To a team with big hammer everything looks like a nail, team strong in DBs will do most heavy lifting in SQL
57. Co-located teams, engaged customer, desired development environment
58. The time to talk about risk is now – at the beginning
59. Two types of risks worth sweating and those that aren’t
60. Randy Mott of Wal-Mart insisted that no development cycle should take over 6 months
61. Uat – user acceptance testing
62. Furious four of the project: (interwoven and connected)
1. Time
2. Budget
3. Quality
4. Scope
63. Timebox-fix time
64. Reducing quality is like juggling flaming machetes on a cold winter day
65. This 4 forces not all can be No.1
66. Try to name other forces too
67. Assemble you’re a-Team UX designer, PM, Developers, Analyst, Customer, Tester
68. 8 px3 ¼ months @$100/hr = $416k budget (160 hr/month)
69. Think if you were a head honcho and decide whether this project is a go
70. User story – makes every agile project
71. Premature upfront analysis is a great waste of time
72. Only documenting has downsides – volume, lack of communication and misinterpretation
73. Face-to-face communication is best for conveying information
74. Agile user stories are more profound than it seems
75. INVEST – user stories
1. Independent
2. Negotiable
3. Valuable
4. Estimable
5. Small
6. Testable
76. For story gathering workshop one has to get a big open room
77. Ten to 40 good user stories should be enough for 3-6 months planning
78. Spend more time talking to your customer about requirements than writing it down
79. Concentrate on understanding on your customer
80. Estimates can never give accurate predictions
81. Estimation is needed to determine whether project targets are realistic
82. Initial estimates can vary by as much as 400%
83. Stories sized relatively to each other and a point based system to track the progress is needed to make planning work
84. Estimating relatively is something we humans are very good at
85. Use point based system and don’t tie to elapsed time on calendar
86. Triangulation is about taking a few sample reference stories and sizing our stories relatively to these
87. Planning poker a game where development team estimates stories and then comparing together – wisdom of crowds
88. Planning poker isn’t voting system where 3 juniors outweigh one senior
89. Reality will always mess with your GANTT chart
90. Murphy’s law takes no prisoners when it comes to disrupting the best-laid plans
91. Another late over-budget IT project
92. Planning should be visible and honest
93. How many points per iteration and how many iterations to cover all master story
94. Treating initial plans as hard commitments is what kills projects before they started
95. Welcome changing requirements even late in development
96. Simplicity the art of maximizing the work not done
97. Stories should be minimal and marketable
98. Most people only use 5% of the features from MS Word
99. Team velocity means both stories completed/iteration story points/iteration
100. Done means story was analyzed, tested, designed and code
101. Be hard on dates but flexible on features
102. Burn down chart:
1. Work done
2. Work left
3. Velocity
4. Expected completion date
103. Burn up shows how many new features were added in backlog
104. a small, co-located team, with an on-site customer, isn’t’ going to need a lot in the way of formal documentation
105. medium sized and little spread out team will need a bit more description
106. when it comes to actual design world is our oyster
107. just in time and just enough are key to success
108. pair programming is useful because programming isn’t merely typing rework time is saved
109. high level smoke screen tests automate what you can
110. to-do->analysis->Dev->Test->Delpoy->Done
111. find root causes, create quality at place
112. analysis, development and testing all rolled up into one to deliver something of value every week
113. spm-story planning meeting
114. itm – iteration planning meeting
115. just in time analysis checkpoint meeting is spm
116. itm is sprint planning
117. mini retrospective at regular intervals team reflects on how to become more effective
118. retrospective prime directive is that we know everybody did their best job it’s not a witch hunt
119. ask what we’re doing really well and where do we need to do better
120. daily stand up – quick daily sync to get on same page
121. Old:
1. What you did yesterday
2. What you’re doing today
3. Is there anything slowing you down
122. New:
1. What you did to change the world today
2. How you’re going to crush it today
3. How you’re going to blast through the obstacles unfortunate enough to stand in your way
123. Declaring what you’re going to do dramatically increases the chances of you doing it
124. Get flight status boards: what’s coming what’s going and what’s being canceled
125. Usual workspace can help you set expectations with stakeholders
126. Story wall, release wall, velocity and burn down chart, inception deck should be making deck usual workspace
127. Inception deck is good to remind why the team is there
128. Dedicate 10% of iteration to bug squashing
129. Xp’s pair programming is controversial
130. Automated unit testing, refactoring, test driven development, continuous integration are so called no-brainers of agile software engineering
131. Before fixing bug write failing unit test
132. Unit tests lower the cost of regression testing
133. Tests everything that could possibly break
134. Unit testing becomes common in soft development there are frameworks almost in every language
135. Refactoring is paying down a technical debt
136. Like a house with a mortgage, software has debt that continuously needs to be paid down
137. Technical debt is continuous accumulation of shortcuts, hacks duplications and other sins we regularly commit against our code base in the name of speed and schedule
138. Technical debt- spaghetti code, excessive complexity’
139. When we refactor our code, we just improve code, make it more comprehendible and amenable to change
140. Treat big refactoring as any other user story
141. Refactoring isn’t rework, avoid thou shalt not refactor, do it as you go
142. Big end of project refactorings usually aren’t worth the pain because you won’t have the time to reap rewards
143. Writing tests first aids us as we stare at our blank canvas of code and wonder where it should all begin
144. Test driven development TDD
145. Write a failing unit test first what your code would like to do, think of design critically
146. Tdd circle of life – test fails, test passes, refactor
147. Don’t write any new code until you first have a failing test, this helps us to avoid over-engineering, not write more code then necessary
148. When writing test imagine the code you need to test already exists
149. One stroke may contain 6 design decisions – developers face complexity
150. Continuous integration is about being able to demo to anyone anytime anywhere
151. You want building integrating and deploying to be non-event
152. CI is taking changes devs made and integrating them altogether throughout a day
153. To set up CI you need:
1. Source code repository
2. Check in process
3. Automated build
4. Willingness to working in small chunks
154. Git or subversion for repository
155. A check in process involves:
1. Get latest and greatest code from repository
2. Making changes into it
3. Run tests make sure they pass
4. Get another update from repository to make sure it includes others’ if done
5. Run test again making sure your change works with others
6. Check in as all tests pass
156. Respect the final build, ensure it always runs and create automated build use tools like cruise control
157. Many languages have their automated test environments NAnt or MS-build for .NET, rake-Rails, Ant-Java, Dos bat files or UNIX script can help you to build your own
158. Willingness to work in small chunks is key to CI by minute
159. Production readiness is an attitude – software has to work today
160. Without unit testing, refactoring, TDD and CI you’re getting back to caveman days of code and fix
161. Are we delivering something of value every week?
162. Are we striving to continuously improve?
163. if both yes, you’re being agile
May 24, 2017
Muy bueno, dinamico y divertido para entender todo lo agile.
A veces creo que le faltó un poco de sazon en las bromas, pero es muy similar al tipo de lecciones que me gustan, muy recomendable!
A veces creo que le faltó un poco de sazon en las bromas, pero es muy similar al tipo de lecciones que me gustan, muy recomendable!
to-read-tier-2
June 5, 2022As recommended to me by Tony Ludwig
listening to this on audible on the bus into Boston.
The only basic Agile book I plan on reading.
listening to this on audible on the bus into Boston.
The only basic Agile book I plan on reading.
December 18, 2011
TL;DR: It's a quick read, suitable for people new to agile. Otherwise, go buy Agile Estimating and Planning instead.
This is a very lightweight and quick to read book, despite its length; I read it in a few hours on a flight, and I'm not a very fast reader at all.
Some people will not enjoy the light hearted and humorous style of the book. I didn't mind it - the style and silly diagrams certainly made it easier to get through than something like Agile Estimating and Planning.
All in all though, it's a good read for someone entirely new to agile methodologies, but has little concrete value for someone already using agile day-to-day, or someone who has read other books on the matter.
That said, it's probably a great book for a client or non-technical project stakeholder who is unfamiliar with agile.
Whilst I did get some value out of it, it was mainly just reminding me of some of the core ideals which are easy to loose sight of during a project. If you really want to get some strong, concrete advice about using agile, check out Agile Estimating and Planning, which is far longer and far more detailed.
This is a very lightweight and quick to read book, despite its length; I read it in a few hours on a flight, and I'm not a very fast reader at all.
Some people will not enjoy the light hearted and humorous style of the book. I didn't mind it - the style and silly diagrams certainly made it easier to get through than something like Agile Estimating and Planning.
All in all though, it's a good read for someone entirely new to agile methodologies, but has little concrete value for someone already using agile day-to-day, or someone who has read other books on the matter.
That said, it's probably a great book for a client or non-technical project stakeholder who is unfamiliar with agile.
Whilst I did get some value out of it, it was mainly just reminding me of some of the core ideals which are easy to loose sight of during a project. If you really want to get some strong, concrete advice about using agile, check out Agile Estimating and Planning, which is far longer and far more detailed.
March 13, 2016
A poorly focused and amateurishly illustrated introduction to Agile project management. While it can serve as a reasonable introduction to someone with no previous exposure to Agile, in the crowded field of Agile project management there must be other books that do the job better.
The book adopts a lighthearted delivery style with "master sensei and the aspiring warrior" anecdotes sprinkled throughout, but the anecdotes add little value. Conversely, some technical execution topics are given but a cursory treatment: the topics of test-driven development and unit testing are afforded ten pages each.
Illustrations take up a lot of the space in the book, making it a fast read. However, there is no consistent style to the artwork and most of the drawings reiterate points already made by the text without adding any insight.
The book adopts a lighthearted delivery style with "master sensei and the aspiring warrior" anecdotes sprinkled throughout, but the anecdotes add little value. Conversely, some technical execution topics are given but a cursory treatment: the topics of test-driven development and unit testing are afforded ten pages each.
Illustrations take up a lot of the space in the book, making it a fast read. However, there is no consistent style to the artwork and most of the drawings reiterate points already made by the text without adding any insight.
February 7, 2017
If you are new to software development, then reading this book should become one of your top priorities. Walking the agile path brings you across the "do not set false expectations" street. There's a route along "act early rather than late" road. You will go sightseeing at the agile dojo where Agile Sensei will share with you the agile reasoning that can give your project a higher chance for success.
When your career has already helped you see some agile practices, this book can help your refresh your skills. It won't make your world shake - like I said, there is no silver bullet - but it reminds you how you could handle certain situations. I think it's a must read for any software developer. And a must re-read in every 5 to 7 years.
Read the full review at my blog.
When your career has already helped you see some agile practices, this book can help your refresh your skills. It won't make your world shake - like I said, there is no silver bullet - but it reminds you how you could handle certain situations. I think it's a must read for any software developer. And a must re-read in every 5 to 7 years.
Read the full review at my blog.
April 12, 2012
If you're looking for a light introduction and overview of agile software development this is probably a good book for you. I think I'll have got some value from the earlier chapters but on the whole I felt it took a long time to describe things in too many different ways that often didn't really warrant the effort. For example, the "Master Sensei and the Aspiring Warrior" interludes didn't add much value and I started skipping them about 2/3 of the way through. I also ended up skimming through the unit testing, test driven development and continuous integration chapters as they were too generic and simplistic to be useful.
March 14, 2017
Really the best book I've read so far on Agility and Scrum! It gives lots of, easy to understand, examples. It really explains Agility based on its principles and does this with a sense of humor as well! I am quite experienced in Agility, and explaining Agility to others. This book has given me even more ways of explanation.
The only criticism I can think of, is the use of different terminology for the meetings and artifacts in the scrum framework. That will complicate explanation, when used in combination with other scrum-explaining video's i.e.
But really a great book I will advice to many new Agilists out there!
The only criticism I can think of, is the use of different terminology for the meetings and artifacts in the scrum framework. That will complicate explanation, when used in combination with other scrum-explaining video's i.e.
But really a great book I will advice to many new Agilists out there!
November 1, 2013
A very good friend recommended this to me - it's an interesting high level primer on Agile. Something that can be skimmed in a few hours if you are familiar with the subject matter, or read in a few nights.
This was a perfect introduction for me, as I'm new to agile (my work colleagues at work use it extensively). I got a few pages of notes out of it.
This was a perfect introduction for me, as I'm new to agile (my work colleagues at work use it extensively). I got a few pages of notes out of it.
May 16, 2017
A good introduction to agile, focusing on principles and practical advice. Like any book on agile, it does not get specific enough to put immediately into practice or to cover all scenarios. Easy to read and clear, with effective arguments for agile practices and frank acknowledgements of what causes software projects to fail.
September 3, 2017
A very solid introduction to agile software design. I have to give the author kudos for not getting religious about his particular agile methodology of choice, and presenting the leading choices equally.
March 12, 2019
I cannot say how I would feel about this book had I read it and not listened to it, but the audiobook narrator was obnoxiously annoying. For that reason alone, I cannot give this book a higher rating.
Read
August 13, 2016Easy to read and refreshing. Boosts motivation to become Agile.
Recommended for both novice Agile practitioners and their managers.
Recommended for both novice Agile practitioners and their managers.
July 26, 2012
a little heavy on the gimmicks. the pocket guide was better.
November 1, 2015
I didn't fancy this book. Too many generic examples I hoped for something more concrete. Felt more like mediocre school book than something to read for a seasoned developer.
March 8, 2020
Yet another agile book.
The Agile Samurai is another agile book that presents the agile principals as usual. But with two important twists: inception deck and a strong emphasis in co-located teams (it mention it is important, it mention the lack of colocation as a big risk for a project, etc).
I'll start by discussing the second. Co-located teams are restricting, it restricts the talent pool, it forces everyone to be at the same place, it creates an environment for interruptions running free. It is not easy to work with remote teams, but there are tons of examples of companies doing it (Basecamp, Gitlab – although Gitlab is kind of using it to pay some employees less for the same job).
The inception deck is the pearl in this book. It provides a nice way of presenting the project, discussing its risks and aligning stakeholders. Together with the recurrent demo, it allows great collaboration between the team developing the project and the community involved.
Once these two points are explored, what remains is a traditional agile book, which fails as most agile books. I normally agree with the agile principles, except by their intensity. Collaboration and interactions become recurrent long planning meetings, long reviews, long stand-up meetings, etc – and start to feel as micro-managing and controlling. And although the book says "start light, add weight as you go", it does a pretty good job of listing tons of documents and boards to be constructed and elaborated (flows diagram, burn-down chart, personas, user-story, one-pagers, etc, etc), not very light in my opinion.
Then, there is the agile fundamental flaw. Treating working software as done. And treating software as a project and not an evolving product. Working software is not done. Software is never done, it still must go into the customer's hands and the user must test it. Metrics and overall experience have to be been proven to work as expected. Then we might say it accomplishes its goals, but we still must monitor it, to see if the customer needs change and then adapt it if possible or through it away. The people who develop the software must own it. They must see it creating value to the customer and change it if it is not. It may work as expected (or spec'd), but does it deliver value? What the software does is what the user expected it to do? Are the users using it to solve their problems?
This is not supposed to be a rant at Agile. Agile practices are good, but they have become too overwhelming and a way too big of a thing. In my opinion, there are bigger problems: creating a common domain language that both developers and business people can understand and express themselves in it, for example – here I must confess that the books mention it, but it does not take much time. User research and prototyping are another. Metrics, tracking, and product validation are others.
Agile fits in a bigger subject that is product discovery and development. That said, shame on me for expecting different from an Agile book. ¯\_(ツ)_/¯
The Agile Samurai is another agile book that presents the agile principals as usual. But with two important twists: inception deck and a strong emphasis in co-located teams (it mention it is important, it mention the lack of colocation as a big risk for a project, etc).
I'll start by discussing the second. Co-located teams are restricting, it restricts the talent pool, it forces everyone to be at the same place, it creates an environment for interruptions running free. It is not easy to work with remote teams, but there are tons of examples of companies doing it (Basecamp, Gitlab – although Gitlab is kind of using it to pay some employees less for the same job).
The inception deck is the pearl in this book. It provides a nice way of presenting the project, discussing its risks and aligning stakeholders. Together with the recurrent demo, it allows great collaboration between the team developing the project and the community involved.
Once these two points are explored, what remains is a traditional agile book, which fails as most agile books. I normally agree with the agile principles, except by their intensity. Collaboration and interactions become recurrent long planning meetings, long reviews, long stand-up meetings, etc – and start to feel as micro-managing and controlling. And although the book says "start light, add weight as you go", it does a pretty good job of listing tons of documents and boards to be constructed and elaborated (flows diagram, burn-down chart, personas, user-story, one-pagers, etc, etc), not very light in my opinion.
Then, there is the agile fundamental flaw. Treating working software as done. And treating software as a project and not an evolving product. Working software is not done. Software is never done, it still must go into the customer's hands and the user must test it. Metrics and overall experience have to be been proven to work as expected. Then we might say it accomplishes its goals, but we still must monitor it, to see if the customer needs change and then adapt it if possible or through it away. The people who develop the software must own it. They must see it creating value to the customer and change it if it is not. It may work as expected (or spec'd), but does it deliver value? What the software does is what the user expected it to do? Are the users using it to solve their problems?
This is not supposed to be a rant at Agile. Agile practices are good, but they have become too overwhelming and a way too big of a thing. In my opinion, there are bigger problems: creating a common domain language that both developers and business people can understand and express themselves in it, for example – here I must confess that the books mention it, but it does not take much time. User research and prototyping are another. Metrics, tracking, and product validation are others.
Agile fits in a bigger subject that is product discovery and development. That said, shame on me for expecting different from an Agile book. ¯\_(ツ)_/¯
July 31, 2019
Clear, concise, and approachable overview of agile. As someone that's been involved in agile products for a couple of years now, there wasn't anything really groundbreaking for me, though it served as a great reminder of some core principles. It walks a pretty fine line of being both concrete enough to be actionable, yet abstract enough to apply to lots of different types of situations and roles.
This book does contain a vague 'samurai' theme as the name suggests, and I found the occasional interlude to be refreshing, and acts as a nice reinforcer of the key points of the book. Not nearly as high-octane goofy as say, a Head Start book.
I listened to the Audible version, which is generally excellent.
Recommended for new and seasoned agile practitioners alike.
This book does contain a vague 'samurai' theme as the name suggests, and I found the occasional interlude to be refreshing, and acts as a nice reinforcer of the key points of the book. Not nearly as high-octane goofy as say, a Head Start book.
I listened to the Audible version, which is generally excellent.
Recommended for new and seasoned agile practitioners alike.
August 26, 2017
Great intro to the concept of agile. A little cheesy with the"tests", but the piece that helps hit home in this book is that there really isn't a set methodology to how you implement agile. Too often in the business world we try to optimize and find the one singular best practice or process and this book helps the reader understand that there is no one way to implement it and that agile isn't a new process ... it's an ideology and a strategic shift in how we need to think about getting jobs done.
Displaying 1 - 30 of 132 reviews