The State of Agile – Mark Levison

Mark has been in software development for over 20 years and an Agile practitioner since 2001. Introducing Agile methods one practice at a time inside a small team. From 2006 – 2009, as an employee of Cognos, he’s introduced Scrum to the organization and coached a number of teams. As part of that process he designed a Test Driven Development adoption strategy and introduced of a number of practices to support it.

As an independant Agile/Scrum Trainer and Coach (Agile Pain Relief Consulting) he has introduced Scrum to a number of organizations.

Mark’s research interests including the application of neuroscience to Agile software development and training. Mark is an Agile Editor at InfoQ and has written dozens of articles on Agile topics. He also publishes a blog – Notes from a Tool User.

How has Agile changed?

It’s interesting the fundamentals haven’t changed, but the diversity and attitudes have changed completely.

When I first started to introduce Agile my team mates were ok with the technical practices and over the next few years we made real improvements in code quality that can be attributed to: Continuous Integration, Unit Testing, Peer Code Reviews (Pair Programming) and Discipline.

However on the rest Agile/Scrum cannon: Daily Standups, Retrospectives, Iterations went over like a lead balloon.

Outside of my team people would say Scrum is that weird stuff or it won’t work here it only works web based companies, startups, or whatever we’re not.

Nearly 10 yrs later I have the opposite problem people have now figured out that Agile/Scrum/xxx work. They flock to training and ask for coaching they understand the transition will be hard and take time. They embrace the mechanics (i.e. meetings, user stories, story point estimation, …). Now we have two problems: the engineering practices don’t get adopted and people often miss the spirit of Scrum. With new teams we can usually get the mechanics of Scrum down pat in only a sprint or two, once people’s minds are open its a remarkable simple process.

The problem is when start introducing Unit Testing (or worse TDD) and people will say: “Wow that’s tough, we really don’t have time for that”. So frustrated was I with this experience that I’ve written an article Technical Debt a Perspective for Managers just to explain the holes they’re digging for themselves. Managers see the amazing results other Agile development projects have achieved and want them now, Developers see the pressure to create working software and just retreat to the technical skills they know. As a community we need to do a better job of educating all parties as to the importance of the technical practices and give them realistic time lines to become proficient. Expecting developers to learn TDD in a few weeks with no support just isn’t realistic.

The other problem happens with people who learn the mechanics without understanding the principles behind Agile/Scrum. For example: some manager’s hold a daily scrum that is just a form of having the team report to them daily and runs 30 minutes instead of the <15 min. Other examples abound, but the point is that these people have learned the mechanics without understanding what it means to be self-organizing, transparent or truthful. Mechanically agile processes seem to be the source of many “Agile ruined my life” blog posts recently. Unfortunately this problem is inevitable as Agile grows up and becomes mainstream their will always be adoptions go wrong.

The future?

I’ve given up predicting it, see Dan Gardner “Future Babble : Why Expert Predictions Fail – and Why We Believe Them Anyway.”

You can find Mark Levison at @mlevison and blogging on

5 Replies to “The State of Agile – Mark Levison”

  1. It’s interesting you mention the split between technical practices and process/management/cultural aspects of agile methods. Personally, I see the technical practices as generally worthwhile regardless of the process. Although the practices you mention are usually associated with agile methods, agile methods aren’t necessary to employ the technical practices. The practices are orthogonal to process. I’ve had clients request training in TDD, CI, pair programming, etc. with the specific caveat that they did not want to hear about “agile”.

    1. The technical practices you mention are indeed orthogonal to agile methods, as in “they cross path”. They crossed path exactly when XP was born.

      Dave, I am just wondering. Apparently, someone went there and actually made such a terrible job at selling Agile (probably saying things like, architecture is overrated, you don’t need business analysts or documentation, or even project managers for that matter) that they refuse to hear where those technical practices come from. Now, should someone else (or the same person, why not), come back and teach them TDD+CI+PP in 5 days? What do you expect the results to be? Do you really think that development organization will get better at producing quality software?

      Maybe someone should start by understanding why they are in such a state of mind. Maybe they have a culture problem that’s hampering their ability to learn, and teaching their “programmers” technical practices will not help.

      I fully agree with Mark’s analysis. And I will go further by affirming that technical practices cannot easily be dissociated from managerial ones. In an organization that allows a climate of fear and competition, not allowing time for retrospectives and continuous improvement, keeping silos and rewarding individual performance, TDD, CI, and even Pair Programming will NOT work. Unmotivated and poorly trained developers will write unit tests… that tell nothing about whether the code actually works. There might be no refactoring and the CI system might run loads of empty test cases every night… And this organization will not have any value out of their technical training (on the contrary).

Leave a Reply