If you’re unfamiliar with the phenomenon, we’re in the middle of conference season right now in the US. Quite a few software and testing centric conferences are scheduled every year in late spring and early summer and then fall. Two times a year, I’m on the road for 4-6 weeks attending and sharing at wide variety of conferences.
It’s something that I enjoy doing although the travel can be quite tiring. One of the great things about it is that it provides me with new ideas. And if you know me, many of those ideas end up in my writing.
Here are a few…
One Story: Leadership, Run Amuck
A young woman came up to me yesterday after a delivered an agile workshop at a testing conference. She had a question for me.
She described the following situation at her company:
- The organization had already started to “go Agile”, but…
- The teams were being driven by fixed scope, fixed date projects by their leaders
- The teams had no say in committing to the projects, instead leaders made all of the “feasibility” decisions for the teams;
- The teams had been working 70 hour weeks for 6 months straight, no weekends off, and would continue to do so into the foreseeable future
Now her leadership team was pushing for their teams to “get more Agile”. So after all of that context, what was her question?
She asked: How will agile help with this situation?
My answer? It won’t.
In fact, I think adopting agile approaches will actually exacerbate the situation because I suspect your leaders will always want more. It sounded to me as if the teams were trying to be agile, but the leadership team was viewing it as a simple speed increase play WITHOUT engaging the agile transformation themselves.
For example, pushing the team for more is a simple management play. It’s short-term and naïve. It might create more “stuff”, but the quality will be suspect. And the reliability of the date commitments will be suspect. And finally, they are risking losing their greatest asset – their people.
While they certainly have the right to operate this way, I view it as imbalanced, immature, and certainly not aligned with agile values.
The young lady sort of expected this answer, but she was still disappointed and sad to hear me say it…
Here’s a link to a blog post that speaks to capacity management within agile organizations and teams.
Another story: Ah, the pain of ScrummerFall
I ran into someone else at another conference. They described a situation in their company that I encounter all of the time. Among other names, it’s often called ScrummerFall.
Here’s how he described the situation:
- Our development team seems to be doing a great job. They work hard and deliver user stories “on schedule” to QA;
- The problem seems to be within QA;
- They don’t seem to be able to “keep up”. I suspect they have skill problems. I also suspect that they might be “over testing”.
So my mental picture is – waterfall behavior working within a Scrum wrapper, which is ScrummerFall.
In other words, there are still “silos” within the Scrum team. In fact, they’re probably not behaving or acting like a team at all.
The key for me was when he said the following: The testers clearly can’t “keep up"!
Some of the actions he proposed to “fix” the problem included the following:
- Putting some of the testers on performance improvement plans;
- Asking them to work more harder, more hours;
- The developers should be telling them what to test and what not to test;
- Start investing heavily in automation – to remove the “dependency” on the testers.
I have to say that I had an incredibly hard time keeping my jaw from hitting the floor as he went through his corrective action list.
I pointed out, just once because I didn’t want to get into a heated debate that the problem might not be solely with the testers. I told him that testing was more of a whole-team responsibility within agile teams. So to place all of the blame on the testers was akin to placing all of the blame on the developers for producing too many bugs in the code or for writing too many stories and getting too far ahead of the testers.
But he had clearly made up his mind on the problem and corrective actions. Too bad really…because he was wrong!
Here’s a link to an article where I explore ScrummerFall and how to avoid it in much more detail.
Another story: The State of Agile QA “Integration” in 2015
This is probably the saddest of my stories, given my ongoing goal of trying to bring a sense of maturity, integration, and health to QA and Testing within agile contexts. It’s been an ongoing goal of mine, and one of the primary reasons Mary and I wrote The Three Pillars of Agile Quality & Testing book.
When I was at the STPCon conference I polled attendees of my sessions. The most compelling question related to ScrummerFall and whether testers felt like they were included as part of their agile teams. In other words, did the team work on things collaboratively or did they handle things the way they always had with hand-offs, phases, email conversations, etc.
In the keynote, the rough number seemed to be about 90% of the audience (there were ~ 250 folks in attendance) replying that they were doing fairly “bad Agile”. So the good news was that agile approaches are becoming quite pervasive. But the bad news is that we’re not really working in the spirit of the Agile Manifesto and the collaborative principles behind it.
Josh Anderson did a similar poll at his sessions at a Mobile Development & Testing conference about 2 weeks later. His results were about 75% of his audiences. So a slightly better result, but still quite disappointing.
I guess the key message is that “bad Agile” is still incredibly alive and well in the real world. Please grab a copy of my 3-Pillars book and look for some strategies to help reduce these percentages. Remember, the goal is not collaboration. The goal is results, which effective teamwork and collaboration will deliver.
Agile Managers – STOP Estimating & Committing FOR Your teams
I encountered software manager at an agile group meeting who was complaining about their sprint planning. He alluded to the team being disinterested and non-committal in the planning.
I started asking him about the dynamics of their planning. I also asked about their backlog refinement meetings and how stories were being matured for sprint execution.
For about 15 minutes I felt that something was unsaid and I just couldn’t put my finger on it. Every response he gave seemed to be generally a good one and implied they were trying to be a mature team.
But finally it came out…
The team wasn’t grooming at all. The manager and a team lead were grooming the stories “for” the team and delivering them to sprint planning. That was the first time that the team was seeing the stories.
So of course sprint planning was difficult and commitment was lacking. I’d lack commitment too if someone had the audacity to tell me how to do something and how long it should take BUT expected me to commit to the work.
What did I say to him you might ask? Basically that he was getting exactly what he should. If he wanted commitment, he needed to stop estimating for the team.
Wrapping Up
I hope you enjoyed my conference stories. I know they’re all of the “challenging” variety. I need to say that the conferences themselves were outstanding events. And I believe the attendees were engaged in active learning and enthusiastic.
There are quite a lot of good people engaged in transforming their software development approaches to be more agile. It just seems that many of them are getting in their own way of success.
My hope is that my blogs occasionally break through and help folks to improve more quickly than they would on their own.
Stay agile my friends!
Bob.