OMS Consulting Partners, LLC

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...

Today's posting is from guest blogger Dan Greenberg... I just came from a daily scrum where a team complained about having to create a PowerPoint deck for an upcoming demo to a group that would not include stakeholders. When I asked who the right people to be in the room for a demo would be, they listed two stakeholders whose feedback they really wanted to get. My suggestion: transparency! Write a user story for the creation of the PowerPoint slides required for the “required” demo and include this work in the team’s capacity, potentially knocking other valuable work into a future sprint. Hold a true demo to get the valuable feedback from the real stakeholders in addition to the “required” one. Go to the manager requiring the demo and show them the valuable work that had to be delayed because of the effort to create the PowerPoint deck. Show the two calendar events and be up front about the double booking of the team’s time to hold two demos rather than one. Stress ...

Daniel Pink (renown author of "Drive" - and the surprising truth about what motivates us  https://www.youtube.com/watch?v=u6XAPnuFjJc  where we learned that throwing money at people doesn't help, autonomy, mastery and purpose do)... He has recently shifted his focus to the importance of timing, including a book called "When".  An interesting data/fact/research driven conclusion is that people are highly effected by temporal events like in 'mid life crisis' or running more marathons at 29, 39 or 49 years old are motivated by midpoints and endpoints. Having short sprints in Scrum (say 2 weeks) forces people to focus and prioritize on delivery, not on some unattainable long term obscure vision, but a concrete step in the right direction of accomplishing that vision. Scrum, once again, leverages human strength and has 'built in' to the system behavior that leverages human strength, not human weakness.  The more research emerges about how h...

Harvard Business Review in its article "An Exercise to Help Your Team Feel More Comfortable with Conflict" , discussed the idea of "conflict debt" and how it can harm your team or organization... Rather than working through the conflicts that will help our organizations move forward, we duck, dodge, and defer them.  The result is that most of us find our teams up to our eyeballs in conflict debt .  Conflict debt is the sum of all undiscussed and unresolved issues that stand in the way of progress. Conflict debt can be as minor as withholding the constructive feedback that would allow your colleague to do a better job and as profound as continually deferring the strategic decision about when to scale your new product line. Paying down the conflict debt on your team is critical, but it won’t be easy.  The problem is that your team likely lacks both the skills and the mindset to use conflict productively.  One reason for that is that we’re biol...