There seems to be a problem, mostly with large organizations, getting teams to work together. And when I say teams, I mean a team, not a group of people with the skills that are working in their own silo’s throwing work at one another and tracking it in Jira, Rally, Azure or any other tool.
If organizations are working in the hierarchical order of things with the departments (Engineering, QA, Product, Project etc..,) these silos are systemic. If teams are autonomous and are able to make this decision, why would they choose to work in such a siloed way?
Let me give an example from actual experience.
We have a team, let’s call this team “Silo”. And this team is comprised of people that code, analyze, test, document and deploy software. This team has a workflow that looks like this:
I think most can see where I am going here already, but let’s play this out.
Team “Silo” gets a “requirement” to build a feature.
Now let’s assume the team is quite good at narrowing features and stories into valuable software pieces. That would then end up looking something like this:
I am not going to get into the dysfunction I find in the item hierarchy model during this post, so let’s continue with this example. Now we get to the fun part. The makers start making. In reality with this team, it is each developer grabs their own story and starts working on it and that looks like this:
Mean while, the 1 or 2 members that do manual testing have now begun creating test cases for each story based on the “requirements”. Mind you, nobody is collaborating with one another. They are barely communicating with one another. Anybody who has worked with me or read anything I have posted would also know how much I detest that word “requirements”. At some point, a story gets thrown over the wall to a tester. Boy, I hope they were writing the test cases for the first story that makes it over the wall, and not one of the others.
Lets say the first story that comes over the wall, the tests are ready and waiting for it. People begin testing, and as long as what was built in the story, matches perfectly to the written “requirements”, that story will pass the testing and be thrown over the wall to users or the product owner for acceptance testing and approval.
Now I am obviously over simplifying and focusing on one stories journey through, but for a glimpse, this is closer to what is really happening.
Back to our one story making it’s way to our customer and users. Remember those people, the ones that are hoping to benefit from the sorcery of software development we have trained long and hard in some mythical land to understand and master?
So our story has been coded, tested, it is now being reviewed by our user or customer or product owner if you are using scrum. Let’s again assume it passes. YAY! It is done… or is it?
Well, it may be “Done” but it’s not released. And this might be a pet peeve of mine, but if its not in our users hands, its not done. And then I could even go a step further and say it may never be done, because our user may start to use it and change their minds. “Oh my gawd what a fuckin’ nightmare..” I expect people to use software and probably change their minds about what they like and don’t like and provide feedback about it. Which in turn should prompt us to make changes to the software that makes it easier for people to use it and get a benefit from using. Another crazy thought would be that they like using it. But back to our story here in the process.
Eventually the story is then handed off to operations and they release the story to production.
Now this all might seem very organized, well managed and controlled. It isn’t. There are a lot of moving parts here. And remember our reality image from earlier?
Everyone knows this is wrong. Everyone who has ever experienced it can tell you how stressful and unproductive this scenario is, yet we continue to do this time and again.
What would happen if we realized this was dysfunctional and actively destructive?
Chris Pipito 