How are you managing your testing, is it really agile?
I’m going to assess this one by looking at the way we work through the lens of the twelve principles of the agile manifesto.
Principle One: Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
Is ‘customer satisfaction’ our highest priority? Yep, I reckon. Almost always.
Principle Two: Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.
Yes, we do this. “Welcome” is an interesting word, because sometimes, changing requirements are really frustrating! But, we take them on head first.
Principle Three: Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
Heck yes. We deliver working software multiple times daily. It's one of the things I love most about my job right now.
Principle Four: Business people and developers must work together daily throughout the project.
Yup, we’re doing good here too. There’s possibly room for improvement - daily might be a slight exaggeration, but it would be multiple times per week at least.
Principle Five: Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
Nine times out of ten, we do great here.
What's hard for me to admit is, this is one that really needs to be ten out of ten. If one of those elements is eroded for an individual, the effects can be dire and long lasting.
Principle Six: The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
Almost always, except for when it is impossible - some of our developers are in different countries, so a Skype or Hangout has to suffice!
Principle Seven: Working software is the primary measure of progress.
I think so? Working software is definitely one of our measures of progress, at the very least.
Principle Eight: Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
Almost always. I can think of one incident only where this hasn’t been the case, but for the most part, we’re really good at managing timing of our projects.
Principle Nine: Continuous attention to technical excellence and good design enhances agility.
Yup, we do great here. My experience on day nine, pairing up for a code review, really cemented this for me.
Principle Ten: Simplicity--the art of maximizing the amount of work not done--is essential.
That’s an interesting one. Simplicity is one of our core values, so clearly it’s something we care about greatly.
I’ve never heard it expressed in terms of “maximising the amount of work not done” though. That's something worth thinking about.
Principle Eleven: The best architectures, requirements, and designs emerge from self-organizing teams.
We don’t do this. Our teams are organised by someone else. I don't mind, because my team is the best.
Principle Twelve: At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behaviour accordingly.
Hmm - we do this, but there isn’t really any regularity to it.
My hope is we would express our reflections as and when they occur rather than waiting for, say, a retrospective to make that happen.
Are we really agile?
Yup! Pretty clearly we’re in line with *most* of the Agile principles. There’s room to improve, for sure, but I like where we’re at!