Agile Banana

Ever read a great article about Scrum and thought, wouldn't it be great if my team did this. But then when you've suggested the idea, it was received with indifference, or worse, resistance? We've all been there. It's hard not feel confused or deflated about why others don't feel the same enthusiasm as you do about some of the great ideas you come across. Well, if you want to get a better result, this retrospective idea is for you. This retro follows the typical retrospective format as set out in  Agile Retrospectives: Making Good Teams Great by Esther Derby and Diana Larsen . In the following example, the team were asked to read an article about Backlog Refinement in preparation for the Retrospective. However, the article and topic in question can be changed to suit the needs of your team. I've used Miro in this example below which is a great collaboration tool for remote teams. Setup 1. Circulate a link to the article you'd like your team to read. Set asid...

The following retrospective follows a simple format for helping teams reflect on any of the events or meetings that routinely take place during a sprint. The following example is used to help my team reflect on Backlog Refinement. This retro follows the typical retrospective format as set out in  Agile Retrospectives: Making Good Teams Great by Esther Derby and Diana Larsen . Setup Draw some type of scale - could be as simple as a line drawn on a whiteboard. Team members will mark on the board how they feel about backlog refinement. Draw a box with two columns - one will be used to capture what the team think is currently good about backlog refinement, and the second will capture what the team think could be better Draw a box with two rows - one will be used to capture the top three improvements that the team want to see, the other will capture the steps that the team need to take to make those improvements a reality Get a wad of post it notes Set the stage Ask each member of the ...

Mood by Masterpiece This is a starter exercise for an agile retrospective that will take 5 - 15 minutes depending on the size of your agile team. It's a great, low-risk, abstract thinking exercise for getting team members talking at the start of a retrospective. It brings out different perspectives on how the team felt about the recent sprint, and builds a greater sense of empathy and understanding. In the following example I used  Miro  which is a great collaboration tool for remote teams. Setup: Select any six pieces of artwork Lay them out on a grid Give all team members a post-it note with their name on it Running the exercise: Ask everyone to drag their post-it note to the piece of art that best encapsulates how they feel about the sprint that has just finished. Once everyone has placed their post-its, ask each member of the team to say just a sentence or two - doesn't have to be anything profound - about why they've chosen the piece of art that they have. Outcome Asi...

We recently started a sprint with user stories that were dependent on work being done by other scrum teams on a scaled agile project. The Problem The Tech Lead and Product Owner came to me with the initial assessment of the situation. The following nine items of work all needed to be coordinated, otherwise we'd face environment problems that would block progress on other tickets.  Specifically, Team Avocado and Team Bobcat needed to complete items in their sprint, before Teams Candyfloss, Dalmatian, and Elephant could complete items in their sprints. If teams Candyfloss, Dalmatian and Elephant didn't complete their work, then we'd be left with a situation where environments across the project would be broken and potentially inoperable.  Furthermore, an initial assessment by our Tech Lead determined that the items sitting with Avocado were "breaking changes" (represented by sticks of dynamite in the illustration above).  As soon as any one of these pieces of work w...

Up until now, the wireframes for the UI element of our user stories have been produced by our Product Owner, Business Analyst and Tech Lead. The wireframes are typically discussed as part of the story in backlog refinement. Now we have a dedicated UX designer working on the project. But how best to loop them into the scrum teams? My immediate thought was that he needs to be brought in as a full, multidisciplinary member of each scrum Team.  However, I also had reservations about this approach - given that we have multiple scrum teams. Wouldn't this be an inefficient way to do things. To have the UX designer attend the scrum meetings for more than one team seemed inefficient. Must be a better way. In the end, we decided to start by setting the UX designer to work on producing wireframes for particular user stories. When these user stories were going to be discussed by each team, the designer would come along to Backlog Refinement / Sprint Planing, talk through the wireframes, and an...

"We need a burn-up chart so we can see if we're on track." This was a request that came from programme management, and needed a bit of unpeeling.  What are we trying to achieve with the burn-up chart? What is the problem that we're trying to solve? After talking through a few examples of burndown charts, and the reporting features in Jira - we decided that ultimately, the question we were trying to answer was this: "are we on-track to finish the product in time for its scheduled launch date?" So -- what do we need to answer this question?  The first thing that sprang to mind was a list of the must have requirements for the first product release. Without this, we wouldn't know what we were monitoring our progress against. Although we had a list a epics that we knew were needed for the release, these were very (VERY) high level. If they had been estimated, I wasn't aware of it. But then the uncertainty in my mind was how to track against the must haves...

The Scrum Guide is the lightweight introduction on how to get up and running with Scrum teams. It’s written by Ken Schwaber and Jeff Sutherland, the creators of Scrum. The Scrum Guide describes Scrum in a nutshell (p. 3): A Product Owner orders the work for a complex problem into a Product Backlog.  The Scrum Team turns a selection of the work into an Increment of value during a Sprint.  The Scrum Team and its stakeholders inspect the results and adjust for the next Sprint.  Repeat But what does this mean if I want to get started with Scrum? Well, here are some simple steps: Step 1 : Appoint a Scrum Master to help accomplish and coordinate the following steps... Step 2 : Get someone who understands what the outcome of a project needs to be from the perspective of your most important stakeholder – commonly the customer. This person is the Product Owner, who can talk to people about what needs to be done and explain why it has value to the customer and the success of the p...