OMS Consulting Partners, LLC

Thank you Joshua! https://www.linkedin.com/feed/update/urn:li:activity:6553338155314094080

Guest post from Dan Greenberg “We need to define success.” Have you heard that one? It happens all the time at bureaucratic corporate organizations who love creating measuring sticks to help them figure out whether everything is okay or not. Before beginning anything, corporate junkies always insist we define what a successful outcome will look like. I take issue with this. First off, life is far more complex than a black-and-white this worked or it didn’t outcome. I propose something else entirely: Start doing some project At regular intervals, get everyone involved with the project (working on it, has some interest in it being successful, cares about it, etc.) into a room together and ask them all “is this project going well?” or “could anything be improved?” (This group of people includes all customers by the way.) For those who think it’s not going well or that it could be improved, ask them what they think is going wrong or what they think could be impr...

Thanks Jesse Fewell!

As recommended by Jeff Sutherland - another way to avoid formal waterfall requirements... https://pages.services/ss.ivarjacobson.com/use-case-2/

Thank you Dan Greenberg for another great guest post! A fantastic 2016 post from Agilist Jasmine Adamson . Sourced from  this Quora story   (and to find the original comment, you'll have to scroll about 3/4 of the way down the page) Full text reprinted here: Agile is bullshit, that's why.  OK let me qualify... The Agile Philosphy is perfectly fine, and it addresses the physical and psychological aspects of managing software development teams quite well. The bullshit comes in when a team or company makes the statement that "we are doing Agile" because they aren't. So, to clarify, Agile itself is a good idea, but when someone says they are "doing Agile" that statement is bullshit. Always. Programmers like things well-defined. When you tell me we're going to "do The Agile Process" (it's not a process), I expect an organization that follows these principles:  Principles behind the Agile Manifesto Those principles are well defined...

Contribution by Dan Greenberg Material Taken From… https://www.knowledgehut.com/blog/agile/5-hurdles-that-scrum-masters-commonly-face Managing Role Expectations The Scrum Master role can be confused with a Project Manager but in reality the two are not related at all. A Scrum Master is a facilitator and a servant leader, whose role on the team is to champion continuous improvement and protect the team from distraction so it can focus on the work. A Scrum Master is NOT a reporter of status, a manager, nor a producer of metrics. Resistance to Change Many teams develop transformation fatigue. We’ve been working together for 20 years and every few months some new corporate initiative comes down but because nothing ever really changes, it becomes like the boy who cried wolf. Now Agile is the hot new flavor of the month, but I’ve been through dozens of flavors of the month over the years and if you just wait it out, pretty soon it will be gone and a new one will take its p...

Guest contributor: Scrum Master Dan-o I’m working with a team now where code commits literally take years to get to production. Why such a long delay? Months and months of repetitive testing and security checks by numerous teams, departments, outside organizations, ad nauseam - essentially years’ worth of bureaucratic red tape. I’m not of the opinion that bureaucracy is inherently evil but I do think it is a misguided attempt to solve a legitimate problem. In actuality, I think it winds up being a self-fulfilling prophecy guaranteed to justify its own existence. Typically, what I’ve seen happen is you have a team deploy say, 100 features to production and one of them has a defect. Rather than do a root cause analysis, management wants assurance that no defect ever makes it to production again so they force EVERY feature to go through an intense series of gates. Developers then, knowing that the robust system of checks will catch any defect (and often getting pressured by manageme...