» Scrum Framework
One of the most common conversations I’ve had with clients over the last few years is how to move from waterfall development to using the Scrum Framework. Based on those discussions and years of experience leading and supporting these transformations for my clients, I’ve compiled this short guide on planning and executing an agile pilot or an agile transformation in your organization.
In my previous post, I described some Agile coaching I was doing with a large, conservative Chicago client working in a highly regulated environment. Like other firms in their industry, they have used traditional SDLC approaches and they are now striving to become more agile as part of their transformation from waterfall to the Scrum Framework . And they are getting some traction. They have a few technology teams using Scrum successfully though that represents a small fraction of a
This is part two in my series of posts about improving your retrospectives. As I mentioned in my previous post, the retrospective is a key part of the Scrum Framework. It is designed to help the team make their processes and practices more effective and enjoyable. This post focuses on the first part of the retrospective where we set the stage for the rest of the retrospective meeting.
In my last post I talked about the Scrum Retrospective meeting and how the speed of the retrospective was not the most important thing. The retrospective is critical element of the Scrum Framework. It is a continuous improvement process to help the Scrum Team become more effective and enjoyable. In this post, we are going to explore how the retrospective helps the team improve, and introduce a structure for planning retrospectives.
Most people are aware of the retrospective meeting that is part of the Scrum Framework. It is a key improvement activity used by Agile and Scrum teams at the end of each sprint or iteration. This past week I was coaching a Scrum team and I witnessed one of the fastest retrospectives ever. The entire meeting lasted 13 minutes and there were 9 participants. Fast? Hell yes! Efficient? Perhaps. Effective? Not even close!
I am working closely with some distributed Teams using the Scrum Framework and seeing some challenges with the daily Scrum Meeting. They are probably typical challenges for all new Scrum teams and include some habits developed over years of using other processes. These habits are harder to break because the teams are distributed and reliant on phones or Skype to communicate.
Earlier this week I was facilitating a discussion on agile estimating at a Meetup. A question came up about whether or not the Product Owner of a team using the Scrum Framework should participate in team estimation via planning poker. The majority of the people felt that the PO should not be included. A minority of the people felt that it was OK to include them, and I agreed. What do you think? Do you include or exclude the Product Owner when estimating?