The seventh Hands-on Agile webinar Scrum Sprint Anti-Patterns analyzed 12 ways a Scrum team can improve its effectiveness by avoiding typical sprint anti-patterns. Learn more about gold-plating, delivering Y instead of X, absenteeism, side-gigs, and organizing people instead of the flow of work.
The video of the webinar is available now:
The main message of the retrospective was clear: there are too many interruptions by stakeholders and the senior management. The interruptions impeded the flow of work through the team. Consequently, achieving the sprint goal had been at risk several times in the past. Moreover, the team missed the sprint goal twice recently. Solving impediments as a team has become a necessity.
Learn more on how to tackle impediments as a team by running experiments and iterating on the solution.
The Scrum Master profession spans a wide variety of skills, knowledge, and experience. Scrum Masters try to create high performing teams and drive organizational change. Although our primary focus and responsibility is the process, it’s people we work with all the time. Surprisingly, our profession focuses predominantly on developing cognitive intelligence (IQ). We need to learn to appreciate the value of emotional intelligence (EQ) in becoming great Scrum Masters.
The term emotional intelligence was first created by researchers Peter Salavoy and John Mayer, and popularized by author Daniel Goleman. Emotional intelligence has been defined as, "the ability to recognize, understand, and manage our own emotions, and recognize, understand, and influence the emotions of others."
Recently I was teaching an overview class for new Scrum Masters. I was covering the five important events (meetings) in Scrum and had just introduced the Daily Standup Meeting (DSM), when a learner interrupted with the following question: “Given the cost to people’s work time and the cost to the corporation, do Scrum teams generally feel there is value in the Daily Standup Meeting?” He followed with, “How do you feel about the Daily Standup Meeting?”
A study was conducted at the University of Oslo Norway (V. Stray et al, 1997) to answer the first question. The method of study was a survey of professional software developers. Those conducting the survey received 221 responses from professionals who identified either as a general computer programmer or a web developer. Participation was voluntary, no compensation was given, and controls were placed to prevent the same respondent from answering more than once.
This is the fifth in a series of posts exploring Scrum Mastery. In our first post, we introduced the 4 dimensions of Scrum Mastery: Team Identity, Team Process, Product Value, and the Organization. In this post, we will explore the Organization dimension.
How is the organization enabling you to maximize the benefits of Scrum? How is the organization holding you back?
"I travel around the world constantly promoting my projects and endorsing products." — Paris Hilton
Agile coaching is a journey into irony. One of the chief discoveries you can make on this voyage is that the more experienced you become, the worse at the job others often think you get.
Finally! With the "embargo" lifted by Scrum.org, we can now share with you the incredible journey that Barry Overeem and I have been on for the past months.
The bottom-line is that Scrum.org has acquired our "Scrum Master Advanced" class. We’ve been spending the past eight months turning it into the official, brand new Professional Scrum Master II class (PSM-II) for Scrum.org. As newly-minted course stewards, we are now responsible (with Stephanie Ockerman and Simon Reindl) for the entire Professional Scrum Master curriculum (both PSM-I and PSM-II). If you’d like to know more about the class and how we designed it, click here for a detailed write-up.
This is the fifth and last post of my blog post series about the five phases of a Scrum Retrospective. In this post, I cover Phase 5 – Close the Retrospective.
If you haven’t read the previous posts in this series you can start with Phase 1 – Setting the stage.
Don’t say this too loudly around agile conferences, but when it comes to the day-to-day work, Scrum and Kanban are basically the same.
Now, as an attendee of these conferences and an enthusiastic participant in discussions on pull systems; time boxes; empirical process control; and Little’s Law, I admit that it’s satisfying to go deep into these issues. However, it’s important not to lose focus on your team, your customers, and your product. Whether you’re doing Scrum or Kanban, the day-to-day work is about a team of skilled and experienced professionals collaborating, solving problems, and trying to make a positive impact. Sometimes this goes well – people succeed in creating great things together; sometimes it doesn’t – bad products are built by a disinterested team, producing poor results.
One of the most common critiques about Scrum that I’ve heard from smart software engineers is that "Scrum does not care about technical practices. Scrum is for wimps." I’ve also heard managers down the hallway say that "Scrum is for wreckless developers because its main concern is only about fast delivery." I’ve heard many business analysts and solution architects tell me that "Scrum is too fragile because it does not specify the documentation the team needs to write."
People often say these things because they could not find in the Scrum Guide that says what technical practices the Scrum team need to do. But just because the Scrum Guide does not explicitly mention any technical practices you need to do, it doesn’t mean you couldn’t or shouldn’t do any technical practices. In fact, professional Scrum teams will find that technical practices are required for the software to be sustained in the long run. This is what agility is all about, not just about being fast in the beginning but slow at the end because of technical debts.
