peterstev's blog
Nothing can ruin a Sprint Review meeting like having no stories to show the product owner when the sprint is finished. This week, I participated in two Sprint Reviews in two different companies. Both teams had the same problem. They took on stories which were so big that they had a queasy feeling committing to them. Of course, the stories grew during the sprint.
When should you advise your team not to accept a story because it is too big?
3 Warning Signs
Not accepting over sized stories is pretty standard advice. But how do you recognize when the story is too big? These are my warning signs:
- Past performance indicates you won’t get it done
- The story is large compared to the team capacity for the sprint
- The demo is complicated and / or demos many sub components.
Bookmark/Search this post with:
As a customer or supplier of software services at the beginning of a Software Development Project, you know that there is too much at stake to work with just a verbal agreement. A contract is really just a set of written playing rules. The right rules increase the chance of success for both parties. The wrong rules make cooperation difficult and hinder progress. What are the available playing rules and what is the best approach for a agile project?
Bookmark/Search this post with:
As a customer or supplier of software services at the beginning of a Software Development Project, you know that there is too much at stake to work with just a verbal agreement. Although the Agile Manifesto values customer collaboration above contracts, contracts are necessary when working with external suppliers. A contract is really just a set of written playing rules. The right rules increase the chance of success for both parties. The wrong rules make cooperation difficult and hinder progress. Which contract forms are best for agile software development projects?
This is the first of two articles. In this article, we’ll look at the purpose and contents of a contract and some criteria for evaluating agile contracts. Next week, we’ll look at contracting alternatives for Scrum software projects and examine their strengths and weaknesses.
Bookmark/Search this post with:
Recently, Scrum and the Certified Scrum Master program in particular have come in the crosshairs of non-Scrum Agilistas and been condemned as a Bad Thing. Martin Fowler wrote about Flaccid Scrum. James Shore, author of The Art of Agile Development explained why he doesn't do agile certification. Certification is about mediocrity and agile is about striving for greatness.
If we believe that agile is eventually going to become the mainstream software development strategy — and I do — then this attitude misses the mark. In a time when every office worker gets told 'A Microsoft Office certification is good for your career,' it is clear that certification is part of the game. We may not like it, but we ignore this reality at our peril.
Bookmark/Search this post with:
“My job is to make myself redundant.” That’s what I told my customer 6 months ago as we started our Scrum coaching project. The development group had been working for almost 2 years trying to develop a software package which would make the company’s very sophisticated hardware attractive to its potential customers. They were “close” to a release, but the release always seemed to recede into the distance like the horizon. Six months later, my assignment is finished: what did the team accomplish, what did it not accomplish, and did I achieve my goal of becoming redundant?
My First Day
I spent the morning with management. In the afternoon I met the development group. The team was under a lot of pressure to make a release “soon.” I realized as I looked around the meeting room, all managers (including myself) were sitting on one side of the table, the developers on the other. Hmm.
Bookmark/Search this post with:
“If that team can find a way to revert to Waterfall, it will!” “Any team that can find a way back to Waterfall will find a way back to Waterfall!” These modern corollaries to Murphy’s Law haunt every Scrum transition and manifest themselves in the Daily Scrum. If the ScrumMaster lets it degenerate, the success of entire transition is called into question. 10 Warning signs that something is wrong in your Daily Scrum and what you can do to correct the problem.
The Daily Scrum is simple daily routine to help the team self-organize, focus, and identify and eliminate impediments to progress. As the backbone of the self-organizing team, the Daily Scrum has nearly nothing in common with a classical project meeting. Team members synch up with each other on what is being done and lay the ground work for self organization — which takes place after the Daily Scrum.
Bookmark/Search this post with:
Scrum is simple and Scrum is hard. The Daily Scrum is simple daily routine to help the team self-organize, focus, and identify and eliminate impediments to progress. How do you conduct the Daily Scrum and how do you know if the Daily Scrum is achieving its purpose?
When and Where to hold the Daily Scrum
Scrum defines basic rules for holding the Daily Scrum. The Daily Scrum should be held at the same location and the same time every day, ideally in the team space in front of the team’s big visible task board. The task board displays the release and sprint burn down charts and the state of each task in the sprint backlog. Each task is represented on a card and moves through the columns from “waiting” to “in work” to “done”.
Before the meeting starts, each team member should update the state of his tasks and the sprint burn down chart on the task board. These make the current state of the sprint visible for all to see.
The Daily Scrum should be held first thing in the morning, so that team members use it to focus their planning for the day. Practical considerations, e.g.
decentralized teams working in different time zones, may require a different time or even changing the time from Sprint to Sprint.
Bookmark/Search this post with:
Last week I gave an introductory talk about Scrum to a group of people in Zürich. One participant asked if it would be OK to make the Daily Scrum a Weekly Scrum? My answer: No way!
The Daily Scrum exists to enable self organization. It helps the team focus, communicate and identify impediments. The team members communicate to each other their progress, goals and impediments. The team members identify how they can help each other to reach the shared goal of the sprint.
Each team member answers three questions:
- What did you accomplish yesterday?
- What is your goal for today?
- What is preventing you from accomplishing your goals?
Bookmark/Search this post with:
One key to success in any development project is the collaboration
between the customer and the team. As Product Owner, you are either the
customer or the conduit to the customer. Your job is to guide the development effort
to a successful conclusion. No one on the team is pulled in more directions at
once than you are. You want your team to work effectively. You want your team
to build the right product.
You must allocate the right amount of your time between
team, customers, management and other duties. Are you spending enough time with
the team? How much time is enough? Does the team even want you to be present at
their meetings? If not, why not? And what are the implications of not spending enough
time with your team? Three suggestions for better collaboration with the team.
Bookmark/Search this post with:
As a Scrum evangelist, I often talk to groups about Scrum. I want each talk and each course to be better than the last one. The best source for feedback is the audience, but usually audience feedback is limited to a multiple choice feedback form. You get a report card, but nothing to build on. I now collect feedback from the participants using a feedback form inspired by Scrum’s Heartbeat Retrospective. This provides useful information and enables continuous improvement as a speaker.
Bookmark/Search this post with:
RSS feed
Subscribe on Kindle
