I recently asked myself whether our Scrum education system is functioning well. Do we simply tell our trainees what to do in a given situation and then make them look for help the moment the situation changes?
I believe that to succeed at anything personally or professionally, leadership is required. And in most companies, to take the lead you must change the corporate culture, but culture is a tricky and difficult thing to change.
Here is why I recommend using Scrum as one of the simplest frameworks for organizing people and work in any industry, business function, or household.
Knowledge workers, who are hired to think, need spare time and space for thinking, learning, innovating, and creating solutions that meet the needs of all stakeholders. Giving slack is especially important during a transformation to Agile practices.
Em meados de 2009 fui chamado para trabalhar em uma empresa que estava implantando o framework Scrum. Naquela época não tinha a menor ideia do que era desenvolvimento ágil de software e muito menos o que era Scrum. . . .
I have prepared a PowerPoint presentation that introduces Scrum at colleges where I have given lectures on the Agile and Scrum frameworks.
Stories help us understand and remember things. This is a story about a problem we have faced often, especially as a non-Scrum or a non-self-organized Scrum team.
I would like to summarize, in bullet format, many of the do's, don'ts, and best practices learned during my Agile journey.
Scrum is all about visibility. But what do you do when important team tasks fall off the radar? We found a novel approach that worked for us.
Clients can gain a lot from implementing Agile for a fixed-price RFP. But what about vendors or service providers? They can lose money if they continue to accept changes. Thus it's important to have a method for handling fixed-price RFPs.
We can find many examples of information radiators in our Agile environments: Scrum/Kanban boards, burn-down charts, burn-up charts, product backlogs . . . The list goes on and on. There are a few, though, that go unused yet can prove useful.
Sprint Two has come and gone. We're all starting to get the hang of this Agile thing. Even the stakeholder is beginning to show signs of understanding the rules of engagement. . . .
A Scrum team's happiness matters. But with so many personalities on a team, how do you ensure happiness?
Must product owners have technical expertise to do the best job? Here I give you my perspectives on the pros and cons of having technical expertise.
My friend Mr. Snooper is one of the finest software quality assurance (QA) professionals I have ever known. He came to me distressed, however, thinking he was soon going to be jobless. . . .
One of the teams I was brought in to "fix" was suffering from the terrible aftermath of delivering a new software version that completely missed the boat with its customers. What had gone wrong?
This article is based on my observations while working with large U.S. financial organizations in the Midwest. It documents my personal observations on the reluctance of large and complex organizations to take their first step toward Agility.
At a recent conference of ScrumMasters and product owners from various product and services companies, five impediments, or blocks, were mentioned by almost all the teams. Let's look at each of these blocks.
In one of my Scrum coaching environments, two members of a newly formed team were interested in nominating themselves for the ScrumMaster role. They were equal in their eligibility, and both were enthusiastic and growing leaders.
If you've worked with a significant number of teams in an Agile context, chances are you've heard something like this many times: "We could get a lot more work done if we had longer sprints." Here are the reasons why we disagree.