Somewhere in the overlap between software development, process improvement and psychology

I’m coming out as not-Agile and not post-Agile

Big A vs. Little a

Huh? What? I’ve written a fair bit on this blog about agile topics, but I always try to write about agility with a small “a”. I’m not really into Agile with a big “A” though – I’m not into doing things according to a set of rules and having arguments about whether I’m doing it right or not. I’m not anti-agile, but I’m increasingly anti-Agile.

To me, the ideological arguments, definitions of everything, frameworks, money-spinning certifications and money-spinning tooling are what’s wrong with doing “Agile”. Being empirical, reflecting and adapting, honestly communicating and putting people first as an approach is being “agile”.

I don’t really like the term “post-Agile” either though as it comes with a bunch of baggage and is easily misinterpreted – and I still see benefits in adopting agile practices. I don’t want to see another specific set of rules or a statement or beliefs with elitist signatures. For me what’s next after agile is about dropping the ideology in software process, destroying the ivory tower of trademarks, formal definitions, money spinning tools and money-spinning certification programmes.

We need to get rid of the League of Agile Methodology Experts and if anyone says “Ah, but this is different” when showing a website of process content then you have my permission to hit them with a stick.

So what does the future look like?

Software development is a complex social activity involving teams of people forming and self-organising to work together, sometimes in teams of teams which is even harder. As technology is increasingly abstracting up and raising in maturity so is the way that developers, managers and organisations think about software and doing software. I think the problem is getting increasingly social, and the solutions will start looking increasingly social using more “soft practices”.

Software process improvement agents/consultants/coaches/mentors (including myself) need to take a long hard look at themselves. Are they telling people how to do it right when they can’t even write HelloWorld in a modern language? I’ve said that to some acquaintances in the industry, generously qualifying “modern language” as something significantly commercially used in the last 10 years and seen them look quite offended at my insulting affront to their professional integrity. I’ll go out on a limb and say you can’t coach a software development team if you don’t know how to write software.

So… software process improvement?

TOverlapping concerns in process improvementhe world runs on software, it’s everywhere and it’s critical. Getting better at doing software, improving the software value chain, is a noble aim and will continue to be as it means getting better at doing our businesses and our lives.

For me process improvement (dislike that phrase as well) is going to be more about combining psychology based business change practices with the best bits of a wide variety of ways of working (agile, lean, Scrum, what you currently do, RUP, Kanban, various workflow patters etc.) with technical software development practices like continuous integration, continuous delivery.

We need to work together, not as “leaders and followers” or “consultants and clients” but as collaborative peers working together to apply specialist skills and experience so that we can all improve. Smart people should be treated as smart people, we have much to learn from them and should be thinking in terms of fellowship rather than leadership.

I’m calling this overlap “soft practices”* because the term is evocative of:

  • The practice of doing software
  • The practices involved in doing software
  • Being able to deal with people is sometimes called  having “soft skills
  • Soft power

What do you think about “post-Agile”?

* I’ve even set up a company called Soft Practice to do this stuff, that’s why I’ve not been blogging much recently, who knew there’d be so many forms to fill in!

Edit 14/8/13: Seems others are now talking about the same things: Ken Schwaber, Dave Anderson, Aterny

4 responses

  1. dtoczala

    Love the tone of this. I heard someone say that as soon as you use the words “always” and “never”, you lose credibility. Unfortunately most software process models attempt to do just that. Developing software does take a tremendous amount of “soft skills” now. We’ve gone from an age where people were afraid to touch the keyboard, to one where children are learning programming skills at the age of 10. The toughest part of the whole thing is getting the interface between software development (a team sport, with soft skills and soft requirements), and business (with project management, schedules, earned value and variances) set up correctly.

    September 4, 2012 at 9:07 pm

  2. Thanks Dan, totally agree, in fact that’s what I’m currently working on with one of my clients – there’s a real mismatch between a downwards project culture and an upwards team culture causing all sorts of interesting problems.

    September 4, 2012 at 9:55 pm

  3. I concur.

    I think about software development practices and methods as a toolbox of techniques that I, (that should be we as in the team I am a member of) can apply to a problem that we are trying to solve. Sometimes I want to use a scrum-like approach sometimes Kanban, and I’ll apply whatever underlying sub-practice that I think will help me and the team overcome our current challenge, so that might mean paired-up dev & tester, TDD, to use or not to use planning poker etc.etc. I hate ideological fanaticism, ologies and isms, they just cause irrelevant argument and contribute zero to the products development, I remember when I did “real programming” the gurus of the day arguing about whether a class should be represented on the design diagram as a box or a cloud….. For crying out loud how much did we pay those idiots…

    If you are “lean ” that’s just more waste 😉

    One of my clients is really enlightened in their approach to developing software, the teams are very open to trying out different techniques, they just want practical, pragmatic guidance and advice on how to produce a good quality product that does the right things, with minimal overhead in the process. They also highly value the fact that we actually contribute to the product development, not just pontificate and “tell them what they should do” but figure out an approach and actually do the job with the team(s).

    I’ve worried for a long time about not being at the sharp end of coding for several years now. Is it like trying to explain flying without ever having piloted a plane? So I’m glad I built that Linux machine and got my “Hello world” java prog done and JUnit test running, I still think any sensible team will totally refactor any of my code though! But I’ve still “got it” 🙂

    September 6, 2012 at 6:41 am

  4. Good point Steve, I don’t mean that everyone has to be a Java expert to talk about software but should be at least aware of the basics. I wouldn’t learn to fly a plane from someone who’s only read books about them – there’s no substitute for practical experience.

    September 6, 2012 at 9:44 pm

What do you think?