Tips, Expertise, Articles and Advice from the Pro's for Your Website or Blog to Succeed
I've been thinking about the people who complain about being forced to do Scrum.
I agree that forcing self-organizing teams to do something seems counterproductive; however, even in that scenario, there are only a few hard and fast Scrum rules. Anything else I'm being made to do is not Scrum's fault:
The world is changing more rapidly than ever, bringing with it more unknowns than known. And without strong leaders to guide our teams through this time of complexity and uncertainty, we won't fare very well at all.
But I can let you all in on a little secret: The key to enduring success in leadership is the ability to stay nimble and to "Leadershift," as John C. Maxwell explains in his book by the same name.
This is a blog about leadership: leadership in Scrum teams, communities, and business. It is also a blog about personal growth and offers a complimentary “action approach” to Scrum Masters, inspired by the book The Serving Leader.
The book covers five principles you need to know to implement servant leadership in your Scrum team and your organization.
Agile Scrum is misunderstood by a large segment of practitioners. Scrum deliberately didn't spell out most of the actions required and that frankly has created quite a pandemonium.
This unclarity of action has created ‘theorists,' who run around with stopwatch in hand, staunchly advocating for so-called ‘assumed’ rules.
In my view, though, Scrum needs to be approached with common sense. A high discipline from the team is unquestionably a mandate. But having said that, exceptions and irregularities are expected when you deal with human beings.
As a Scrum Master, I know that encouraging the development team, product owner, and organization in the adoption of Scrum is anything but not easy. It takes time (a lot of it) and patience.
And during that long journey, it's vitally important that the Scrum Master never stops improving. In fact, it's this commitment to continuous learning that helps me perform my responsibilities and enables my team to maximize the values of Scrum.
In simple terms, a product backlog is a list of everything that needs to be done in relation to the product. This is the key artifact that helps in translating the high-level product vision and serves as the foundation to initiate the development of the product.
The product backlog includes features to be built, enhancements, fixes, quality attributes, etc. in the form of user stories.
This is beneficial in comparison to the waterfall approach of creating multiple pages of requirement documents because it provides prioritization so that the team has a direction, has the necessary details required by the team, and it keeps evolving and responds to change.
We've all seen it: The Scrum Team goes through the motions, implements all the mechanics of Scrum, and still when we look at what's going on, it doesn't feel right.
Steve Porter fondly named it Believably Bad Scrum. I call it Scrum Theater. Barry and Christian call it Zombie Scrum.
"I can tell how much this story means to you. It makes me wish I could've experienced that with a Development Team."
This is what another Scrum Master told me after we took turns during a recent training to share a success story about a Development Team. I've heard this many times before.
What does this say about Development Teams out there? Why is there such a strong emphasis on the people needed for the process and so little on the people doing the work?
Scrum Masters are often understood mostly as "team coaches," Yet, their role is vastly more important. The Scrum Guide emphasizes that Scrum Masters are responsible for leading and coaching organizations in the adoption of Scrum and causing change that increases the productivity of the Scrum Team.
And this makes sense; Scrum Masters are in a perfect position to see how missing skills, red tape, external dependencies, and other organizational impediments impact the ability of Scrum Teams to deliver working software every Sprint. Like car mechanics who try to fix cars by only looking at the tires while ignoring the broken engine, Scrum Masters who only focus on the team will miss the bigger, more important changes.
Documentation in an Agile environment is an interesting topic. The Agile Manifesto places more value on working software than on comprehensive documentation, and one of the Agile principles states, “Simplicity–the art of maximizing the amount of work not done–is essential." But does this mean we shouldn’t write documentation when we use an Agile framework? Not at all. I use these three key practices to create effective Agile documentation.
First, minimize documentation to just what’s needed to get the job done. While software solutions must be maintained and need supporting documentation (either as commented code or external documentation), there is a tendency to create documents simply because “we’ve always written them," whether they are ever read or not. Creating unneeded documents expends valuable time and is counter to delivering the highest value first. Documentation effort should be treated like a requirement if it’s not part of your Definition of Done; it should be estimated and prioritized along with other work. This means weighing the cost of documentation against the anticipated benefit.
As an Agile Coach, it’s exciting to watch a team of young agilists start their Agile journey. Some start with unbridled enthusiasm, others with fear and trepidation. They then crawl from Agile infants to toddlers learning how to communicate and play well with others, then move into Agile childhood where they begin to develop competencies and enjoy success. And then… [long pause] …they become Agile teenagers – yikes!
Don’t get me wrong – I’ve raised one teenager and have another now, and I love them even during their teenage years. There are great times at that age, and there are, well, less than great times too. Those growing in their agility go through stages similar to what my kids did. Some move through the teenage years with grace and style, some with a rebellious attitude, and unfortunately some stay in Agile adolescence way longer than they should. Being an Agile teenager is normal for a while, but just as we don’t want our children living in our basement, playing video games and eating Cheetos well into their 30’s, at some point every Agile teenager needs to grow into adulthood.
Looking back, a couple of years ago I had a chance to work with the great team. Yes! They are a great team, but not from the beginning...that was a broken team when I came on.
In a tough time, I planned to do many things to support the team, but first I asked them: "As a Team, do you trust each other?"
Through my professional experience, while serving my customers, working with Scrum Teams and training people in Professional Scrum, I have observed that some Scrum Masters only work to serve the Development Team and the Product Owner.
According to the Scrum Guide, Scrum Master serves on three levels:
Generally, the majority of Scrum software development projects are completed successfully. However, there are situations where Scrum does not deliver the expected results. This article discusses why Scrum fails in software development and the possible reasons for it. This article is targeted toward those who have a good understanding and some experience on the Scrum framework.
It is very important to have a good understanding of the Agile Scrum principles, strategies, and approaches. It is equally important that all team members have a common understanding of the Scrum framework, as well as the Scrum roles in the team. The team should know the distinct roles and responsibilities that the Product Owner, Scrum Master, and developers should play.
Back in 2017, we started the Scrum Master Salary Report 2017—the first industry report that covered in depth the educational background, working experience, industries, and organizational details of the companies Scrum Masters or Agile coaches work for. For the Scrum Master Trends Report 2019, we partnered with Scrum.org, the leading Scrum training and certification institution founded by Scrum co-founder Ken Schwaber—to improve the underlying data set.
Learn more about the state of the industry and download for free the Scrum Master Trends Report 2019.
For my career, I have had the great privilege to witness different companies undergo many different phases of Agile transformations. I've met many amazing Scrum Masters along the way that have evolved to take on major responsibilities in their organizations. However, I have also seen many Scrum Masters who fall into common traps that impede the Scrum team, impede delivery, and inadvertently slow down their own career growth by falling into five common traps that I have identified. I'll identify these common mistakes and offer ways to best avoid them or get out of an invisible sinking tar pit that frequently pulls new Scrum Masters into their demise and show you how to get back on the path towards becoming a great Scrum Master.
Are you always the one doing the typing in every Scrum event? Being a Scrum Master doesn't make you the team secretary. Anyone who can type can take the keyboard or laptop and write user stories, take notes, update hours and change Outlook appointments. If you want a self-organizing and empowered development team, you cannot do everything for them, including taking notes. I often get asked if a Scrum Master is a full-time role because all they have seen are Scrum Masters that run all the meetings and take all the notes. If that's all you do, it's understandable why one would see it as a part-time job.
We often talk about Agile and its benefits in an organization. Everybody knows that using Agile will bring a lot of long-term benefits which can be related to profit, better team, better quality of software, and lot more. Do we ever wonder, though, what the success rate of Agile projects is, and why Agile projects fail?
Agile cannot be implemented without the support of management. Let’s discuss two different organizational scenarios for management support in detail:
"I see a lot of nuances in how people interpret Scrum."
Today I’m going to talk about my interpretation of Scrum and the roles, events, artifacts, and rules that sit within it. I have worked with many different Scrum Teams from all kinds of different companies, so my interpretation is based on credible, practical experience.
A lot of people see the Scrum Master as a servant-leader, one who coaches the Scrum Team. This is wrong. The Scrum Master is really a project manager. They help the Scrum Team create high-value products, so they should lead the team by controlling the User Story Requirements List and assigning work to the developers and even the QAs. As leader, or manager, the Scrum Master has the final say on the order of the Product Backlog.