This survey is different, and I took the time(about 10 minutes) to fill it out. I suggest you do as well.
This question was asked in an online forum(I’m paraphrasing):
> How do people here handle the impact of difficult errors/bugs (but not legacy bugs) on sprint progress? Like ones that take weeks to solve?
In my professional opinion, the answer is: we make them transparent and try to improve upon them — at Daily Scrums, Sprint Reviews, and Sprint Retrospectives.
I tend to coach teams to handle bugs in Scrum using the Bradley Bug Chart.
One of the aspects of the Bradley Bug Chart is that bugs like the one mentioned (i.e. non legacy bugs) end up on the Sprint Backlog. Because they end up on the sprint backlog, if one is using Story points and velocity, no story points are assigned and no velocity is gained from fixing bugs. This, once again, helps provide transparency on to the lack of progress that the team might be making due to bug fixing. The truth can be a hard pill to swallow, but the truth will also help set you free from these mistakes in the future.
The transparency should help all involved understand that there is something that needs improving, that is dragging down the team’s ability to produce new features and working software. I would argue that this is not a sprint killer. It is simply a fact of complex software development.
One of Scrum’s main tenants is about self organization. Self organization is difficult enough to achieve on its own, especially with a new Scrum team or a team who has members who are new to each other on it. In the context of this article, when I say “Manager”, I mean someone who has a large amount of input in determining the company advancement (performance reviews, raises, promotions, etc) of any individual on the Scrum Team. It could be someone a team member reports to, or it could even just be a supervisor or team lead. Sometimes a Manager plays a Scrum role like Product Owner or Scrum Master. I’m *especially* talking about those managers. Those managers should not attend the retro, or at the very worst case, should attend only a minor part of the retro(See “Strategies” below).
It should be obvious to Managers (though often it is not), that honest genuine feedback about how to work better as a team is very hard to get with a Manager in the room. Every time a person opens their mouth, they are taking a political risk if their manager is there, and that is not a safe environment for true collaboration and innovation. Managers, if you don’t believe me, try the strategies below for 3 sprints, and judge the results for yourself. You, as a manager, have every right to ask the team, one day after the retrospective is over, for their plan of action on improvements. I say one day after because I’d strongly prefer that you not come into the room where the retrospective is being held once it is over. Often times there are things on whiteboards that you may or may not understand, and again, that becomes unsafe.
Excluding the Manager from the Retrospective is not an attempt to usurp the Manager’s authority or anything like that. It is to create the safety and experimentation that is required for great innovations to occur. The Manager still has a very important role to play — see The role of Managers in Scrum .
The PDH retrospective is a retrospective format that is very efficient and fairly simple. Teams quickly generate discussion topics(Transparency) by listing the things that went well(plusses) and the things that should change(deltas) to make the team better in the upcoming Sprint. The team then has a chance to quickly vote on the discussion topics to help prioritize and order the discussions. With the discussion agenda quickly set, the team then sets about discussing the most important topics(Inspection) and develops action items(Adaptation) that allow the team to improve its Scrum implementation.
(This is probably obvious, but the number of votes and time-boxes can and should be adjusted to the team size, time allowed, etc)
This pattern implements the required elements of Sprint Retrospectives in the Scrum Guide. The required elements basically boil down to:
I’ve seen the “Plus Delta” analysis and “Dot Voting” (Hash Voting is a variation of Dot Voting) in several publications and web sites, but I don’t really know the origin of the techniques. This pattern is one I’ve developed over time in coaching Scrum Teams and it seems universally successful. Having said that, don’t forget the Best Practice – Change Up Your Retrospective Format. If anyone knows of the true origins of any technique described above, feel free to email me at the address on the home page and I’ll be happy to post it here.
I often get asked to evaluate a particular Scrum tool or to compare the relatively value of one to another. To be honest, tool evaluation is not something I spend significant time on. Most teams I coach have little choice about which tool to use, so I usually just a) try to encourage them to use more manual techniques and b) help the team adapt the tool usage to their optimum performance/usage, which sometimes means no usage.
Ok, hate is a strong word, but I’m generally anti-tool when it comes to managing Scrum artifacts and data. I strongly prefer more manual techniques (Scrum Boards, sticky notes, story cards, white boards, wikis, etc).
The vast majority of the time I have seen Scrum teams extensively using a tool, it is wasteful or aids in creating poor habits. It’s pretty hard to justify spending money on a tool that decreases overall productivity. I’m amazed at how many companies do this. I also believe that most of these tools have a huge amount of bloat in them, and thus the bloated features either a) obscure the needed features or b) waste a lot of time with very little ROI in terms of value.
Besides the normal effects of top down mandates (poor adoption, minimal ROI, etc), the elephant in the room created by mandating tools is that it greatly harms self organization on a Scrum team. Mandating particular tools or tool usage is just another form of command and control management. To achieve Scrum’s benefits, self organization is absolutely vital, which means, when it comes to tools, the team should be able to make their own choices. I want the team as a whole (and preferably not the ScrumMaster at all) to create, maintain, own, love, and care for their own artifacts. Having said all of this, it’s perfectly acceptable for management types to try and organize company strategy around goals and timelines — I just don’t believe that Scrum software tools are a good way to do that.
There, I said it… I’m generally anti-tool for Scrum artifacts and data.
In a future blog post, I intend to talk a little about some special contexts in which I think tool usage is ok, and about my general views as to the kinds of tools that I like. Teams where multiple members are working mostly remote is one exception to my generally anti-tool stance. I’ll talk more about that in the future post.
Here is how I define a Best Practice:
Many teams talk a good game on making changes to their development process, but fewer actually make those changes. Therefore, it is a Scrum Best Practice to make Retrospective action items highly visible to the team, usually on or very near the Scrum Board.
The visibility technique employed will be highly dependent on the team. Consider some of the following methods, or come up with your own!
Here is how I define a Best Practice:
Don’t take this the wrong way. I’m *not* suggesting that you all sit around a table and estimate tasks like Planning Poker or anything. Besides, Planning Poker is for sizing Product Backlog Items, not Sprint tasks. What I am suggesting is that when your team does Sprint tasking, generally in the Sprint Planning Meeting, allow the entire team to see the tasks and suggest modifications. Typically, with an experienced team, I recommend the team split up into pairs to create tasks for each Product Backlog Item. I then have the team re-join later and let the entire team view all tasks and their estimates. I then encourage the team to spend a short amount of time tweaking the tasks and estimates. Don’t fall into task analysis paralysis or anything, just give some short amount of time for some high priority tweaking. Whatever you do, don’t overthink task estimates! Just put something down quickly and then retrospect on it later.
It is perfectly acceptable to re-task one or more tasks mid sprint. Sometimes, you’re just not able to accurately predict the tasks for your sprint. The most important thing about your Scrum board is that it accurately reflects the work remaining in the sprint, to the best of everyone’s knowledge. I recommend you do not re-task alone. The tasks were originally created as a team in the Sprint Planning Meeting, so it’s important that you don’t re-design tasks alone. Consult with at least one team member when you’re doing this. Also, inform whoever updates your Sprint burndown so that the calculations stay correct. If the re-tasking is noteworthy, take 30 seconds to increase transparency by letting the entire team know about the re-tasking activity at the Daily Scrum.
Sometimes a small sub-portion of the Team will do the initial creation and estimation of tasks. In these cases, make sure that the Team eventually takes a broad view of the Sprint Backlog before finishing the Sprint Planning Meeting. Near the end of the meeting is a good time to have the entire team view the entire Sprint Backlog and get clarifications make tweaks. Don’t get too caught up in the clarifications, of course. Whatever you do, don’t overthink tasks! Just create simple tasks and then retrospect on them later.
What are your favorite Sprint Tasking Tips? Post them in the comments.
In this article, I discuss the role of those outside of the Scrum Team. This includes managers, stakeholders, and any other member of the organization that the Scrum Team works for. I look to the Scrum Guide first, and then discuss some other ideas not specifically from the Scrum Guide. In short, the role of those outside of the Scrum Team is to:
In my post earlier this week, I spoke to the role of Managers in Scrum, which is a specific subset of those outside of the Scrum Team.
A common question when trying to implement Scrum is, “What is the role of members of an organization that are not on a Scrum Team?” Let’s take a look and see what we can find out about this.
Click the link below to see what the Scrum Guide says about people not on the Scrum Team:
“People not on the Scrum Team” includes managers, as well as anyone without a defined role on the Scrum Team.