![](\"http:\/\/10kdev.net\/wp-content\/uploads\/2018\/01\/0e3d91b27a02863eb793d81dd8f63d0e.png\")
<\/p>\n<\/p>\n
Nooooo I’m not talking about that QA member who hogs up the standup meetings.\u00a0 I’m talking process.<\/p>\n
<\/p>\n
It came to light on a project I was on that the management team’s fix for bad process was more bad process.<\/p>\n
There were real problems on our project.\u00a0 First, there was a zero window set for testing\/bug fix turnaround before the release of a story.\u00a0 We weren’t allowed to do any target of opportunity refactors without a story\/planning, we had a devops team constantly breaking environments mid sprint, no per-feature deployment environments and a revert-as-process due to this (still changes code!!!) , the *asking* for testing but no time allocated to build out the fixtures or worse,\u00a0 people with no experience making the decision on its direction U(unit, integration, etc.), BA’s running the entire show (conflict of interest), even to the point of specifying technical direction, and the kind daddy of all process failures — crappy requirements.<\/p>\n
An example.\u00a0 I was working on a monstrous feature.\u00a0 The time allocated came in right after the develpoment cutoff time.\u00a0 This was a backend story and had a tandem UI story from another developer.\u00a0 To top it off, the process kept introducing and pealing off people, adding requirements, and server downtimes during the development.\u00a0 At the end we found out that a service dependent wasn’t even scheduled to be released to production, the toggle to turn this feature off didn’t work in the UI BY DESIGN, and the geographical database we were using was still in talks for licensing — none of this we knew, some of it we did but was ignored.\u00a0 Our local dev data wasn’t even close to reality.<\/p>\n
Several other stories were chugging along like this.\u00a0 Of course, the outcome was AC’s were met but the software itself was not adequate.<\/p>\n
A lot of this I attribute to: crappy requirements, no real tech analysis allowed, scheduling a full story to be released that could never meet the deadline, and an integration on top of this (backend and UI, entire feature to production code) with no time to test.\u00a0 Ignoring the outside dependencies was a management gaff; the JIRA story repeatedly mentioned it yet was ignore.<\/p>\n
The response of the team that controls the process, that created this process was MORE PROCESS.<\/p>\n
So you have broken process, and to fix it — have the team that created it to make more broken process to fix the broken process.<\/p>\n
I’m headlining this as Scrum Creep – which is process scope creep.<\/strong><\/p>\n Scrum Creep is when the entire focus to fix things is not to remove blocks (devops issues, bad requirements, increasing testing time, lack of hardware\/tool licenses\/training etc.) and instead continue to do the same thing :\u00a0more<\/em> process, more<\/em> meetings, more<\/em> third-hand training from handed down from alcohol induced Agile Meetup events.\u00a0 More<\/em> documentation to maintain.\u00a0 More<\/em> blaming.\u00a0 More<\/em> heavy handedness.<\/p>\n