“I’ve personally witnessed several failed agile adoptions that could have been prevented. The first was in a company that had spent more than a million dollars on its transition effort. Executives brought in outside trainers and coaches and hired five people into an “Agile Office” to which new Scrum teams could turn for advice. The company’s failure was the result of thinking that the implications of adopting Scrum would be restricted to only the development organization. The executives who initiated this transition thought that educating and supporting developers would be sufficient. They failed to consider how Scrum would touch the work of salespeople, the marketing group, and even the finance department. Without changes to these areas, organizational gravity pulled the company back where it had started.”

“Perhaps you’ve read a book, on Extreme Programming and have decided that is the right approach for your company. Or maybe you attended a Certified ScrumMaster training course and think Scrum sounds good. Or maybe you read a book on a different agile process, and it sounds perfect for your organization.
In all likelihood, you’re wrong.
None of these processes as described by their originators is perfect for your organization. Any may be a good starting point, but you will need to tailor the process to more precisely fit the unique circumstances of your organization, individuals, and industry.”

“With most organizational change, after someone figures out the right or best way to do something, that way of doing it is captured as a ” best practice” and shared with everyone else. For some types of work, collecting and reusing best practices is a tremendous aid to the change effort. An organization that is selling a product to a new type of customer may, for example, capture best practices for overcoming objections from potential customers. When transitioning to Scrum, however, collecting best practices can be dangerous.”

What is interesting for me in these quotes is the emphasis on Agile being a process and not a technique. You can’t just apply existing recipes to your organization and think that you are “done”. You have to think on how you can spread the spirit of Agile in your organization and, when you think you are “done”, continue to try to improve your process every day. The same message is conveyed in a Karl Scotland article about Kanban that I am just reviewing and that will be included in the Summer 2010 issue of Methods & Tools. Another very interesting article by Yves Yves Hanoulle on Core Protocols will give you tools to support the improvement process.

Reference: “Succeeding With Agile”, Mike Cohn, Addison-Wesley, 463 pages, IBSN 978-0-321-57936-3

Methods & Tools articles on Agile adoption

Adopting an Agile Method

Agile Delivery at British Telecom

Creating an Agile Environment

Agile Coaching Tips

Five Symptoms of Mechanical Agile

[...] I started a conversation with the question that had been bothering me: “How do you reconcile the lean view that tests are waste with the need for tests in software development?” Mary’s immediate response: “Unit tests are what let you stop the line.” (quoted from the Foreword by Dottie Acton)

In our experience, the most common causes of policy-driven waste in software development are:
1. Complexity
2. Economies of scale
3. Separating decision making from work
4. Wishful thinking
5. Technical debt

The strategy of designing the effort to fit the constraints, rather than computing the constraints form the design, is absolutely the most effective way to achieve reliable delivery.

Reference: “Leading Lean Software Development – Results are not the Point”, Mary and Tom Poppendieck, Addison-Wesley, 278 pages, IBSN 978-0-321-62070-5

It could seem very provocative to propose an approach based on the slogan ” Results are not the Point”. In their book, the Poppendieck defend the idea that there are many good managers around that could foster the adoption of lean practices. From my personal experience, most of the managers thinking “results are not the point” do this because they think “costs are the most important point”. This is why I think that companies that adopt agile or lean approaches want results…. and quickly! We could all wish that more managers and developers take the time to read book like this one, but even if it was the case, I am very dubious that many companies will really abandon their “command and control” and “short term vision” culture.

Get more details on this book or buy it on amazon.com
Get more details on this book or buy it on amazon.co.uk

“Bug fixing often uncovers opportunities for refactoring. The very fact that you’re working with code that contains a bug indicates that there is a chance that it could be clearer or better structured.”

“As a rule of thumb, for every user who tells you about a problem, there will be between 10 and 100 other users who experienced the same problem and didn’t think to get in touch.”

“Once you start to get on top of your quality issues, you’re going to want to start refactoring the old, crufty, untested code. And you should – the point of exercise is to clean up problems, and refactoring is a key element of that process. Remember, however, that refactoring crucially depends upon the support of an extensive suite of automated tests. Without tests, you’re not refactoring. You’re hacking. So, how do you refactor untested code? You don’t. The first thing you do is to write the tests.”

Source: “Debug It!”, Paul Butcher, Pragmatic Bookshelf, 214 pages

Old and new programmers are still writing programs, but the technology to achieve the goal has changed. When a new technology is sufficiently different, you can’t evaluate it in terms of the old technology.”

Source: Stephen J. Mellor, Letters section, IEEE Software, March/April 2004

Sometimes new ways of doing things come in our life and it might be difficult to adapt. If you are used to drive a car and you take a train, you don’t ask how you are going to “turn left”: the train just follows the tracks. However, you have now to go to a station, buy a ticket, look at timetable, etc… This could be the same thing with some of the software development approaches that have recently become popular.

Functional programming, domain driven design or frameworks that favors convention over configuration like Ruby on Rails can offer a new perspective about what you have to do to develop software. If you have the time (and the energy) I would like to strongly encourage you inform you about these approaches or even better to try them. Ironically, the above quotation was in reply of a letter about UML and Model Driven Architecture. Six years after, there is not a lot of people still caring about this way of developing software, as it is for Smalltalk or assembly languages.

Resources

* Wikipedia.

Functional Programming

Domain Driven Design

Convention over configuration

* Articles

Functional programming – HaskellWiki

Functional Programming For The Rest of Us

Ruby on Rails guides

An Introduction to Web Development Using the Ruby on Rails Framework

An Introduction To Domain-Driven Design

An Introduction to Domain Driven Design

“Any construction project begins with raw material, and as Confucius suggests, the nature of the raw material is critical to success – so much that you shouldn’t even begin if the “wood” is poor. Even if you have sharp, finely honed tools, your project will still fail if the raw material isn’t sound. And what, might you ask, is the raw material of software development? Us. People. We are the only raw material of consequences in software development.

[....] So how do we prepare this material? Obviously, we don’t want it to be “rotten”, but how can we tell? How can we tell if hidden voids lurk beneath the surface, just waiting to ruin the project once we start carving? When you lack the right material, you’ll keenly feel its absence. For example, warning signs might include:
* The developer who only uses one favorite solution for every problem
* Folks who don’t learn from mistakes – or worse, are too afraid to make any
* The developer who can’t be bothered to tell anyone what he’s doing and why

[...] Painful as it is to admit it, for most people, most of the time, the problems that come up are our own fault – not the compiler’s, not the OS’s, not the database vendor’s, not our bosses’, and not our coworkers’. Yet many people and team, when facing a disastrous problem, first embark on a search (aka witch-hunt) to fix the blame. It goes somewhat against human nature, but you should always try to fix the problem, not the blame. Remember we all write software in our heads, so it makes sense to go ahead and take responsibility for it. “The cat ate my source code” just doesn’t cut it anymore – when problem come up, we need to invent options, not excuses.

[...] The isolated, lone developer huddled over a terminal with a can of highly caffeinated cola offers not only an inaccurate and misleading stereotype, but a dangerous one as well. Isolated developers can inadvertently duplicate other teammates’ work, use outdated or inappropriate methods, and even build the wrong product – at least, not the product the sponsor wanted. Instead of taking more Java and UML courses, we should work on our technical writing, public speaking, and group facilitation. A CPU with no I/O isn’t very useful. Neither is a developer who can’t communicate.”

Source: Andy Hunt and Dave Thomas, “Preparing the Raw Material”, IEEE Software, September/October 2003

My only disagreement with the authors is that I think that the end users are also essential raw material in software development, but I fully agree with the idea that we should take responsibility for our own limits. Fresh out of the University, one of the first important modification that I did created a big trouble, because I didn’t tested it with the right files, even if my supervisor suggested this to me ;o( This taught me that being confident with my work could be good… but thoroughly testing it was even better ,o)

About adding value

“When Ward asked Toyota’s American engineering and managers how much time they spend adding value (i.e., actually doing engineering work), their response averages 80%. The same question asked of engineers and managers at American automobile companies averages 20%. How can you compete with companies that are getting four times as much value-adding work from their development engineers.” (referenced from “Product Development for the Lean Enterprise”, Michael Kennedy, the Oaklea Press, 2003)

About technical knowledge

“As a software development consultant, I’ve never encountered a successful software company (although my sample size is limited) in which the team and project leaders were not technically savvy. [...] Championing technical excellence requires that the project leader, and team members in general, understand what technical excellence means – in the product, the technology, and in the skills of the people doing the work.”

About leading or managing

“Agile leaders lead teams, non-agile ones manage tasks. How many project managers spend hours detailing tasks into Microsoft Project and then spend more hours ticking off task completions? Unfortunately, many project managers like this task oriented-approach because it is concrete, definable, and completion seems finite. Leading teams, on the other hand, seems fuzzy, messy, un-definable, and never complete. So naturally some people gravitate to the easier – managing tasks.”

About self-organization and anarchy

“Self-organizing teams are at the core of the agile management, but the concepts have become corrupted – and counterproductive – in parts of the agile community. Although self-organizing is a good term, it has, unfortunately, contingent within the agile community who encourage an anarchistic management style and have latched onto the term self-organizing because it sounds better than anarchy. As larger and larger organizations are implementing agile methods and practices, the core of what it means to be agile – an empowering organizational culture – may be lost because large organizations will reject the cultural piece of agile.”

About the value of a plan

“When we “plan”, we expect the actual project result to conform to that plan, and then deviations become team mistakes or sign of the team’s failure to work enough. When we “speculate”, we take the opposite perspective – it’s the plan we suspect was wrong. The plan, or speculation, is a piece of information, but it is only one piece that we will examine to determine our course of action in the next iteration.”

About software malleability

“Software is the most malleable product. Companies need to use this characteristics to their competitive advantage, and sticking to traditional waterfall development negates this advantage.”

Reference: “Agile Project Management”, Jim Highsmith, Addison-Wesley, Second Edition

“The art of Agile coaching is understanding the situation, the values underlying Agile software development, and how the two can combine. As an Agile coach, you don’t need to have all the answers; it takes time and a few experiments to hit on the right approach. We’ve worked with teams who’ve come up with great solutions, and we learn from every team we work with.”

“Don’t expect to get recognition for your work as an Agile coach. It’s a supporting role rather than one that delivers direct benefits. A good coach gives credit to the team. When you work on an idea with Frank, it’s Frank’s idea if it succeeds, and if it doesn’t, then commiserate together.”

Some good points to keep in mind the next time you will be looking for some help to transition to Agile.

Source: “Agile Coaching”, Rachel Davies and Liz Sedley, Pragmatic Bookshelf, 250 pages

Get more details on this book or buy it on amazon.com
Get more details on this book or buy it on amazon.co.uk

“Testers cling to the concept of an independent QA team for many reasons, but the main reason is fear, specifically:

* Fear that they will lose their QA identity

* Fear that if they report to a development manager, they will loose support and programmers will get priority

* Fear that they lack the skills to work in an agile team and will lose their jobs

* Fear that when they’re dispersed into development teams they won’t get the support they need

* Fear that they, and their managers, will get lost in the new organizations

We often hear of QA managers asking questions such as “My company is implementing agile development. How does my role fit in?”. This is directly related to the “loss of identity” fears.”

Source: “Agile Testing”, Lisa Crispin and Janet Gregory, Addison-Wesley, 2009

Source: “Managing Iterative Software Development Projects”, Kurt Bittner, Ian Spence, Addisson Wesley.

Transitioning from a traditional approach to iterative software development is more a change of mind than a schedule adjustment. So try to be honest… or at least as honest as you can be ;o)

You must begin by writing a unit test for the functionality that you intend to write. But by rule 2, you can’t write very much of that unit test. As soon as the unit test code fails to compile, or fails an assertion, you must stop and write production code. But by rule 3 you can only write the production code that makes the test compile or pass, and no more.

If you think about this you will realize that you simply cannot write very much code at all without compiling and executing something. Indeed, this is really the point. In everything we do, whether writing tests, writing production code, or refactoring, we keep the system executing at all times. The time between running tests is on the order of seconds, or minutes. Even 10 minutes is too long.

Robert Martin

http://butunclebob.com/ArticleS.UncleBob.TheThreeRulesOfTdd

Besides these rules and independently of an agile approach, I always like as a developer being able to verify quickly my code, because it makes much more easier to find all the errors I do ;o)

People come to those styles because there are a bunch of decisions that work well together. Taking one bit of that out and using it isn’t necessarily working well. So by writing a pattern kind of format I get a chance to say: “How do you name fields?” Well, let’s see. What are all the things that you might want to communicate? What things might a reader be interested in if they are reading a name of a variable? What are all the constraints on naming, both in terms of like cognitive constraints. Abbreviations don’t work well for a variety of reasons, but why? Really long names don’t work well, but why? By writing in terms of patterns I get an opportunity to think about all of those. Here is my rule for naming variables, to use simple names that describe the role of the variable in the computation, but if I just said that as a commandment, someone could copy that, but they don’t really get it in the same sense that I care about, and more importantly when that is not the right rule, they don’t get any sense of what thinking was behind that rule, so they don’t know when to break it.

Source: “Kent Beck on Implementation Patterns” on infoq.com

The main point in Kent Beck’s words is that you cannot use software development methods and tools without knowing the context in which you should use them. Every time you find something interesting and new, you should ask yourself why and when you could use it, and why and when you should not use it.

As agility is crossing the chasm, however—as you can see if you attend any big software synod such as SD East or West or OOPSLA (Object-Oriented Programming, Systems, Languages, and Applications)—many more people say (or repeat) rather uninformed messages with a strong conviction and little background, scoffing at anybody who dares to question their claims, even if it’s just a clarification about scope or context.

For writing these words, I’ll be shot dead as a traitor to the agilism cause, a defender of the waterfall church, a dinosaur, the über-curmudgeon, though I do value agility or agile practices in the proper context, and with the tainted glasses of my own 33-plus years of experience. But I would like my friends and colleagues to keep cooler heads, to question assumptions, not assume too much of a common, shared mental model, and contextualize what they hear, read, say, or write.

Source: Philippe Kruchten, Voyage in the Agile Memeplex

These are word of experience from Philippe Kruchten. It should be repeated that there is no silver bullet in software development and that many approaches will fail in specific contexts when their essence is not understood, but rather people are just trying to apply some recipes without intelligence and common sense. Every new approach will have its share of zealots that will apply them as strict religious rules. I am a strong believer that the success of software development depends more on adapting existing tools and processes to specific situations and not the contrary.

News comes from the Department of Labor that productivity growth in nonfarm business in the U.S. hit a critical number in the third quarter. That number was zero, as in naught, as in nothing, no growth at all, not even something you could round up to a minuscule decimal of some kind. [...]

Let’s look at what forces are coming together to suppress productivity growth, to see if we can augment them in some way. [...]

Second, I’m thinking that the reason we kept being more productive in the first place wasn’t so good. When I started out, my department had 20 people rushing around working very hard. Then the corporation, under pressure from Wall Street to grow our stock price every day, decided to do what analysts, investment bankers, and business reporters all agree is the most terrific thing a successful enterprise can do: fire a bunch of people and make those who remain do the work that used to be done by others. Before long, we had ten people doing the work of 20. This naturally produced impressive gains in individual productivity. Of course it did! But at what cost, I ask you. Actually, I’m not asking you, I’m telling you. A big one.

The things that’s happened now is that corporate America is just about done firing people, because if management wants to fire any more people, it’s going to have to start firing itself. That’s expensive. Firing an executive is often more expensive than retaining him.[...]