People often conflate Scrum with Agile. But Scrum is not the same as Agile. Agile is considered by many to be a set of values, principles and way of being. Scrum is a framework consisting of roles, rules, artifacts and events. It is designed for teams to add those practices needed in order to become Agile.
XP is quite different. Continue reading “The biggest difference between Scrum, XP and Kanban”
Planning events should be more about collaboration & dependency management than just creating a plan. Teams commit to the plan with the understanding that any teams they are dependent upon will work with them as needed.
During the event this requires both teams to agree to the date a dependency will be built. This is supposed to happen before the stickies & yarn go on the board. But it sometimes doesn’t happen. This must be tracked. This is done easily enough by putting red dots on both stickies involved. This does not always draw these uncommitted to dependencies to enough attention.
Continue reading “Big Room Planning Event tip: Make sure commitments are made for all dependencies”
I founded Net Objectives almost 20 yrs ago. I have always loved solving problems and having a chance to earn a living by helping others solve problems has been a very wonderful opportunity for me. Continue reading “A personal goal of almost two decades is manifested today”
I founded Net Objectives almost 20 yrs ago. I have always loved solving problems and having a chance to earn a living by helping others solve problems has been a very wonderful opportunity for me.
I have long thought that training methods have had to change significantly to keep up with the growing demand. It has in some ways – simulations, games, group exercises, etc. But basically, training is how it has always been. Especially in the area of growing Scrum Masters or Agile Team Coaches. In particular provide 2-4 days of coaching and then either let them go on their own or pay a lot of money for a coach. Continue reading “A personal goal of almost two decades manifested today”
One of the central tenets of Lean is that the system people are in impacts them significantly. This does not mean, however, that one can just create a new system and put people in it – this would be a perversion of Lean-Thinking. Lean suggests systems support our people. But this presumes they are capable of getting their work done. Putting people into a potentially Agile system does not teach someone actual Agile skills.
Continue reading “Lean Thinking on frameworks vs. the work in them”
If you are kicking off new teams there are two types of coaches you can bring in. While it’s useful to bring in someone who can actually help with the work, such as a technical or ATDD coach, when it comes to Scrum or Agile coaches it’s usually better to grow your own. There are several reasons for this:
Continue reading “Why you should grow your own Scrum Masters instead of bringing in outside coaches”
Which initial training you chose should therefore be that teams can do this after their initial training. The promoted belief that you should focus on the framework & then learn how to do this later is not just self-serving, it is wrong. While you can take a course and then pay for coaching after the workshop to learn this is not just expensive but wastes the time of your staff and often produces resistance. Continue reading “The #1 challenge for teams after Scrum training is writing small, well-scoped, testable stories”
The Scrum Guide is the de facto standard for how to do Scrum for Scrum.inc.org.alliance. But at Net Objectives we believe you can and should go beyond it – pragmatism over dogmatism – work over framework.
There is, of course, a reason that the Scrum guide says “Scrum’s roles, events, artifacts, and rules are immutable.” And, if you are starting Scrum out on your own and you have control over your team that’s likely a good thing. But when Scrum doesn’t exactly fit, relaxing the rigor in the right way can make Scrum more effective. Continue reading “Why you should go beyond the Scrum Guide with Scrum”
Do you have devs who resist Scrum or don’t want to take the time to write better code? I can attest that with very few exceptions devs want to do the right thing in the right way. So why does it show up differently?
Several answers: Continue reading “Attend to what’s in it for them”
Scrum’s roles, events, artifacts and rules are immutable. Ironically, immutability is as non-Agile as one can be – so why is this? When difficulties arise in how work is being done a question must be asked – “are we doing the right thing poorly or just doing the wrong thing? Scrum pre-defines the “right” thing & says keep working on until you do it correctly. But what if these are not ideal for your situation? What do you do then? Continue reading “Scrum FLEXed”