Review: Agile! The Good, the Hype and the Ugly

In October, I spent some time in the company of Bertrand Meyer, author of "Agile!: The Good, the Hype and the Ugly". This book was written to be an independent, impartial and objective study of the various agile methods (scrum, xp, lean, crystal) viewed against the knowledge-base of software engineering methods and principles. The author, being no stranger to software engineering, is well-known in the computer world, across both academia and industry. He took it upon himself to do the research, investigate the agile landscape breadth-and-depth, probing assertions, practices, principles and values using a scientific (and empirical) approach with searching questions, thus providing an overall assessment. This wasn't purely an academic exercise, Meyer walked the path of agile himself, is even a certified as a Scrum Master, his team are using selected methods of agile in their own product development, so it's not like Meyer is throwing the baby out with the bath water! On the contrary, Meyer tries to remain objective, unbiased and fair in his reporting and analysis.

This book may just as well be the first book to read if you're a software manager, entering the agile-space, who's potentially feeling uncomfortable with perhaps some misplaced(?) "baggage" of software engineering, old-school-style projects, as touted by some agilists. Meyer has done almost all the background work for you, covering and assessing the popular agile methods in play today.

I was quite intrigued by the book's title, who wouldn't be!!?? You must admit it is quite EDGY, axe-to-grind, in-your-face-daring-the-agile-pundits - agilistas. I just HAD to get my hands on a copy, I actually waited a long time to buy this book (due to the bad Rand/Dollar exchange rate). I have voraciously read most of the popular books on agile (Schwaber, Cohn, Poppendieck, Rubin, Appelo, Pichler, Derby et. al, you name it), that extol this new thing "agile", often claiming a silent revolution is coming to overtake the industry, that "Software Engineering" should belong to the annals of history, and instead welcome "Software Craftsmanship" as in.  And when I read these signature-series books, I do get caught up in the rush-of-it-all, excited, converted and have actually been a promoter for #agile for ten+ years...I was caught hook, line and sinker!

Then when I came across "Agile! The Good, the Hype and the Ugly" written by a person very well respected in the industry, I had to ask myself, if I may have actually fallen for some hype, maybe I didn't ask probing questions, without having empirical data to substantiate claims. I wanted to find out if I was potentially backing the wrong horse, wanted to check some of my own values, personal-biases or not, of software engineering experiences held weight or not, but most important, the title being so catchy, I was rather curious to find out what the "Hype & Ugly" bits of agile this book claimed were...

Since my background in software is in embedded systems (Set-Top-Box systems) and highly-available-systems (Real-Time-Streaming/Encryption-Services) I grew up with the scientific engineering mindset (BSc. Electronics Engineering & Masters Computer Science), so I often found myself being selective with vanilla Scrum and had in the past, cautioned people against following a particular agile method with extreme dogma, i.e. I maintained a certain amount of discipline and structure was always needed. This is primarily because of the particular domain-experience I was coming from, which wasn't high-level application non-critical development (Mobile apps, WebApps, Websites), or application development that relied on a stable SDK/engines (i.e. the expectation of a stable operating system, database, etc upon which to build applications on top of).

This book, in my view, should be essential reading for any software manager, looking to understand agile methods before diving head-first into a vanilla, textbook-implementations.

For people convinced about agile to-the-letter, this book will be a little edgy for you - one needs a cool head, and openness to accept some of the challenges that Meyer puts forward, especially when it comes to backing up assertions of values/practices/principles or citations of productivity-gains, without sound scientific and empirical data to back up those claims.  Meyer highlights such challenges from some of the books that I myself have held in high esteem for many years, so take it on the chin...

Meyer's style of writing is somewhat academic, factual, but also practical with some nerdy-humour thrown in-between. Meyer has written with sincerity, remained as open-and-unbiased-as-humanly-possible, and made a conscious effort not to promote his own personal projects, products and frameworks. Meyer cuts to the core of uncomfortable-but-some-relevant truths, especially challenging assertions and statements that lack scientific validation, or backed up by empirical studies. He writes with a depth of experience and passion for practical software methods that it forces you to think hard about the course you're on, the things you just accepted and may have taken for granted (e.g. forgoing necessary engineering practices such as a little bit of design up-front to support changing requirements).

You have to be patient with Meyer as he unpacks in some surgical, analytical detail the various topics, in fact, the selling point of the book's title, is actually left right till the last chapter, so you have to read from start-to-finish, because the essence of the Hype, Ugly, Good & Brilliant is saved for the end (building upon his arguments and case-points from the earlier chapters).

I was taken on a roller coaster ride, experiencing moments of pure resonance thinking I am on the same wavelength as this guy riding high, in-phase. Yet also, there were instances when I felt a little edgy, somewhat uncomfortable, noticeably shifting my position as I lay in bed reading at night. Stopping, putting the book aside, to sleep over it. [I am two+ years into consulting as a Systems & Software Engineering Management consultant, doing the odd agile coaching gig here and there, advising on agile systems processes - and here is Meyer taking issue with consultants!]

In keeping with my deep-review style for special books - topics struck certain nerves, either resonating (fully in agreement with Meyer) or feeling of discomfort (not sure, not convinced), so I graphed the below curve, which is how I resonated with Meyer's assertions in the last chapter, specifically the edgy bits: Meyer's UGLY & HYPED assertions:

The blue area shows the feel-good, things that resonated with me, the extent of which I agreed and was comfortable with the ideas. The amber spots show the areas that made me feel uncomfortable, my level of discomfort, that either I'm not convinced, or have some personal biases that's potentially blinding me from seeing the points. On the whole though, resonance wins over discomfort.

[Aside: Here is Meyer's blog post introducing why he wrote this book, you'll find detail about the book's table of contents too]

Here's the detail of these comments, for each topic - In what follows, read as:
Title, Level of Resonance, Level of Discomfort, Comments

The Bad and the Ugly parts of Agile

1. Deprecation of Upfront Tasks, 95% 5%

Meyer takes issue with Agile completely denouncing and deprecating "upfront" activities in particular upfront requirements and upfront design. I tend to agree with Meyer, in my experience, with complicated systems, some time has to be spent thinking and designing for simplicity, yet scalability, adaptability and flexibility (which is in keeping with the agile notion of "welcoming changing requirements"). I was often on a project breathing a sigh of relief to know that we'd designed the components / system with some foresight to deal with new customer requirements. The changes were simple (sometimes just new config) and customer got the change turned around very quickly.

As always it depends on context, hence my 5% discomfort, there are cases where upfront anything is just wasteful, indeed Meyer does comment in his arguments to this effect:

It is true that one cannot fully comprehend requirements before the development of the system; that requirements will change; that the architecture will have to be improved as implementation proceeds. Those observations express some of the fundamental difficulties of software engineering, and the futility of trying to define everything at the beginning.

There is, however, no argument for shunning the normal engineering practice  the practice, in fact, of any rational endeavor - of studying a problem before attempting to solve it, and of defining the architecture of the solution before embarking on the details. The alternative proposed by agile methods is an ad hoc approach: identify some functionality, build it, assess and correct the result, repeat. It is no substitute for serious requirements and design.

2. User Stories as a basis for Requirements, 90% 10%

A lot of these cases will depend on context of the application / domain / business model, so if we're talking about complex software systems, that involve a number of interconnected components and possibly integrating with other systems, then I agree 100% with Meyer that the form of requirements by way of user stories: As a ... I would like to ... so that I may.... may be somewhat short-sighted, and given the aversion to upfront activities, such user stories are applied to a given context and time period, with the information known to the person at that particular time, somewhat short-sighted, since in the upcoming iterations it is quite likely that new user stories would conflict with earlier user stories from earlier iterations...and then development team would have to refactor and change the design to accommodate for these conflicting user stories to seek out a more coherent and accommodating design.

Meyer makes reference to the "critical Jackson-Zave distinction between the machine being built and the domain that constrains it". This pretty relevant to the world of software & systems that I've managed, where it is crucial to separate the machine from the domain, the system from the consumer application, citing from Chapter 3, section 3.2.5:

Some requirements elements describe properties of a model of a part of the world, or "domain", in which the system will operate.

Others describe desired properties of the system, or "machine", that the project wants to build. 

Here are examples of rules that are clearly requirements and not "candidate solutions":

• In a business system: "Any transaction over $10,000 requires approval by a supervisor". This statement describes a business rule, perhaps, a legal obligation; not something the project decides, but a constraint that the implementation must satisfy. If it does not, the implementation is incorrect. What competent software manager would ever embark on a banking system, constrained by such rules, without setting aside time, up front, to write them down?

• In an embedded system: "All cell phone communications shall take place within the allocated frequency range" (also defined precisely in the requirements). Another example of a fundamental constraint imposed of the project by its environment. 

And to drive the point home, Meyer says:

User stories are no substitute for a system requirements effort aimed at defining the key abstractions and the associated operations (the domain model) and clearly separating machine and domain properties.

3. Feature-based development and ignorance of dependencies, 98% 2%

This comes down to the complexity of the architecture & platform, Meyer makes reference to two models: Additive and Multiplicative complexity: the Lasagne and the Linguine. And when you consider this argument, it is quite clear of the challenge required to co-ordinate, synchronise and manage development teams responsible for a complex architecture, allowing independent feature-based streams of development without considering upfront time required to align and manage the dependencies.

Additive and Multiplicative complexity is covered in an article on ACM here.

My personal experiential bias agrees with Meyer: Difficult projects to not lend themselves to this scheme [i.e. treat software development as a sequence of implementations of individual features, selected at each step on the basis of their business value] - they require foundational work (building core architectural elements, such as a communications or persistence layer) which extend across features; and the features interact through dependencies, causing complexity of the "multiplicative" kind.

4. Rejection of dependency tracking tools, 100%, 0%

Agree 100%, quoting Meyer verbatim:
The potential complexity of feature iterations requires a careful analysis of task dependencies; projects can skip this analysis only at their own risk. The advice to stay away from Gantt charts and dependency-management tools is not only naive but detrimental. Such tools are not a panacea for project management but have proved their value over several decades of use. They can help agile projects just as well; dogmatic rejection of useful tools is a self-inflicted wound.

In a past project that we ran as agile-as-possible, involving 100+ software components, with development teams across many countries, over 30 scrum teams, using 6-week program iteration cycles, we relied on dependency-tracking tools quite heavily. Whenever new work packages were drawn up, we cross-checked component dependencies across the board, using this to synchronise and schedule the work and manage the integration points...without dependency tracking, we would've been running like headless chickens all over the place!

In another experience, I've seen scrum teams work in relative isolation of each other, not fully tracking dependencies, only to find out just before release date "The frontend is ready, but the platforms team and backend team still need four more sprints to go".

Personally, I have moved away from MS Project Gantt charts for a few years now, my tool of choice is Excel, whilst I agree that classic Gantt-like charts become out-of-date the moment it's published, that PMs end up spending more time with a project tool, than talking and collaborating with people, I can't argue with the point that on complex projects, some form of dependency tracking is inevitable, and if agile-people shun this completely, then yes, this maybe a bit ugly.

5. Rejection of Traditional Manager Tasks, 70%, 30%

I agree that reaching a state of a full self-organising team is more a dream than a reality, yet, in my own experience as a software engineer, did indeed work in a self-organised team. It didn't happen overnight, our team was small, collection of mature and experienced, equally passionate and motivated individuals, with a blend of management and technical expertise built over time. We had a manager that just let us run with commitments, only intervened when we needed some kind of business intervention, but apart from that - it was awesome, so self-organising teams do work.

However, the agilists promote this as if this is the best way, that teams must always aspire to, or that classic managers are no longer needed. I have seen teams struggle (with agile coaches thrown in between) to reach a point of self-organisation, that the absence of a software manager directing or playing a co-ordinating role, steering decisions or being decisive - the project would have failed.

Now I fully support the notion of self-organising teams, it's something that I myself try to promote, but if the ingredients are missing, one must take into account the context, so Meyer's arguments are really sound:

The self-organizing teams promoted by agile methods, with no manager having the traditional duty of assigning tasks, are the best solution for a few teams, and are in appropriate for many others. The picture of the manager as an incompetent control freak is a caricature. Many software projects have been brought to completion, and many projects on the brink of failure have been rescued, through the talents of a strong manager. Imposing a single management scheme on everyone is arrogant.

6. Rejection of Upfront Generalization, 85%, 15%

I am in agreement mostly with Meyer's point that if one of the principles of agile is to "Welcome change in requirements even late in development", then how can software engineers not take up some time upfront to think through a design, anticipating change and at least providing an architecture framework or model that is receptive to change?? As Meyer aptly puts it:

Good software developers do not wait for change to happen: they plan for it by designing flexible architectures and solving more than one problem of the moment.

Designing & implementing for now, instead of anticipating some changes to warrant a flexible design, in my experience, is a form of waste as it adds further work that could be avoided if some time was spent upfront with design. I have seen it happen on many a TV systems project where months of rework and expensive costs could have been avoided by little thought upfront with a flexible architecture (instead of implementing for the information as was known-at-the-time with a product owner that was not comfortable anticipating almost probable changes to future business requirements), so development teams implement for the as-is (leading to hard-coding and very narrow-minded system configuration implementation).

I do however, appreciate that we should not get carried away with envisioning future changes, running the risk of gold-plating architecture design, building so many abstractions that will end up never being used - there needs to be a sense of balance and pragmatism, that can come from mature engineering culture...

The bulk of my software and systems engineering space has been working in technologies, systems and businesses that were quite mature, the level of uncertainty and unknown was not complex or insanely unclear, the systems and stacks evolved over time. So in terms of upfront requirements in this context, there is enough history and acquired wisdom that one can tap into. Even if you're overhauling your technology infrastructure and architecture, replacing legacy systems with brand new design patterns, your customer requirements, the end-goal, the bottom-line is tangible and pretty tractable. You are not solving a new problem for the customer, you're overhauling the engine, customer still gets the car...hence my bias and issue when organisations switch to agile-methods, teams naively assume everything disappears and start from scratch, with requirements taking the form of user stories and post-it stickies...it's a little amateur in my view.

But I am open and objective enough to accept that in the realm of the new, creating a new webapp or mobile app, with backend cloud services integration, cool new features, disruptive user experience, in that space you're in the unknown and go for it, don't spend too much time upfront, experiment, iterated, feedback and learn...but don't throw out acquired wisdom of subject matter experts just because you've decided to take the agile / scrum route.

I find this picture always useful for settling the agile-debates:

Cynefin Model

7. Embedded Customer, 70%, 30%

Meyer has singled out XP from Scrum, where XP insists on embedding the customer representative within the development team, full time - I agree in practice, this is very hard to achieve, and as always context matters. I have seen instances where embedding customers and even third-party vendors adds real value, so I'm not dismissing this outright, hence % discomfort there.
Meyer acknowledges the Product Owner role from Scrum as an excellent idea, which I'm in agreement with.

8. Coach as a separate role, 10%, 90%

In this instance, I don't fully support Meyer's view:

The Scrum idea of a dedicated Scrum Master is good for Scrum, but not appropriate for most projects. Good development requires not just talkers but doers.

I am not clear if Meyer sees Scrum Masters as coaches, or is he referring to separate Agile Coaches supporting Scrum Masters? Will have to re-read that section of the book again.

For me, from my exposure to agile-methods, I don't take kindly to what I call "Textbook Scrum Masters" who read a book, go on a quick 3-5 days course, gets certified, and presto, you're a Scrum Master. No, I look for real-world experience, seeking out people who have seen at least three major endeavours through to completion, including experience with early agile adoption, seeing a transformation through, and ongoing support of product release cycles. I look to Scrum Masters as people that can lead, not just facilitate and talk-the-talk, but must have some battle scars to show for it...Scrum Masters that just follow ceremony-for-ceremony-sake, who feel that they're just impediment-removers, and facilitators, and not play an active part in feeding back systems process changes, are not valuable to me...

When it comes to coaching, I must disagree with Meyer, seeing that I've been a coach myself, and am a consultant who values teaching others, instead of taking over and just doing things. I believe there is a need for a consulting coach to teach, guide and up skill the development teams, as the saying goes:

Give a man a fish, you feed him for a day. Teach a man to fish, you feed him for a life time.

9. Test-driven Development, 90%, 10%

I honestly cannot find fault with Meyer's arguments on this topic. I have not been close to code for some years now, and when I did use xUnit tools, and experimented with the concept of writing tests first before code, it just didn't feel right. Eventually, the rule our organisation applied was all code must be testable, no new code without tests, must run regression tests before every check-in, etc, etc. We could care less if we wrote a failing test first, then run a test suite, change code, make the test pass...what we focused more on functionality: every requirement must be fully testable, no regressions... if we review the original TDD Cycle:
1. Quickly add a test.
2. Run all tests and see new one fail.
3. Make a little change.
4. Run all tests and see them succeed.
5. Refactor and remove duplication
... seems almost too simple.

So Meyer claims the following:

While test-driven development is extensively discussed in the literature, industry has made its choice: it is not broadly practicing this technique...

I'll take his word for now, seeing that he's done the research, with a caveat that there maybe domains and tools where TDD is possible, but where I've come from in TV systems software, test code still is mandatory, testing functionality more than code...I am open to be shown otherwise.

Anyway, Meyer has attributed other test ideas from agile methods as good-and-excellent ideas:

Test-first development, and the requirement of associating a test with every piece of functionality, appear in the lists of good and excellent ideas...so does refactoring.

10. Deprecation of documents, 40%, 60% 

I wouldn't necessarily label this as completely Ugly idea for agile methods, hence I lean more in favour for agile....Meyer says:

Agile criticism of document-heavy processes that produce little real customer benefit is right on target for some segments of the industry - although in some cases, such as mission critical systems, little can be done about the situation since the documents are legally required by certifying agencies...outside of specific industries with high regulatory requirements, a strong case exists for lightening up the document infrastructure.

Because of my systems engineering inclination, I do resonate for the need for certain documentation efforts, that can be started upfront and modified as the project progresses. It all comes down to knowing who your customers are, what outputs are expected and the value thereof (i.e. not document for document-sake), and that agile teams must respect there is a need for certain levels of documentation.

I have personally experienced waste in the form of documents, and therefore do take the side of agilists - be sensible about the approach. Not too much, not too little, just enough. Factors such as product usage, local versus distributed teams, external qualification requirements, organisational contractual obligations, must be considered before dismissing outright the needs for documents. As long as there's value in documents, it should be respected...if we prove there isn't value, then it's waste.

I also support that just-enough design-on-paper, but the code really speaks for itself, that auto-generated documentation (from code) is far more efficient and valuable doing paper upfront designs...for complex systems, block diagrams and sequence interactions for the principle solutions make sense, but nothing more. Installation, configuration, operational and business rules however, are indeed deserving to documentation!

Documentation shouldn't be assumed to be physical paper: wikis, blogs, online audit tracking forums/conversations, howtos can all be forms of documentation provided by agile teams, which may need some upfront investment. So I'm not a traditionalist stickler for documentation, but neither am I promoting a naive, head-in-the-sand-view that all documentation is wasteful...

The Hyped parts of Agile

1. Pair Programming 95%, 5%

The 5% discomfort comes from my remaining hopeful and wishing to see the dream come true. I participated in pair programming back in the day, it was fun, humbling and yet a little frustrating too. To prescribe pair programming as mandatory seems off to me - if the team gels well, and the environment can really make it work, then cool...but most engineers are quirky, and the really good ones (that I've come across) prefer to work their magic on their own, then share it with the rest of the team. Meyer is waiting for the evidence to prove otherwise:

There is no credible evidence that it provides major improvements to the programming process or that it is better than classical techniques such as code reviews, and no reason to impose it as the sole mode of development.

2. Open-space working environments, 35%, 65%

I accept Meyer's point "there is no single formula for the layout of the working environment" however, I wouldn't necessarily agree that this idea warrants belonging to the HYPED category. I have seen how open-spaces encouraging dialogue, interaction and close collaboration improves the working situation, knowledge flow and assists in the breakdown of silos. I also agree there should be quiet-spaces, that a bazaar-style environment doesn't necessarily help either. Just forcing everyone to be co-located in a space sometimes runs the risk of a "chicken run", which I once experienced, it was impossible to get any real work done, interruptions upon interruptions, noise-makers...there are techniques like Pomodoro that help...so open-spaces, co-location and removal of offices (anything that creates a barrier of "I'm better / higher than you" in the teams) gets my vote.

3. Self-organizing teams, 95%, 5%

I do feel that self-organising teams are over HYPED, that whilst it's a great ideal to aspire towards, it is extremely difficult to achieve in practice. It's like searching for that elusive unicorn, in la-la land. I did get a glimpse of a self-organising team, I was part of one back in the days of coding, and it was quite awesome, to be given the trust, responsibility to mere technical engineers, very little management intervention except the steering and subtle orchestration required for business alignment...

As Meyer compares a team of musicians (orchestra) can't function without an orchestrator, co-ordinating and synchronising, pointing & giving cues...so too is it very difficult for a development team to produce the outputs without anyone orchestrating. I have not seen it happen, from my program management experience, there needs to be someone reigning in the streams, co-ordinating and playing conductor to the software orchestra...so basically agreeing with Meyer:

A few teams are competent and experienced enough to manage themselves, like a conductor-less orchestra. Most are not. Each situation calls for its own organizational solutions and there is no reason to impose a single scheme on the the entire industry.

Besides this, organisations need to have a massive change in mindset, management needs to change, this is fundamental, and such earthquake-like changes are very hard to happen in huge organisations - recently a very senior manager told me "Self-organisation leads to arrogance and egos getting in the way, teams end up doing their own thing, where misalignment happens"

The disruptor-in-me really wants to see this change come through, although the battle-hardened manager in me, has shown me it's really difficult to achieve, therefore somewhat of a HYPE, unless the agile canon does more to talk about the realities and challenges in getting there, instead of laying it out a rule...

4. Working at a sustainable pace, 70%, 30%

I am all for managing expectations, negotiating requirements against the timeline expectations, for representing the development team's best interests of what is achievable or not, of being wary of burning out teams, of getting down to the bare-bones minimum releasable feature set, etc, etc...

But what I've come to learn, is that business-is-business. Expectations and commitments are set by leadership teams in other conversations, that is usually outside a development teams sphere of influence or circle of control...and the bottom-line is always about DELIVERY.

This too depends on the nature of the organisation, the competitive landscape, and the product environment. Deadlines will never disappear, release and ship dates must never slip. There are some minimum requirements that must happen by a deadline, and there's no way of avoiding that...every manager knows that death marches are not good management practice and should be avoided. In the same vein, development teams must appreciate business & commercial drivers too, and deliver, even if it means disrupting the "sustainable pace" ideal.

5. Producing minimal functionality, 30%, 70%

In this case I am leaning towards supporting the agile camp here, this is not HYPE in my opinion. Too often products get released with features that hardly anyone uses, dreamt up by product managers who couldn't be closer to the truth. Traditional methods of dreaming up features, use cases, and even using focus-groups -- does not cut it anymore IMHO. I favour the lean start up approach, build-measure-learn-feedback loops. Get the minimum releasable features deployed, ask for feedback, adapt and change as required.
In my experience from TV products, most of the STB Applications are just bloat-ware, bells and whistle features that users just don't care about. Product teams must apply critical thinking to their requirements, Simplify Simplify Simplify..."Perfection is achieved not when theres nothing more to add, but when there is nothing left to take away"...

6. Planning game, planning poker, 50%, 50%

The jury is still out on this one. I have seen these games work in the development team, almost like they're in their own bubble without accounting for their impact on the bigger picture, as if the entire business must just accept "this is how we estimate here" and program end dates must just accommodate slippages (yes project management speak here). I prefer estimates in working-days and days remaining (this is the info I need to manage large programs), I don't really care what the dev team uses (points, buildings, cars, t-shirts, etc) as long as the scrum master or product owner can translate their estimates into customer-speak... and how they do it, using a planning game, planning poker, etc - doesn't matter either.... but is it all HYPE? I'm not sure, hence 50/50, because I've seen it work...Meyer says

..they cannot be a substitute for more scientific approaches. In particular, they are open to the danger of intimidation by the crowd; the voice of the expert risks being smothered by the chorus of the novices.

Whilst there may be some truth in that, if this really happens then the team needs to rethink their make-up, and probably need more coaching on the teams value systems and working agreements

7. Members and Observers, 100%, 0%

I resonate with Meyer here...I just don't like the agile terms "pigs" and "chickens" - personally (bias) find the words repulsive, unfit to be part of a professional software engineering body of knowledge. I fully support agile managing people's influence in the project, that yes, listen to people who are fully invested and have some real value to add, be wary of people on the sidelines, observing...but in my view, there maybe excellent subject matter experts that are not in the project, and can still play a valuable role in the project, acting as observers, soundboards and counsel. Agree with Meyer:

In project meetings, the views of the people most seriously involved matter most. This trivial observation does not deserve the amount of attention that the agile canon devotes to the distinction between "pigs" and "chickens".

8. Collective code ownership, 98%, 2%

Just as I see self organising teams as the nirvana, so too is this notion of collective code ownership that developer can touch any part of the software stack. Of course, it would be absolutely awesome for a team to have expert knowledge across the stack, but in reality, speciality exists, there are just some subjects that require people to have spent years working on, becoming experts. There are certain parts of the stack (like security components for example), that are just sensitive. So agree with Meyer (although still hopeful in the ideal):

The policy governing who is permitted to change various parts of the code is a delicate decision for each project; it depends on the nature of the team and many other considerations. It is pointless to prescribe a universal solution.

9. Cross-Functional Teams, 85%, 15%

This is similar to the collective ownership and self organising teams idea, although I am a supporter of cross-functional teams as long as it's done with a sense of reality and practicality in mind. I still stand by the notion that there are just parts of a software stack or system, that require specialist skills and attention, that will not be fixed by a cross-functional team: The notion that any member of the team can do any tasks, for me, is one to aspire for, but in practice, extremely challenging to get right in practice...in my world for example, I won't get someone who's written only high-level Java application code, to work on memory optimisations in the kernel, or, implement seamless transitions when splicing in transport streams... as Meyer aptly puts it:

It is a good idea to encourage developers to gain broad competence and to avoid dividing the projects into narrow kingdoms of expertise each under the control of one person. Beyond this general advice, there is little a method can change here to the obvious observation that special areas require special skills. If one of your developers is a database expert and another is a concurrency expert, you will not ask the first, if you have a choice, to resolve a tricky deadlock issue, or the second, to optimize queries.

I support the notion of cross-functional teams as a means to breakdown traditional barriers and silos between for instance: Product / Dev / Test / Integration / Deploy silos, after all, the silo-mentality is exactly the thing that agile methods wanted to address...

The GOOD parts of Agile

Agree with 100% resonance with Meyer here:

1. Promoting Refactoring [but don't use it as an excuse not to do upfront design, then it's ugly!]
2. Run short daily meetings focused on simple verbal progress reporting
3. Importance of team communication
4. Recommend co-located project teams over distributed development
5. Insist on removing waste is a good discipline

The BRILLIANT parts of Agile 

Gotta agree with 100% resonance with Meyer that he openly commends as being brilliant and inspirational:

1. Short iterations timeboxing
2. Continuous Integration with Regression Test Suites (from XP)
3. Closed-window rule - prohibit anyone regardless of status from adding functionality during an iteration
4. Concept of product owner who represents the goals of the customer and has decision power over what goes into the product and what does not.
5. Emphasis on delivering working software
6. Information radiators - velocity / task boards provide visible evidence of progress
7. Associating a test with every piece of functionality

So Meyer concludes, quoting:

The ideas listed as good or brilliant are relatively few, but they are both important and beneficial; they deserve careful study and immediate application.  They justify the journey, arduous at times, that we took through the land of agile methods. Once disentangled from the questionable part of the agile credo, they will leave a durable mark on the practice of software engineering, and find their place, along with earlier ideas such as structured programming, formal methods, object-oriented software construction and design patterns, in the history of major advances in the field.

In my own journey, I am of those that studied engineering, aspired to become a systems and software engineering professional, definitely building up my own baggage and biases. Who am I to stand in the way of this precipice of change, the age-old debate of whether writing code is an art of engineering, or a craftsmanship...or whether anyone can just code for the heck of it... I do see the craft in software, and I also see the engineering as well...for now, I go with my gut feel and intuition, do what feels right, makes practical sense, choosing a method appropriate for the challenge at hand!!...