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.
I’ve given up predicting it, see Dan Gardner “Future Babble : Why Expert Predictions Fail – and Why We Believe Them Anyway.”