Agile Elitism – Undoing the Good

I’ve been in IT for a bit over 20 years. In that time I’ve been a business analyst, a support desk lead and, for the most part, a tester. I’ve designed processes, I’ve redesigned processes, I’ve redesigned myself and my testing beliefs. When I first starting testing, as a dedicated tester, I was very much “by the seat of my pants”. I had ideas how to go about testing and I sort of followed them. I was then sent to an ISTQB Foundation course. I came back from that with a framework and an approach. It just made sense. It gave me a structure that I lacked, or more correctly, it gave me a structure and approach approved by others. I was somewhat evangelical about the whole deal when I returned to work with my new shiny certification.

Funny thing about shiny stuff, unless you keep polishing it (which in my view is often little more than reinforcing your biases) it tarnishes and stops looking the way it used to look. This is exactly what happened to me. What I thought I needed to do and what ISTQB told me were far apart. Writing detailed test cases sucked (and also led me to considering exiting testing). Having to maintain them sucked more. I wanted to engage with the business analysts and developers earlier, I wanted to write less and test more. I wanted to pair with other testers (before that practice had a name). I learnt very quickly that what I thought the software would do based on the specification, and what it actually did when it got me, were often worlds apart. I also found that when I focused less on the test cases and more on observation of the software I found really interesting bugs and made interesting discoveries that I could share. That was basically how I found context driven testing and a whole new view of testing. It’s also how I became substantially different to the majority of other testers I worked with for much of my professional testing life.

The reason I outlined a brief of my background is because I’m finding the same thoughts going through my head around Agile/agile as I did about testing. My first introduction to agility was through being in a waterfall project team that thought holding daily stand ups made us agile. At that point I lacked the experience I have now and just went along with it. It was slightly useful but mostly slightly annoying. The stand ups rarely revealed anything we didn’t already know. Mind you, nobody had the foggiest idea about Agile, it was just a directive from management (who also lacked the required awareness).

My next interaction was at the same company. A decision was made to “be Agile” and scrum was the adopted framework. It was doomed to failure because management had no idea of what was required and had no interest in changing their behaviours. That Agile was a mindset, rather than a concrete “thing” never occurred to them. From a waterfall development shop 5 scrum teams were formed. There was minimal coaching, for many there was minimal interest in learning new behaviours. At some point, because of my enthusiasm to find better ways of working, coupled with the amount of reading and learning I did on Agile and scrum, I slid into the “Agile evangelist” role (something I would now avoid with great enthusiasm)  and ended up coaching several teams on adopting good behaviours such as collaboration, testing from start to completion (what is often called “shift left” – horrible term – please don’t use it), writing testable stories and breaking stories into small slices, or least making the stories small and delivering small bits of testable code frequently. The move to agility failed, badly. Lack of trust and a management need to both micromanage and blame overwhelmed everything else. Interestingly, and not all that surprisingly, the teams I worked in loved the (fleeting) ownership and responsibility shift.

Since that gig I’ve worked at other places. My time at Locomote was interesting. It desperately wanted to embrace Agile but in no way did it tick of on all the manifesto principles and values. Again, scrum was the chosen framework. There was a bunch of waterfall behaviours that persisted, BUT, and this is the key bit for me, there was a desire for change, a desire to get better at producing high quality software. A willingness to reflect on what had been done, what could get better. Transparency, at the team level, was pretty good. At times it was patchy from higher up. At least here there was a feeling that we worked as teams wanting to be more agile. The cool thing for me was that with good Scrum-masters I was able to contribute ideas to improving the team and also focus strongly on improving testing specifically.

It was actually during this time that I really started to question Agile and how people spoke about it. Too much talk about “you don’t do this, so you’re not Agile”, too much focus on exclusion as if Agility is an exclusive club with strict entry criteria. I call these people “Agilistas” (a term somebody else coined, can’t remember who). I got tired of these discussions and discussions that simply focused on reinforcing some level of “purity” above a culture of consistently getting better as a group or company in sustainable ways. In short I’m over being told that unless the company I work for does a bunch of practices, that might not be relevant in context, the company does not qualify as agile.


My current company, HealthKit, may not pass the “Agile purity test” that “Agilistas” demand. From my perspective HealthKit is the most agile place I have worked. It is a group of people who prize and practice:

  • transparency
  • reflection
  • adaptation

We collaborate a lot, we idea swap and challenge each other with respect and in an environment of safety. We adjust our planning as our views change, based on customer feedback or discoveries we have made, things  we have learned. When someone needs help it is willingly and rapidly made available. We actually pair a lot, something that only solidified in my mind this week. The best thing is that this is what you might call “natural pairing”, it’s not really pre-determined, it’s more on a “needs” basis. You know, “I need some assistance”, “here, lets explore what this does together”, and “hey, you know this area better than me, let’s work together, knowledge share and see what we can find”. I’ve had plenty of sessions where I ask for some assistance and then the person stays a little while longer to contribute testing ideas and observations. I work with 2 other testers and we are always involving each other, knowledge seeking, sharing, helping, working through some testing side by side. At Locomote we tried to schedule pairing between testers, it didn’t work. Pairing requires desire and willingness not a schedule.

As far as I know the developers at HealthKit don’t do a lot, if any, development using TDD (if they do it must be discussed in secret developer meetings). We don’t have a huge amount of automation, it is not currently a “way of life” (although automation is going to receive some specific attention I believe – even better the focus is automate the right things not everything). We don’t use Jira, we don’t write user stories using INVEST, or anything remotely similar, we don’t have enormous planning meetings or estimation meetings. We meet once a day for a whole team stand up session to discuss what we have done, what we are doing, raise any concerns/blockers and share things learned. To be honest, the rapid reduction of formal meetings, compared to past work places, is really appreciated. If it helps any “Agilistas” reading this, we release frequently, 2 or 3 times a week.

I’m at a company where the people are truly passionate about building excellent software and keeping our customers happy. We respect each other, we talk honestly and respectfully with an eye on sustainable, continuous improvement. Transparency is promoted by all and we are a genuinely happy and fun workplace. Best of all the culture is neither top down or bottom up, it is both because the culture is shared by all. Our CEOs sit in the office with everybody else (and no, I don’t mean the same space but in offices with doors closed) so if the culture wasn’t jointly owned it would be glaringly obvious.

So I reckon there are a bunch of people that will tell me HealthKit doesn’t meet their definition of Agile. That’s fine because I’m done having those discussions, they are pretty much irrelevant. My thoughts and understanding have been shaped by my experiences, observations and shared discussions. This doesn’t make me the oracle of “right” but it gives me more than “I read it in a book” or “this is what course ABC” told me. I’m in a company with an extraordinary culture, committed professionals that work together to create the best software we can for our customers, always on the lookout for ways we can improve. If what I’m currently part of isn’t Agile, according to the “law of the Agilista”, I really don’t care.




10 thoughts on “Agile Elitism – Undoing the Good

  1. Is there ever a ‘right’ way of doing stuff, or is it more a case of what works best for you?
    Is there a best selling book on the ‘right’ way of doing stuff, or are there different ways that negate what any book says?
    Was there ever a cargo cult that truly replicated the real thing?
    Paul may have his views, I may have mine and you may have yours. Those views don’t have to be the same, do they?
    Agile is a tool, not a weapon.


  2. Thanks Paul – good post. I’ve was also an evangalist in the “Agile” world for a while, but have been in the “agile” world for much longer. There are really good practices we can take from methodologies like eXtreme programming (ex. – TDD), and other practices which we have found to be worthwhile like exploring examples (call it ATDD, BDD, SBE) that have spawned because people adapted what they were doing. I believe the agile values and principles still have meaning. The practices that people repeat are usually methodology specific (but not always).

    To me, the goal for teams is not to “be” agile, but use use the values and the practices to get to what Elisabeth Hendrickson refers to as her acid test… “Agile teams produce a continuous stream of value, at a sustainable pace, while adapting to the changing needs of the business.”


  3. The mention of not using TDD interests me. How does your company or team handle regression testing? How does your team know that changes they made didn’t change any previously working behavior?
    And if your developers are passionate about building excellent software, how do they know what they build is truly excellent, and not just average? And same with customer happiness. How do you know your customers are truly happy and not just “not unhappy”.


    1. I’m unclear if you are grouping TDD and regression testing with your opening 2 sentences. In terms of checking for regression it is people checking and testing based on discussion and some other artefacts. There is also some automation in use. The excellence of our software is a judgement that is, ultimately, in the hands of our clients. HealthKit has a robust bidirectional feedback loop with customers. We have a lot of information (both conversational and written) about how our clients feel about HealthKit. We also get a lot of information about what our clients want in HealthKit so it helps us move the software in directions that are desired by our customers.


      1. I do group TDD and regression testing. To me TDD is best way to achieve useful and efficient automated regression testing. As a developer I find is highly useful to have fast and automating way to check if changes I made didn’t introduce regression. Having to wait for someone else to check for regressions is big source of slowdown and inefficiency for me.

        I wonder, reading your article, that you put big value on feedback from customer and collaboration, but your focus on efficiency of your process is less important? You said that you prize adaptation. How do you know that practices you adopt have actual positive effect on your process? Do you use any metrics to measure that?


      2. Clearly TDD is important in your context and seems personally important to you. It is good to have practices in which you see value and enjoy using. Efficiency of process is important, I’d go so far as to suggest any competently run business has to have an eye on efficiency. As a group we discuss experiences, we discuss where the process appears to be slow or simply not working well in meeting objectives. This enables us to run experiments to test changes. Do we have metrics, yes we do. Do we need metrics for every improvement experiment, no. Numbers are a way to tell a story but not the only way. Improvement in process can often be assessed through discussion and observation of better experiences, better outcomes. Again, context is important.

        Liked by 1 person

  4. “Mind you, nobody had the foggiest idea about Agile, it was just a directive from management (who also lacked the required awareness).” Resonates with my experience almost eerily.


    1. I’m guessing many have had the same experience. It’s sad when people think that narrow, divorced practices, in the name Agile, are actually what agility is about.


  5. Great article that reminds me of my experiences with ‘my’ teams so far. I work as a freelancer and I am called to companies to introduce Scrum or to do agile coaching.

    What I found was always different. The most important thing was always to motivate the team to go their own way to become more and more efficient and effective.

    That doesn’t happen overnight, but over time it gets better and better.

    What you describe that the CEOs are sitting with you is, of course, something very special. But that shows a real connection between the management and its employees. You really must be very happy to work in such a company. Great!


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s