content top
Index of all posts

Live Online Courses will be Free

Live Online Courses will be Free

At Scrum Inc. we've been broadcasting live online courses every month for over two years. In fact this week's course on Retrospectives was our 29th. Until now, we've been charging $50/course. While we've experimented a few times with broadcasting the live event for free, it's never been our policy. However, starting with next month's webinar on Getting Done, we will offer the live broadcast for free forever.

If you want access to the recording and slides, those can be found on ScrumLab Prime. Prime is a $50/month offering but allows access to all Scrum Inc. content. This includes all previous and future online courses as well as a vast array of multi-media content that covers advanced patterns and topics.

Checkout ScrumLab Prime for free as well. Simply use the coupon: FREE MONTH.

Read More

Scrum Inc. Heads Back to the Valley

Scrum Inc. Heads Back to the Valley

This past fall I visited some of the biggest tech players in Silicon Valley (PayPal, Twitter, Salesforce, Wallmart.com etc.) There were two take-a-ways from those visits. First, people, mostly leadership, wanted to know how to scale their Scrum implementations; and second, teams weren’t getting testing done inside the Sprint.

I’m heading back to the Valley in mid February to teach both a public CSM and CSPO course as well as a one day Scaling workshop and I plan to address these two issues head on.

Read More

Scrum at Scale: Changing the Conversation

Scrum at Scale: Changing the Conversation

Part of the key to Scrum's success is that it allows for context-driven solutions and processes – which is why no two Scrum implementations are identical. So why does the conversation about scaling Scrum focus on finding a proscriptive, one-size fits all solution? The conversation should instead be about how to scale the underlying principles of the Scrum framework that have enabled it to be so adaptable.

The Scrum at Scale framework is our first move in that direction. It is a minimal extension of the core Scrum framework that keeps the modular structure at the core of the Scrum framework, and allows you to scale a Scrum implementation tailored to the unique needs of your company.

Read More

Getting to Done

Getting to Done

My book Scrum: The Art of Doing Twice the Work in Half the Time was published in October. Over the last six weeks, I’ve been touring the U.S. and Europe telling the story of all the influences that culminated in the creation of the first Scrum team over 20 years ago. No matter where I go, people ask me what the secret is to running a good Scrum. The secret sauce of running a great Scrum Team is Getting to Done!

Bad Agile

There is a lot of “bad agile” out there. According to Jim Johnson at the Standish group, 49 percent of Agile projects fail. Why? Because people don’t grasp the essence of what it means to be Agile. It requires a fundamental shift in thinking. The second value of the Agile Manifesto is quite clear: Working software over comprehensive documentation. That means that at the end of every Sprint you have potentially shippable increments that work!

Working software is key because it is the catalyst for one of the most important aspects of the Scrum Framework: feedback. If you don’t have working software at the end of the sprint, stakeholders can’t use it during the Sprint Review and, as a result, can’t give the Product Owner and team the feedback that will allow the team to develop the product into the customer’s sweet spot.

The secret to working software is complete testing inside the Sprint. If your testing practices aren’t tip-top, your teams are probably struggling, your customers are probably frustrated, and you most likely don’t know when the product will ship.

Five causes of team failures

  1. Poor definition of DONE
  2. Stories not READY
  3. Dysfunctional Leadership,
  4. Technical Debt
  5. Ineffective coaching
  • A rigorous definition of Done includes working tested product at the end of the Sprint. Teams must work together to refine their definitions of Done. Product Owners have to stop accepting Stories that don’t meet these criteria.
  • Good definitions of Ready and Done are two levers that produce successful Sprints. Stories don’t magically become Ready, they need to be clarified and granulated. Acceptance tests need to be embedded. This takes time and attention from the Team.
  • A leadership team that sees the benefits of going Agile, but hasn’t engaged enough to shift its mindset is a recipe for disaster. Scrum works because it allows capable workers to self-organize and determine how best to accomplish their goals. If management maintains a command-and-control mindset, a Scrum implementation will fail. In an Agile context, managers become Leaders. They are tasked with setting transcendent goals for the organization, supporting the Teams and removing organizational impediments. They need to determine what Scrum metrics would best bring transparency to the processes so they can hold the Product Owners responsible for value delivery and Scrum Masters responsible for velocity.
  • Technical Debt needs to be stopped in its tracks. The discipline of having clean code every day is essential as is completing all testing within the Sprint. Then the historic technical debt can be reduced piece by piece
  • When implementing an organizational change, companies are pretty good about educating their employees but they fail to provide them with support they need to succeed. The most successful implementations not only get their workers certified but also bring in outside help to launch the teams. A team launch includes an expert coach who helps develop the first iteration of the Product Backlog, helps the teams define what it means for a story to be both ready and done, and leads them through all the Scrum ceremonies at least once. Ideally, the coach returns periodically to fine-tune the teams’ work and take them to the next level.

Systematically focusing on remediating these issues will consistently produce high performing teams with 200-400% improvement in production.

Failure to focus on them will add yet another team to the 49% of teams that are “Bad Agile” leading to unhappy customers, lost revenue, and lower stock prices.

-- Jeff Sutherland

 

 

Read More
content top