HeadFirst Agile: target audience?

[nick woodward]

Hi Andrew and Jennifer,

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

Thanks,

Nick

[Pete Letkeman]

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

[Junilu Lacar]

I just had a quick look at the book contents on SafariBooks Online.

Based on a quick skim of the content, here are my initial $0.02:

1. The book seems to be mostly about high-level concepts (values and principles of agile s/d), process management, and mindset/attitudes. As with most books in the Head First series, there is a lot of introductory material and explaining about the approach to writing the book up front. I'm not saying that's bad but if you're like me and/or have read Head First books before, that's quite a bit of material that you can skip or quickly skim through, worth about 20-30 mins of reading (time based on estimates given by SafariBooks for each section).

2. The discussions about XP (Extreme Programming) practices focus on certain things that I believe either miss the point or gloss over more important things.

For the solo developer and someone who is not familiar with software development team dynamics and processes, this book can give you a broad, high-level view of a certain way of working (with agility). However, if you don't have a basis for comparison, that is, if you don't have previous experience developing software as part of a team, that lack of context will probably make the discussions less relatable, like someone trying to tell you how thrilling a new roller coaster ride is when you've never been on a roller coaster in your life. Without prior team development experience, the discussions will probably be interesting at best. I think the authors touch on some of this in the "Who should probably back away from this book?" section of the introductory material.

As for the discussions about XP practices, I think there are a few things that I would add.

The meeting at Snowbird UT in 2001 was driven primarily by an explosion of interest in XP and to some extent, Scrum. Kent Beck's "XP Explained: Embrace Change" and Fowler's "Refactoring" were published in 1999 and the ideas were getting a lot of attention in a certain section of the software development community. At least that's how I perceived it at the time. I heard about XP in early 2000 and I knew about Kent Beck, Martin Fowler, Ron Jeffries, Robert Martin long before I learned about Scrum and others in that group of 17 professionals and thought leaders of our industry.

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

(continued)

[Junilu Lacar]

These are some of the things about team/collaborative development that I didn't see discussed much, if at all, in the book:

1. Instant feedback / review of code that is written
2. Developing a shared mental picture and understanding of the code and design
3. Diversity of perspectives can be beneficial, to some extent
4. What exactly does "collaborative development" look like?
5. What are the driver and navigator roles in a programming pair?
6. Examples to illustrate how team development can be better than solo development.

The chapter about XP (117 mins reading time) appears to be the longest. That kind of got my hopes up but unfortunately, there's just too much about XP to cover thoroughly in one chapter. After Kent Beck's "XP Explained: Embrace Change" (the white book) came out, there were a number of follow-up books published that delved deeper into certain aspects of XP, like planning and testing. The TDD and pair programming practices spawned their own subset of books. While you shouldn't expect the book to do a deep-dive into all things XP, it would have been nice to see some mention of the things I listed above.

I took a closer look at the section in the book that talks about team programming and there's mention of flow and sustainability but I don't think those are things you can easily put into context without prior experience. Even people who try to do pair or mob programming can have some difficulty in getting into a rhythm and developing a "flow".

Here's what the authors wrote:

Team programming is social. It’s not an isolated activity.

Programmers don’t like being interrupted—and for good reason. When you’re on a roll coding, you get into a kind of “zone,” a state of high concentration where work seems to just flow. In fact, a lot of people have a name for this state: flow. It’s actually pretty much the same thing as when an athlete is “in the zone” (where players feel like the baseball is the size of a watermelon, or the basketball hoop looks like it’s 10-feet wide). This effect has actually been studied, and those studies found that it can take 15 to 45 minutes for a programmer to reach that state. An interruption, like a phone call or an annoying email, can completely break you out of flow. If you get two phone calls an hour, you can sit at your desk all day and get nothing done.

I have a bit of trouble reconciling the first two sentences (in bold) with the paragraph that follows. There's no real explanation of how team programming promotes flow. If anything, one might think that having to work with someone else or, in the case of mob programming, a few other people, on the same code around one display and one keyboard would impede rather than facilitate flow. That's probably what most developers who are used to working solo would think. So, ironically, I don't think the idea from the introductory sentences flows well with the paragraph that follows. That's unfortunate because I think there's a lot that even solo developers can get out of understanding the motivations, dynamics, and mechanics of team programming.

[Pete Letkeman]

Wow, okay thanks for that information Junilu.
After close to 15 years of being pretty much the sole programmer using ASP Classic I'm stuck trying to improve my skill set and I've noticed that many job postings state that they want the candidate to have Agile experience.
I was kind of hoping that this book could point me in the correct general direction. Do you think it can?

An interruption, like a phone call or an annoying email, can completely break you out of flow.

I've had this happen to me too many times to count. But when working in a small shop it's to be expected to a degree.

[Junilu Lacar]

Many job reqs have "Agile experience" on them but there really aren't that many shops that practice agile development well. Whenever I see "Agile" these days, I usually expect it to mean "Scrum" which is more about process management than anything else.

Here's what I keep telling people though: You can wrap the best management process around your technical practices but if your technical practices are not good, then the best you can get out of your "agile" practice is that you're delivering bad software more efficiently.

For me, true agility has to be anchored in technical excellence. Without it, you will only see short-term gains and even the gains you see initially will quickly disappear when you run into the problems that come with poor quality.

My recommendation to solo developers wanting to get started with agility is to learn Test-Driven Development (not a trivial task). To learn how to TDD well, you might want to first learn about refactoring. When you start learning about refactoring, you'll want/need to write more automated unit tests. When you finally step up to TDD with the unit-testing and refactoring skills you learned, then you have to learn more about Simple Design (see the Four Rules of Simple Design), patterns, principles, and then understand the mindset behind collaborative programming (I'll explain that next, if you want me to expound).

[Pete Letkeman]

TDD is something that I need to get better at, as this isn't something I've done too much of and not really required at my previous job.
The tools were not there and need was not clearly visible either.

Junilu Lacar wrote:(I'll explain that next, if you want me to expound)

No need, but thanks for the offer.

Thanks for all of your insights Junilu, I've found them very informative.
It appears as though you have come from a place with a lot of experience.

[nick woodward]

wow, great answer Junilu, thanks.

TDD is an area I've dodged and know I shouldn't have.... it's one of the pluralsight video series i never quite got to (and as with most of them it no doubt only scratches the surface). will definitely look into it.

as for distractions - i create enough of my own to worry about someone else XD

thanks again

[Junilu Lacar]

Pete Letkeman wrote:The tools were not there and need was not clearly visible either.

Not sure which tools you were missing. I have an IDE and JUnit. Those are pretty much all the tools you need to do TDD. Well, those and a version control system like Git or Subversion.

Care to elaborate?

[Junilu Lacar]

I don't want get into TDD too much here and digress from the original question of target audience so I will start another topic specifically about TDD.

[nick woodward]

also, just to confirm - most agile books are management material by their very nature? I only ask because  XP Explained: Embrace Change has had this same criticism levelled at in in it's amazon reviews.

I think I'll probably grab it regardless - although I'm keen on the 1st edition for £1.70 over the £25 second edition (ill check the changes though...)

Junilu Lacar wrote:I don't want get into TDD too much here and digress from the original question of target audience so I will start another topic specifically about TDD.

thanks

[Junilu Lacar]

nick woodward wrote:also, just to confirm - most agile books are management material by their very nature? I only ask because  XP Explained: Embrace Change has had this same criticism levelled at in in it's amazon reviews.

If would say that's a fair, if unfortunate, characterization of what's available on the market. Most books that have "Agile" in the title are indeed about process management like Scrum or Kanban.

Technical books that are related to agile software development often don't have "Agile" in their title. A notable exception is Robert Martin's "Agile Software Development: Principles, Patterns, and Practices" or the PPP book. However, if you really want to learn technical practices that good agilists follow, get books like "Understanding the Four Rules of Simple Design" by Corey Haines (one of the best books, IMO, about TDD), "Refactoring: Changing the Design of Existing Code" by Martin Fowler, "Refactoring to Patterns" by Joshua Kerievsky, and "Working Effectively with Legacy Code" by Michael Feathers (the WELC book).  There's also Nat Pryce and Steve Freeman's book, "Growing Object-Oriented Software, Guided by Tests" (the GOOS book).

These are just for starters. A couple of our retired sheriffs, Lasse Koskela and Ilja Preuss also have technical books that are very useful for developers who want to learn to be more agile.

[Pete Letkeman]

Junilu Lacar wrote:Not sure which tools you were missing. I have an IDE and JUnit. Those are pretty much all the tools you need to do TDD. Well, those and a version control system like Git or Subversion.

ASP Classic, which was born around 1999 uses VBScript aka VBA, and interpreted language.
The tools for creating ASP Classic files were:

Microsoft Visual Interdev

Microsoft FrontPage

Adobe DreamWeaver

Any Notepad type editor

In 2005 Microsoft released Visual Web Developer Express, which was a good step in the correct direction.
However Visual Web Developer Express did not support unit testing for ASP Classic.
Microsoft has since released Visual Web Developer Express 2008, 2010, 2012 and there is still not a lot of support for unit testing of ASP Classic.
There may be some now, but I'm not betting anything on that and it's properly not integrated into any IDE.

Often times, a unit testing framework is supported by the IDE, but Microsoft killed to IDEs (Visual Interdev, FrontPage) which supported ASP Classic.
Another issue was that the owner/my boss did not want to spend money on setting up a VCS server, which would require more hardware.
While I was the primary developer some people would make changes to typos and edit the CSS and these people did not want to learn more then they had to do their jobs.

So with no or not much of a TDD framework, lack of IDE and lack of a VCS test driven development was a no go.

[nick woodward]

nice, i'll definitely have a look at those books.

does the PPP book bridge the gap to some extent? or would I be better with XP Explained and seperate dev books? i only ask because despite asking about the technical side, I'm also helping a friend with his start up company at the beginning of next year, as an intermediary of sorts between him and his small dev team of 2 or 3. I did a decent amount about s/d processes in an information systems course many years ago, but never really dived into the agile side of things in great detail. I'm maybe naively assuming that as a small start up the principles can be applied in a rather adhoc fashion. This seemed to be at least the case for the project management methodologies I learned about back then, although I know that's somewhat different to the more narrowly focused s/d side of things


anyway, I'll probably start with Haines' book. thanks again for the information - and for scaring me with the "just for starters" phrase after naming 6 books!

nick

[Pete Letkeman]

Nick, just like me you were most likely drawn to post your initial question in hopes of winning the free book.
If like me, you have decided that thanks to Junilu insights that this book is not for you then you may want to opt out of the draw like I'm going to.
You can find out how to opt out by reading this post https://coderanch.com/t/684294/questioning-authors

I really do want to thanks Junilu for all of the insights shared in this thread,
Pete

[Piet Souris]

I've always found it impolite when an author is invited to answer questions about a published book, only to see that others reply, without giving the author the chance to reply first. Unfortunately, this happens on quite a regular basis. No one ever made a remark about this, so it could be just me feeling it this way. If so, so be it.

But I must say: this topic is extreme as far as (im)politeness goes. Condemning the book, withdrawing from the lottery, without even giving the authors a chance to answer. Gentlemen!

[nick woodward]

I understand where you're coming from, but I don't think it's condemning the book at all. I plan on checking it out initially via safari's trial to see if it's a good fit at least with my second requirement. I'm not withdrawing from the competition, I'd love to win the book - I won't - but I'd love to. As I said, headfirst books are always a good place to start, and I'm sure this is no exception.

However, as Junilu points out in reference to the original question there is a difference between books, and not just this one, that focus on project management and workflows rather than how to develop software. I don't think he meant it as a condemnation either.

[Junilu Lacar]

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

I welcome any input from the authors to correct any misperceptions I may have written in this thread. While we certainly would like to have the authors answer all the questions posted related to the book being promoted, I don't recall it being a matter of ranch policy to give them a chance to answer first before adding anything to the thread.  The last thing I'd expect an author who writes about Agile software development to be is defensive. If it were me, I would welcome an opportunity to learn what other topics readers might want to see more on in a future edition.

Also, I asked not to be included in the drawing for the book because I already have access to the book online through a Safari Books subscription. I would rather give others a chance to win a copy instead.

Did you ever stop to think that it may be impolite to imply that others have malevolent motives before getting clarification?

[Pete Letkeman]

Please note that I did not mean to offend anyone at all and if I did please let me apologize. I am well aware that everyone at CodeRanch and the authors do a lot of work for no money and sometimes for not even a "Thank You".
From what I can gather it does appear to me that Junilu has some insights that apply to me, and possibly not to anyone else.
I'm also under the impression that Junilu has read the book, or at least parts of the book.
I realize that not everyone receives the same value from the same book and that everyone has different experiences and situations.

I have chosen to withdraw from the promotion not because the quality of the book, the book however does not appear to help me out as I may have expected it to.
Also withdrawing gives others a chance to win this book without my name in the mix, thus changing the odds however slightly.
These others may will probably make better use of this book at this point in time then me.
I have actually privately withdrawn from two maybe three other book promotions and still contributed to the conversations on the topic at hand.

I only publicly mentioned withdrawing as it appear as though the OP was looking into other books based on Junilu recommendations.
I realize that the OP does not have to, and I was not expect them to, withdrawn from the promotion.
I am not expecting anyone to withdraw from the promotion, however some people may not know that this is an option.

[Junilu Lacar]

Here's what the authors wrote about the target audience:

Who is this book for?
If you can answer “yes” to any of these questions:

1. Are you a developer, project manager, business analyst, designer, or other member of a team, and you’re looking to improve your projects?

2. Is your team going agile, but you’re not really sure what that means or how you fit in?

3. Are you thinking about a job search, and want to understand why employers are asking for agile experience?

4. Do you prefer stimulating dinner-party conversation to dry, dull, academic lectures?

this book is for you.

Also, the authors wrote that if you're studying for the PMI-ACP exam, then the book is definitely for you.

And if you're wondering about question 4 above, I think that pertains to the general style of the Head First book series rather than anything specific to agile development.

As for how much value a developer might get out of this book, if you're looking for specific things to learn regarding pair-programming, unit testing, and TDD, then I don't think you'll get much of that. The discussions around these practices seem to be more high level and related to principles, values, and overall benefits rather than mechanics and specific techniques. In other words, you probably won't learn much about how to do pair-programming, unit-testing, or TDD from reading this book. It's geared more towards answering the what and why of the practices, in my opinion.

[Pete Letkeman]

Thanks Junilu, once again.

[Andrew Stellman]

Hi Junilu,

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

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

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

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

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

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

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

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

I wanted to respond to two things that you said:

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

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

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

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

Thanks,
Andrew

[Andrew Stellman]

To respond to the original questions:

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

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

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

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

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

[Junilu Lacar]

Hi Andrew,

Thanks for your reply. I, too, have Alistair's book and the appendix about Shu Ha Ri was my favorite part of it. It was especially meaningful to me since it also resonated with me as a student of Aikido.  

Yes, I often have to look at things from the management perspective. However, my primary focus in things technical in our agile practice stems mainly from the fact that developers are often caught up with learning process side of the house when they are first brought on board in this journey of adopting Agile/Scrum. This tends to draw their focus away from the technical side of the house. I try to act as a balancing force, reminding everyone that developers mustn't forget their primary job: to produce valuable software, and that include paying attention to quality and good engineering practice is just as important as transparency and communication with product owners and stakeholders.

[Jeanne Boyarsky]

Piet Souris wrote:I've always found it impolite when an author is invited to answer questions about a published book, only to see that others reply, without giving the author the chance to reply first. Unfortunately, this happens on quite a regular basis. No one ever made a remark about this, so it could be just me feeling it this way. If so, so be it.

It's fine (and good) for people to reply. We want to encourage discussion not just do a Q&A with the author.

The best case is that others answer the question saving the author more time in other threads. Or that the other person answering says something interesting that deepens the question. The worst case is that the answer isn't right, the author has to correct it and the person with the incorrect answer learns something. So heads we win; tails we win!

[Junilu Lacar]

Andrew,

I read more of your reply and went back over what I wrote. I'm sorry it didn't come across they way I intended it to, which was to just provide a developer's perspective by putting myself in the shoes of someone who was more of a novice at this stuff.

When I first started out learning to be more agile, I started with Martin Fowler's book on refactoring. I didn't have experience with XP when I first read Beck's XPE and while I found the ideas Kent talked about in his book interesting and exciting to think that they somehow worked, that was the extent of its usefulness for me, as a source of inspiration and hope.

Fowler's book, on the other hand had recipes for refactoring, giving me step-by-step instructions on how to manually refactor code. This was before I used an IDE that helped me do refactoring and before I even worked with Java. This is what carried me through my Shu stage. XPE was more like a guidebook to what I should learn to get from Shu to the Ha stage. It took another five years of bouncing around different projects before I even had a chance to try to put what I read in XPE into practice. It wasn't pretty either and it took another two years before I got another chance.

My point, at least the one I wanted to but failed to clearly make, was that as a solo developer looking to learn agile, I'd probably get more from a book that had the kind of recipes and context-free rules that Fowler's Refactoring gave me. I see your book as more of a bridging book, much like what XPE was for me, except maybe instead of just a guidebook to one particular flavor of agile, your book covers several flavors of Agile.

I hope that clears things up.

[Junilu Lacar]

Andrew,

I'm glad you brought up Shu Ha Ri because it reminds me of something that Mike Cottmeyer of LeadingAgile talked about regarding the choice of where to start in an agile transformation effort: Should you start with Culture/Mindset, Practices, or Structure?

Mike makes a pretty convincing case for starting with Structure. I think the reason why starting with structure (of the organization, per Conway's Law) makes sense and probably works better is because it gives novices a defined context within which to start adopting new practices. Changing culture and mindset takes a longer time and many of the abstract high-level concepts and modes of thinking on which mindset and culture are anchored have to be first steeped and aged in the sweat (and often, blood and tears) of practice.

So, what I've seen so far in the book are discussions about mindset and principles and a general overview of practices. This is why I think it's more of a Shu-to-Ha bridging book rather than a Shu level book. Can you cite some specific sections of your book that have more of a recipe type presentation intended for readers at the Shu level?

[Junilu Lacar]

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

Andrew,

Thanks again for your response.

I woke up this morning still bothered by how far off-base I was in how I had intended/hoped my input in this thread to go over and how it actually did go over with you (I'm assuming Jenny feels the same way). I'm sorry it stung you that much but my intent was not to disparage your work. I assume you've experienced going through a code review or perhaps even had a focus group try out a new UI design. I wrote what I did hoping that you'd receive it from a perspective similar to that of a developer whose code was getting reviewed or whose UI design a focus group was trying out and giving feedback on, impersonal and objective. However, writing a book is no small feat and you have written a number of them. I'm sure each was a labor of love, with this one being no exception. I understand what it must feel like if someone says something that might suggest it's not the best thing since sliced bread. I guess the sting you felt just goes to show you're only human after all.

I am by no means an expert in agile software development. I do have strong and firm opinions based on a fair amount (I'd accept "limited," too, but not "plenty") of experience but like everyone else, I'm still learning and continue to learn.

I have been fired up about agile software development since reading Kent Beck's XPE and Fowler's Refactoring book in late 1999 (looks like I dated my copy Nov 1999) but it wasn't until about eleven years ago that I was really able to work in an agility-friendly environment. I am primarily a developer but I am also passionate about sharing what I have learned with others. I often confess that this passion for sharing knowledge is not entirely altruistic. A big part of me wants to share and help others get better for an entirely selfish reason: I want to work with people who know how to write great software. Too often in the past, I have had to work with horrible code. To this day, that's still the case to a large extent. My thinking is that if we could teach more people how to do things better, then the likelihood of inheriting bad code and suffering the consequences becomes less and less over the years. Spread the goodness and eventually reap the benefits. I hope there is something we have in common in this.

That said, there are many people who want to learn agile s/d and are getting lost and confused. There is a plethora of information about agile s/d out there and it's difficult for the uninitiated to know how and where to start getting their bearings. I'm sure you'd agree that there's a lot of people out there who fall under the category of "knows enough to be dangerous" and I'd bet that's the last thing you want to do, to give a bunch of people just enough information to be dangerous. Unfortunately, I'm have to say that I have a bad feeling that's kind of what you have here. I'm not saying that anything you wrote is wrong. I just don't think the broadness of the topics you try to cover in the book lends it well to be offered up as a "Shu" level type book.

For the benefit of those who are not familiar with the term, Shu is the first of three levels of learning (traditionally, in a martial art). In the Shu stage, you learn kata and various movements related to them. Often, you break each technique down and learn how to do each part correctly. In the Shu stage, you try faithfully follow the form taught by your instructor, and try not to deviate in any way from that form. This helps you develop "muscle memory" and proper execution, eventually leading to you executing techniques more naturally and instinctively.

For developers and other creative types, Shu involves rote learning, following step-by-step instructions. Andy Hunt, in Pragmatic Thinking and Learning: Refactor Your Wetware refers to the recipes we follow as "context-free rules." Experience gives experts the context needed to come up with a solution to a particular problem. Novices, by definition, don't have that experience so when faced with an unfamiliar problem, they won't know what to do. Context-free rules help novices do things without prior experience. This is essentially what happens when you follow along with a YouTube video to make an origami giraffe or change fix a broken pipe under your sink.

Coming back to the book, I'm not convinced that the book can be used at the "Shu" level. This is not a failure on the authors' part. In fact, I would say they did a pretty good job in covering the breadth of the topics they included. The nature of things like mindset, culture, principles, and to some extent, even practices, just doesn't lend itself well to "Shu" level type learning or teaching.

Again, to be complete honest (and hopefully fair), I think this kind of book is most useful as a way to get an overall, high-level understanding of the lay of the land. It helps "set the scene" for learners, giving them an idea of the different things that are out there that people call "Agile," how they might start to think about things differently, and what they might expect to experience when they join a team that says it's "doing Agile." This can be useful for Shu level learners, so they have an idea of where they are heading, what to pay attention to and what to avoid.

As a beginner's recipe book that can provide context-free rules on how to do agile software development, I just don't think such a thing can be written by anyone. That's why, for learning how to do things like pair-programming, unit-testing, and TDD, I'd start with some of the other books I cited before.

One last thing: I think it's good to know the history of the things you're learning. In studying Aikido, I went back and read about what motivated Aikido's founder, who his teacher was and what his story was. I read about many other masters of the art. The thing with masters is that most of the literature you find about them or written by them pertains to philosophy and mindset. Sometimes you can learn more from a master's advanced students than you do from the master but the principles and foundational things you learn really should be based on what masters of the art taught.

So, in learning about agile software development, I think it's useful to go back and read literature written by or about those who started all this: the 17 original signatories and their contemporaries. Learning about their motivations, what their early and recent experiences were, how their thinking has evolved over time, new techniques they are trying out, all these things help you get a better insight into what you're trying to learn about agility. It also helps you keep from straying far off the path and getting lost or falling into traps. Then come back and read works by those like yourselves, Andrew and Jenny, to see how a new generation of experts take those original ideas and evolve, refine, and improve on them.

[Andrew Stellman]

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

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

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

[Junilu Lacar]

It's cool that you know about O'Sensei's moment of enlightenment. And, yes, I would much rather interact with you as training partners do on the mat, like an uke giving nage something to work with and "receiving" the technique rather than butting heads and trying to show who's better, which isn't really in the spirit of Aiki or agility. If you prefer to answer questions first before others add their own thoughts, I'm happy to oblige and defer to you and Jenny going forward.

Thanks again.

[nick woodward]

thanks for the reply andrew

there's a good chance i'll end up buying this or your other on the subject (having reading Jeanne's review)

[Liutauras Vilda]

I've been observing this thread since the beginning (same as many other peers). It was waving, with its own ups and downs. But to be honest, I think it exceeded expectations, at least it did with mine.

I think promos which may look as a parade of glory are unnatural, meaning come and pass without even exposing their actual context. Here, I think have been exchanged a good amount of valuable information about the subject, which made me stood for a while and think.

No Andrew, I don't think it changed (some way negatively) the way people will look at your book, I'd think otherwise. Authors, who don't obviate from discussions which might aren't that comfortable to discuss, especially during their promos, gain a fellow feeling from other peers for their professionalism. I think Junilu opposed in a way such as "..we don't criticise you, but your code, please support your position why you implemented it that way..". And hey, it turned out to be a highest class debates, were scales fluctuated, and finally I think both of you had a valid arguments to be right in one or another way.

Piet as always with his mundane view, acts as an revival, which brings stuff back on the track.

Kudos to you all guys, knew it it is going to be a good promo