Ok, this is gonna be a bit of a rant.
I am constantly amazed at some of the pain and strange reasoning that is presented when making mere suggestions about changes to the way we work together in large organizations.
When faced with many issues that bog down teams and organizations, some of the most painful I have experienced are not that uncommon, especially when working with large organizations.
- Departmental Bureaucracy
- Silo Driven Work
- Large Up-Front Requirements
- More Faster Mentality
- Fire & Forget
- CAB Approvals for Releases
- Etc..,
But the biggest pain I feel in these organizations is the lack of willingness to try new things and learn from it. I am constantly facing people that will complain about the situation or way they are working, but won’t entertain a possible solution someone has or dare to come up with a possible solution on their own. The world might end if that happened.
A quick example is the mere suggestion of dedicated teams. That was met with outright hostility recently based on the reasoning that “we are a cross-functional QA department, and we don’t want knowledge loss if someone leaves.” Well, one, don’t treat people like machines and make them want to leave, and two, stop using outdated processes for testing software because you don’t think automation is worth the investment and manual testing is the way to go.
Now this example is absolutely driving me insane. We have a team that is about as dedicated as it gets right now. And some of the pain this team experiences is as follows:
- BA’s gather requirements
- DEV build requirements
- QA tests requirements
- Users test the same way QA tests in UAT
- Code is submitted for 3 layers of approvals in a CAB meeting
- Code is released relatively easy since its AWS terraform. In comparison to some other products, it is extremely easy and very fast.
So a suggestion was made.
Why don’t we get everyone in the room, discuss this story and its possible functionality and solution, start building and testing it together, reaching out to our business users for questions and feedback since we can’t get them in the room with us all day, and work this story to completion?
And to add some more context, the suggestion was even made that since people are new to true CI/CD and haven’t experienced it before, that we even create an extremely tiny story, really not even a real story at all, like a CSS change to a button, just to walk through an example of what working like this could look like and learn about the release process. Identify pain points in the release process wherever they are. Of course we could grab a small story and dig in, but when ultimately we are trying to share knowledge and learn about this new way of releasing software, why not make the story or task as simple as possible at first, and put all the focus on that release process. At least it sounded like logical thinking to me… I could be wrong, wouldn’t be the first time, won’t be the last time either.
From some people, you would have thought I made a derogatory comment about their mother. But I have to say the biggest pushback came from the QA department. They have a process to create test cases, run through test cases, and approve functionality. We had a long conversation on why that process is the way it is and how we might be able to make it less painful for people. Especially when this team is working with stories that are as small as they are? There are a myriad of reasons that were given why we can’t possibly change that process, but the one that pained me the most was, “What will the leaders of people do? They don’t want to test tiny stories all day. They might leave since there is no career path.”
I find this disturbing on many levels, but the obvious issue here is the organizational bureaucracy supporting the silos. The organization, in my opinion, should be actively seeking to be a learning organization. Treating people like people, and rewarding people for wanting to solve problems. Creating and supporting a culture that welcomes change and embraces different solutions. A psychologically safe place for people to voice opinions and try new things. I have not heard of mass exoduses from organizations that have these cultures. That really empower the people that work there. Am I wrong about this?
Now I don’t force a way of working on anyone. I make some suggestions, I offer up how we might go about that learning experiment, and leave it up to the team to see if we all want to try it to solve some specific issue or impediment we are facing in the way that was suggested or if there may be another option.
My personal favorite approach at this point is to simply ask what options or changes we could try that could solve something. What is our ideal way of working, and how do we get there?
In the essence of keeping this short, and since it was a rant after all, I want to invite people to offer up any experiences they have had with this and what you have done to work through these types of issues.
Chris Pipito 