As you probably know already, I consider "new" methods like SCRUM a YAM, a Yet-Another-Method. And there are a lot of YAM's. Like potatoes they are root-vegs and you can find them everywhere in any vegetable shop. Very versatile and you can bbq, bake, smoke, boil, fry, grill or even eat them raw with the right recipes. Some have other bumps and dents but at the end of the day, they all taste more or less alike.  

Well, coming back to earth, you know that a YAM, the Yet-Another-Method and not the vegetable, in the Application Development context is a box stuffed with techniques and tools of which probably most of the time more than 80% are "borrowed" from earlier emerged YAM's. Perhaps with another footprint or selection, other tools, given other names and acronyms, put in another context or changed just slightly enough to make them (false) distinct. There is a complete industry around YAM's and tools (YAT's ???) and many vendors make a living of it. I have nothing against that, it drives professional innovation but it make the life of the humble IT-professional a bit awkward.

SCRUM in my view is just another representation of other agile YAM's like IAD, DSDM, Lean Development, XP, RAD, Essential UP, SMART, DevOps and I am sure I missed a few dozen others. Sometimes it's even a bit embarrassing to see people so excited about "new" methods like SCRUM or DevOps. I can only hope that the "SCRUM-Masters" have enough knowledge and experience to learn from the past and look over the SCRUM-fence, But to give all the original YAM-inventors some credit, every YAM is usually based on some very good and new ideas to improve our profession indeed. Sometimes a YAM is just connected to a tool of the same vendor to create a complete (lock-in) package. But obviously, in an attempt to deliver a full size and complete new method, the "borrowing" from others is unavoidable. 

Yes, agile projects have sprints, iterations, time-boxes or what ever you call them. A short period of time with a working and implemented piece of software at the end with real business value. And yes, that forces  to use other workflows, techniques and sometimes tools than we are used to in a waterfall environment. But no, actually there shouldn't be anything against using good "agile techniques" like workshops, standup meetings, backlogs and the like in any kind of project. And to be honest, they  have been used in all sorts of linear projects for decades. Conversely, still looking at any agile method like SCRUM as a YAM, lots of the (intermediate) deliverables in agile are quite similar to those in linear ones. Maybe a different presentation but it's not another planet. We're still building and implementing IT applications.

So then, what are the real differentiators between agile and a linear projects?

So, first of all, the contract and as a derivate from that, the plan. In Information Technology we got used to fixed price/date/functionality contracts. That's (sort of) fine if it's clear where to aim at and the functionality is already, preferably written down, with enough detail. However in a true agile environment the targets move. Business and economic outlook changes, customers are tempted by a new competitor, new technologies emerge suddenly. So an agile contract should be more focused on real collaboration where goals can change and so the priorities, functionality and time-to-deliver. All written down on just a few pages with sized budget- and time-boxes as the only quantitative elements. After all, there is no functionality yet but of course there are demands and restrictions. Maybe there are just some good ideas to beat the competition with new IT embedded into a product or service.

As a consequence contract- and expectation management is very very different. Anything can change everyday and it's the responsibility and challenge for everybody to stay tuned to reality and move with the flow with the project leader at the wheel. Note, I mean with sense, not shooting at everything that moves. Needless to say that a project leader should be able to manage this kind of process. Not every one can (obviously).

Thirdly, and most importantly, the people in the teams. If business and technology targets move and should be adapted to, the above mentioned "sense" is in fact a continuous replanning and recalculation of all functionality given the budget- and time-boxes. In a classic environment a "change" was usually followed by a request for more money. In a agile environment it's just a rearrangement of priorities and so probably money as well. Mind you, it's still a collaboration. The client expects professional judgement of the vendor as well. People who are just asking what the client wants, will be out of business soon in a true agile setting.

This means that if we all "go agile" what I always call the "single specialist" has become a commodity. Knowing a lot about just one business or one technology area is not enough to survive in a agile environment anymore to maintain innovation speed in business and a face-to-face communication situation every day. On top of that, in "off shore" countries is pretty easy to develop specialists in any topic in a large volumes for relatively little money. So, a bit black and white, no need to have specialists onshore anymore. At least not in the definition and volume we have today.

What is needed in a local situation, where ever on earth that is, are people who are not generalists but truly multi-specialists. At least one specialty in business and another one in technology. Additionally, a vast knowledge of techniques to be executed in any kind of workflow, agile or not. And finally, superior communication and collaboration skills to act as an equal partner to the clients and their users. 

CIO's are screaming for this new breed. Gartner calls it the "Renaissance Professional", Forrester the "Business Technologist" but their are many names for the same kind of people.

Just like YAM's.

(This article has been published on my old website earlier)