Adopting The Whole Enchilada

I believe there are still some points missing:

1) Ron Jefferies covered the necessity of practices in addition to organisational problems (see the example of refactoring)
2) Ron further writes another article on "Discovering Essential Technical Practices". It's a very nice article I would recommend for people following this thread.

In response to Joshua Kerievsky on "Scrum out of the box says nothing about technical agility. It is like selling a car without seat belts and other critical safety features.". I prefer the following saying by Ron Jefferies again:

"Locomotives are not limited because of lack of wings." tech.groups.yahoo.com/group/leanagile/message/2333 . This was a comment made on adding more Lean into Scrum. I think it is also applicable to the case of suggesting adding XP into Scrum. XP practices are useful doesn't mean we need to add XP practices into Scrum.

I don't know how many times how many times it takes before people stop asking Scrum to add certain things or blaming Scrum for having no technical practices without blaming themselves for not discovering the essential technical practices.

"You have to do right things, and you have to do things right, in order to succeed."

Wrong! You simply have to do both "good enough". Saying you MUST follow a particular external prescription is saying that you must follow a religious dogma. The dogma has nothing do to with doing the right things correctly. You simply must do X1..Xn where n is some silly large number and Xx has no connection to anything real. They are nothing but laws on stone tablets written by a burning bush on the top of some far off mountain.

Its even a more silly dogma to say the context MUST be changed to accommodate an arbitrary dogma that is reported to have worked in other situations. If you change the context, you are working on a different problem. You might be able to solve the New Problem but The Problem still stands in its original context. What you did may match your sacred religious dogma, but is it in the same universe as "do the right things correctly"?

The task is to solve The Problem and not to use a particular way to do it. It does you no good to be able to say we failed but we used the sacred "approved" way to fail.

Gasp! I have dissed the gods of Agile. Will I ever be forgiven? Will I ever gain access to my promised 72 virgins? Oops, sorry, wrong religion.

PS: I have been successfully using some agile methods since long before the Agile Dogma was born (early 1970s). It the right situation, used correctly, agile works magnificently. Used blindly, without thought, as a hammer that solves all problems, Agile fails miserably.

Hi Steven, thanks for the feedback, that's what this is all about.

As for possibly "missing some points", to be honest, these news posts here at InfoQ are not necessarily intended to be "the whole enchilada" :-), but rather they are intended just to be enough to summarize what's being said and excite/prompt readers to go see the real thing. Admittedly, its an imperfect science (including "this", leaving "that" out), but one we here do our best with.

As for adding your refs, in the future, please be sure to do so (with hyperlinks). I see you did so with the Jeffries leanagile message, but not for the first reference, to Ron's recent Discovering Essential Technical Practices article. For others, here is that link.

As for your thoughts on the topic itself, well, I'll let others weigh in on that :-)

Cheers
MB

Hi Lionel. I don't think its being suggested that all the practices in XyP agile methodology be "blindly used".

What's being said, for one, is that most organizations should be less inclined to dismiss this or that practice simply because it seems to conflict with the current state of their organization. The fact is that in many cases they *need* that practice, and thus need to figure how their organization should evolve to adopt it.

And no one here is saying anything about using these practices blindly - they're commenting on people not using them at all. They're not saying there is "one true way" to do the practices once you've adopted it, I think all our experts would agree loudly that you must Inspect & Adapt to do things right.

Of course, agile or no agile, using anything blindly, as a golden hammer, is more likely to end in failure than it is success.

Cheers
MB

MB,

I suggest using the lead "Adapting The Whole Enchilada" implies one must use ALL of the methodology without regard to the nature of the problem or its context. It may be that some practices when mixed with still other practices result in a better match to "do the right things correctly" for some problems and their contexts. Then again it may not be so for other problems and contexts. Its simply not automatically and ubiquitously true no matter what the method.

A method that is dependent upon a perfect context is not agile, its brittle. A method that can adapt to the existent context and give improved results is truly agile.

Assuming you were willing to change the context, what IT development group has the authority or even the skill to change it? Most of the time they don't have a sufficiently detailed and global view to know more than an outline. Also, they usually have no more authority to change the context than a random flea on a stray dog.

The ground truth is, they have to accomplish results with what they have and who they are in spite of the context in almost all instances. A method that could do that is far superior to the best possible method that works only in the best possible context. I suggest such a method would be truly agile. A method that requires a perfect context is more brittle than agile.

I say, where its applicable, use it. Where it isn't, leave it on the shelf. You do have to do the right things correctly but only good enough. What is good enough depends upon the situation/context. It should not be based upon authoritative assertions by some external self appointed authority.

If you have good developers, the "chosen approach" largely doesn't matter. Assuming of course the business understands what it needs. If the business doesn't understand what it needs or wants, then it doesn't matter who you have on staff or the approach you use. Come on people, no methodology is magic.

I have a couple comments on this blog posting ...

Firstly, there are no two companies that will practice Scrum the exact same way - that's simply not possible. Scrum has been specifically designed to be adapted to a companies context. It's a learning framework and you have to make Scrum work based on the context.

Second, I believe the Scrum coaches and trainers are all saying the right things. I know when I did my Scrum training, a considerable amount of time was spent on defining what "Done" means and that Strong Engineering practices is an absolute must.

In my book, Agile = Scrum + XP + TDD no ifs ands or buts. It has to be the whole enchelada. If not, you're asking for trouble.

I am sure many companies won't do it all and that's a shame. But that's not the fault of the Scrum folks.

My two cents,
Jack
www.agilebuddy.com
blog.agilebuddy.com

Blindly following any fixed set of practices by the book IS following a plan. That said, one must be sure, when abandoning a recommended practice, that he does so because it doesn't apply - say, pair(-only) programming, or customer must always sit by his side, or synchronized integration - and not because of laziness.

The Agile Manifesto has just values and principles because people just couldn't agree on the practices. And that's fine!

In my opinion, 'being agile' is just a matter of: 1. REALLY value the manifesto's values; 2. do whatever is necessary to keep them. Is code quality necessary to respond to change? Yes, so, what practices do I have to follow to keep it high? Pair programming? TDD? CI? Whatever works for you, I guess. Try, evaluate, adapt, and keep, or drop, it. The same for the other values and practices.

One may say that if you don't follow ALL <your methodology of choice>'s rules and practices, you can't possibly keep the pace. Well, it's just an opinion, backed with facts or not. Just watch out when you use the words 'always' and 'never'.</your>

One may say that if you don't follow ALL <your methodology of choice>'s rules and practices, you can't possibly keep the pace. Well, it's just an opinion, backed with facts or not. Just watch out when you use the words 'always' and 'never'.</your>

That paragraph pretty much sums it up. Most IT organizations are far below the necessary cultural maturity to consciously adopt *any* change in practice. Most IT managers are quite happy to stick a label on a project so as to appear fashionable. But little effort will be made to actually walk the walk. And when things fail, the method will be blamed, masking the failings of the organization and its management.

It would be better for all if non-leading edge IT organizations not even attempt Agile. Eventually, after a few leading edge competitors adopt Agile and demonstrate success in their industries, these laggard organizations will then make the necessary effort.

Forgive me for anthropomorphizing the words "method" and "context". However, it simplifies the following comment to do so.

Isn't it also true that the cultural maturity of the method is insufficient to adapt to the necessary rigidity of a vastly larger context within which it must function? The context is rigid because its huge, complex, not fully understood, and change can and will have many unintended consequences. Further, the prime drive of the context is to continue to exist. That results in any long standing context being homeostatic.

A homeostatic context can and will adapt to any external force in such a way as to cancel the effect of that force. Ditto for any internal force attempting to induce change. This is why the context can continue to stand. The method attempting to change the context MUST take this property into account or it too will be nullified.

The Three Laws of Thermodynamics apply

1. You can't get ahead.
2. You can't even break even.
3. You are behind before you start.

If the method understands this and can deal with it, it can work. If it requires that the Laws of Thermodynamics be suspended for it to work, its failure is assured.

Agile is failing? Ditto object oriented development, layered architecture, code reuse, etc in Java development. Java is the new COBOL.

Hi Lionel,

Companies that resist change eternally eventually go bust. Just compare Toyota and Ford to see the results of an "homeostatic context".

Whats been missed in this discussion is that the buyer decides. Scrum and XP are based on the same principles and cultural values, but are packaged differently. With Scrum, much less comes in the box, which makes it an easier sell and allows the buyer to fit it around what they do now and in so doing not challenge their existing culture.

The whole "enchilada" isn't an attempt to ram "best practice" down anyones throat. There is no such thing as best practice. Infact Taiichi Ohno of Toyota, said that their success was based on continuously asking "why?" five times, inspecting and adapting as they went, everything else was built on just this (eliminate waste, Jidoka, etc came later).

Five Whys means challenging the status quo. XP is an explicit challenge to established norms, and comes with concrete "challenges" in the box. Things like pair programming for instance, common code ownership and TDD. This packaging makes it less attractive to buyers who don't want to be challenged and do not want to change. This also makes XP less "marketable".

So its not the practices that matters as much as adopting the right values and whether you are willing to ask yourself tough questions, like "Are we any good at producing high quality software? And if not why?". XP as a "package" forces these questioning more than Scrum does IMO. Here is my contribution on the extremeprogramming forum.

Paul.

Sorry, wrong link. Here.

>> So its not the practices that matters as much as adopting the right values and whether you are willing to ask yourself tough questions, like "Are we any good at producing high quality software? And if not why?". XP as a "package" forces these questioning more than Scrum does IMO. <<

And this goes to the critical issue of what attitudes and values must already be held by an organization (or at least a management supported subset) before it can realistically pursue any agile method. In my mind, a clear specification of concrete (organizational) prerequisites is required. While this may be outside the scope of a discussion about Agile methods, and/or it may be felt that this would discourage adoption, I think it ought be part of any Agile practice definition.

Perhaps this has already been specified clearly before and I just missed it; pointers to work on organizational patterns (or anti-) relevant to Agile practice success are very welcome. :-)

Paul,

The first challenge is that we are discussing a very complex non-obvious problem set. The second challenge we cannot say everything at once - especially in short posts on a blog.

Your point that the system MUST be able to ask the right questions, be guided by the right values, and make the appropriate responses to survive and be successful is correct. This kind of system would be very supportive of Agile methods because its coherent with them. It would also be a total blast to work within such a system. We could blow the lids off and really get something done for a change.

What do we do when we are inside a system that doesn't have these properties? Isn't this the state that most of us experience? If so, isn't expecting the system to change before we can do the right things a futile exercise? Especially when we have no power to change the system?

Dreaming of utopias is a long and venerable practice. Meanwhile, back in the real world, we have real work to get done. Perhaps we could be far more productive if we could focus on how to be more agile in a hostile environment. I suggest that we accept that the hostile environment is all we have to work with and deal with it.

There is an interesting principle that helps to sort things out. Its known as POSIWID: the Purpose Of a System Is What It Does. If you see a system doing something absurd, look at what it does. THAT will be its purpose. The interesting thing is that it can work in reverse. If we use agile methods, the system is doing agile. The change that is needed is within ourselves and not the system. The interesting thing is that THIS is the most powerful way to change "the system".

Lionell,

>> I suggest that we accept that the hostile environment is all we have to work with and deal with it. <<
>> If we use agile methods, the system is doing agile. The change that is needed is within ourselves and not the system. The interesting thing is that THIS is the most powerful way to change "the system". <<

I'm afraid I don't see how this might manifest itself in practice... AFAIK, Agile methods propose a set of specific practices and techniques that **when used together** improve our ability to deliver value to our customers. Are you saying that practically adopting an Agile method in one of my company's projects is merely a matter of self-improvement? And that regardless of company culture, this self-improvement is all that is needed to manifest positive results? <>

As a contractor I see a lot of projects where OO is completely missing. Developers seem to be stuck in the mindset of producing procedure based services with a naked object model. Something that was widely pushed due to the failings of EJB as an architecture..

Improvement is improvement. It does not have to be 100% perfect to be improved. A 10% improvement is far better than no improvement at all. Combine enough 10% improvements and you will get to a point that the result is quite good enough. If not, go for another 10% improvement. Its rather like applying iteration to the way you work and where you work as well as to your work product.

If you don't improve yourself, how can you improve the system in which you are embedded? You must start somewhere. Start where you have the most control - with yourself. THAT is where your power resides.

The bottom line is that real people work in real environments and have to produce real results even though not everything is exactly as they would wish or as required by any particular method. You cannot work with what you aren't and what you don't have. You have no choice but to start where you are and work with what you have. Anything else is simply wishful thinking.

Standing around bitching because the system won't change to make something possible is simply an excuse for failure to perform. I say stop making excuses and start performing. Make SOMETHING better today. Then use that as a foundation for making it still better tomorrow. Seems to me this is actually at the core of all the practices of XP, Agile, Scrum, et.al.

Hi Lionel,

I agree that the what we are talking about is the psychology of the workplace, and there are no easy answers.

>> Dreaming of utopias is a long and venerable practice. Meanwhile, back in the real world, we have real work to get done.

Equally, I don't believe pointing out the route cause of the problem is dreaming. In the nineties I worked as a manager in a TQM company that spent milions on TQM practices, but never truly embraced "Kiazen" values. The result? Well people learned how to game the system and how to use the right TQM language to get on whilst still playing by the same game they had always played. Nothing changed. Not 10%, no zilch. In fact I'm sure that TQM as a concept became tarnished in the minds of many. So in a sense they had gone backwards.

Our industry has a very short attention span. Who remembers "business process re-engineering" or Six-Sigma? These things have come and passed as fads. At the moment "Agile" is poised to be the latest fad, passing like all the previous fads before.

I think we have a responsibility to "keep it real" and give visibility to the real issues. Who knows, those in power may actually take heed this time :) Truth as won through in history before, so it won't be the first time :)

I applaud your methods, and I trust that in the right context they do work. But can't we have more than one string to our bow? "Keeping it real" and saying it as you see it has its place too.

Paul.

I think this has enough relation to topics in this (good, healthy) discussion to reference. I liked it, so why not:
agilefocus.com/2009/02/agile-versus-agile/

Cheers
MB

"But can't we have more than one string to our bow?" No problem as long as its not used as an excuse for failure to perform. However, the "we can't do it because they/it won't let us" excuse is the ultimate excuse. You need to find a way to make "they/it" irrelevant. Then you can and will perform.

Part of what makes me cynical about XP et.al. is my experience with CPM, Pert, Kepner Tregoe, TQM, Six-Siqma et.al in my over 40 years in the business. I have used them. They work. In all but a very few situations, I have seen them gamed to death.

The common thread was they were to produce extraordinary results without knowledge, understanding, skill, discipline, or effort. All you had to do was turn the crank and the results would magically flow. They uniformly failed to deliver as expected. I also observed that, almost without exception, those with knowledge, understanding, skill, discipline, and willingness to expend the effort got results.

So I cut to the chase and reduced all the huha to the following prescription for improvement of anything. Which, incidentally is the underpinning of all process improvement practices.

1. Say what you are going to do
2. Do it
3. Verify that you actually did what you said you would do
4. Do it better the next time

The challenges are in being totally honest with the verification step and really knowing what is better. However, the process converges to something that really is better than you had when you started. If you do it, it works. What you call it is irrelevant.

Asking the tough questions is what it's all about. Scrum is designed to provide inspect and adapt points specifically to learn and adapt. You have to continuously re-invent yourself and finely tune the software development machine.

while I haven't read the original articles cited here I have to say I'm pretty disappointed by the tone specially by industry leaders like Ron Jeffries.

Telling organizations that they should apply agile as a "all or nothing" is basically telling them that incremental improvement is impossible.

Sounds pretty hypocritical given the agile is all about self organization and fine-tuning things.

I have been on plenty of projects where I have to be realistic and had to pick and choose which agile practices I could use depending on the developers I was working with, the executives who were the stakeholders, and the culture.

In every case, picking the right practices added an incredible amount of value. Was being unable add the "whole enchilada" a perfect scenario? no. But welcome to reality.

Blaming typical "CXO s” for not being able to adopt agile is pretty juvenile, I wish certain members of the agile community would stop acting like a bunch of disgruntled developers and grow up.

You're making it impossible to introduce agile in any but the most junior management levels.

I prefer my approach which can be found at agileconsulting.blogspot.com/2009/01/agile-over...

Jeff,

Yes. It is very disappointing.

Its as if the goal of XP, Agile et.al. is to produce a method to create books, training classes, certifications, seminars, meetings, and, especially, $$$$$$$. Lots and lots of dollars for the selling of still one more silver bullet.

Now I have no problem delivering VALUE for money. I have done it the entirety of my productive life. I do have a problem with pushing something indistinguishable from a cult religion for cash.

Your way works. I agree with the method of using the tool appropriate for the problem and the context. This is exactly what I have been proposing within this thread. That is truly agile (note the lower case "a"). We need to be agile and not Agile.

I will make this offer to anyone. Take my four step process improvement process. Make it your own. I don't even want attribution for it. Its an open source public domain free for the taking method. Do it all, part, or none of it. Call it whatever you want. Its totally your choice. I am not selling books or training. The results you get from it are totally and completely your responsibility.

1. Say what you are going to do
2. Do it
3. Verify that you actually did what you said you would do
4. Do it better the next time

Hi Paul,

>>Perhaps this has already been specified clearly before and I just missed it; pointers to work on organizational patterns (or anti-) relevant to Agile practice success are very welcome. :-)


You make a good point. Organisational culture is at the core of the issue. As an anti-pattern take a look a look at the classical Taylorist management approach. As far as positive patterns take a look at the work of Edward Deming and people like Taiichi Ohno. Mary Poppendieck has delivered an excellent presentation on the role of leadership in software that covers all the salient pre-requisites in more detail then I can here.

What it boils down to is creating a culture of success.

You don't change the organisational culture by just reading a book or attending a course, and no one in the XP community at least is suggesting this. In fact the Agile Manifesto makes great play of "values and principles".

I have worked in Agile (or agile, take your pick) bubbles, where a group of developers have taken responsibility to "improve themselves" and have adopted XP values, principles and practices. Customers love it, but others in the organisation perceive this "self organisation" as a direct threat. In the end the bubble is burst and the status-quo restored.

You can't generalise, but this is a common pattern, and I have spoken to several people from other teams that have had the same experience. Sustained continuous improvement needs a conducive environment. I just don't believe developers can make it happen by themselves.

Paul.

"Sustained continuous improvement needs a conducive environment."

Yes, It needs an individual to do what it takes to improve himself. I have done just that for my entire professional life in several different fields.

Sure, you might be able to do more faster if .... Well if pigs could fly, you could have ham flavored buffalo wings. If the individual does not take responsibility over his own improvement, the team doesn't have a chance no matter what the envrionment.

Hi Lionell,

No one is talking against taking personal responsibility. It isn't one or the other. Leadership has a responsibility too. My comment was talking to the need for responsible and effective leadership. Leaders have "personal responsibilities" too.

I don't think there is any disagreement here. Or is there?

Paul: Leaders have "personal responsibilities" too.

Yes but what do you do when they don't take that responsibility?

Waiting for others to change before you change is an instance of a deadly embrace: process A waiting for process B while process B is waiting for process A. The result is nothing happens. Its an eternal wait state. Its also a grand excuse for failure to perform. If your goal is not to perform, this is a perfect way to do it.

Each has the power to improve HIMSELF but has absolutly no power to improve others. If you improve, things have improved even if no one else has done so. OK. So the result is not as good as you would like. What does that have to do with the real world? That's only a problem in the world of your fantasies and wishes.

The starting point is within each of us, one individual at a time, taking personal responsibility for his own existence and performance. Give up waiting for the grand ubiquitous sacred other to change. Make a difference where you and only you have the power to make a difference.

Hi Lionell,

>> Yes but what do you do when they don't take that responsibility?

We got on and made change happen. My experienced was that in the end the "empire struck back". Like I said I applaud your methods, but there is no simple formula.

We can beat up on developers and make them responsible for everything. Or we can acknowledge that management has a responsibility too.

Paul.

Paul: We can beat up on developers and make them responsible for everything.

That doesn't work any better than acknowledging that management has a responsibility too. Like I said, the only person who has the power to improve is each individual within himself. Others can support or hinder but they can't do it for you. Nor can they do it for others.

Paul: in the end the "empire struck back"

Hey, rocks are hard, water is wet, and fire is hot. So use the rocks to build a fireplace, use the fire and water to make some hot tea. That is so much better than complaining that the rocks are too hard, the water is too wet, and the fire is too hot.

In other words, that is the nature of the beast. The good thing is you did improve something. That is a lot better than improving nothing. This is my point exactly.

This is likely more than enough on this thread.

Hi Lionell,

>> ... Like I said, the only person who has the power to improve is each individual within himself. Others can support or hinder but they can't do it for you. Nor can they do it for others.

Understood. And I totally agree.

Paul.

I read your blog. If you're not going to do Agile, don't call it Agile. I've worked with guys who had their own form of OO development. They thought business logic went in the servlet. The confusion was eliminated when I started calling their style 'Procedural'. So, your style could be called 'eligANT', which is Agile backwards plus some other stuff that doesn't make sense in Agile. Cheers!

I've added more fuel to the fire with my "Kaizen and Kaikaku" essay, here:

jamesshore.com/Blog/Kaizen-and-Kaikaku.html

So, yes, an Agile team should continuously inspect and adapt, and Agile gives you the tools to do so. And... there are some things that won't be visible to teams at first.

Will kaizen help these teams? Eventually. Does that mean we should hang them out to dry--wait for them to crash and burn, then hope they'll learn from their mistakes? Keep in mind that this is what we're seeing in the field: teams start out well, then struggle. It's good money for us consultants, but I'd rather people didn't get into that mess in the first place.

Jurgen Appelo's feeling that "experts asking for it all" are being hypocritical to what agile is really all about (Inspect & Adapt). I, for one, don't quite think he's getting it right, as I believe he's taking all this too literally. Like I said early in this response thread, "No one is saying definitively 'Thou must do exactly this or that', they are just saying "You need to pay attention to management, business, AND technical stuff (, then exactly how you do that you must inspect and adapt to get to)". Nonetheless, I like his spirit, and some of his ideas, and certainly the discussion attached to his blog post:
www.noop.nl/2009/02/the-decline-and-fall-of-agi...

And then yet another. Ron Jeffries continues to clarify what he's really saying:
xprogramming.com/blog/2009/02/06/why-is-refacto...

Cheers
MB

I would agree with Lionell's posts here. Adopting the "whole enchilada" in a brand new organization can and probably should be done, but there are not many of those opportunities around. Expecting an existing organization (more so a large organization) to change overnight and adopt a completely new system, however big the problems of the old system and however impressive the industry reports on the effectiveness of the new system, is simply not realistic. A reason is indeed because organizations tend to be conservative in the way the do things -- even when they recognize problems -- but another reason is that organizations have seen too many fads come and go.

It is, therefore, much more useful to introduce something new gradually, if needed, then build on early successes -- however limited -- and next time improve in ways that make sense -- whether adopting more of the features of a methodology/manifesto or just doing what makes sense (aka being agile, with lower case "a".) Large organizations have many projects running concurrently, and not all must start overnight doing things differently. Too much change, too rapidly, without experience of the implications of change can be worse. People must be convinced of the value of change (through those early successes) rather than being imposed it, in the name of industry trends. Asking for too much too early can kill a good thing. Most of the Agile principles (maybe not all) can be (and are) applied early (but each done well) in whatever non-Agile context team may find themselves and there would still be improvements over pure non-Agile practices.