ScrumBut – Part 2: I’m a specialist and that’s not my job

As part of my continuing review of practices that undermine the value of scrum I’d like to focus on two areas that I see teams struggle with. Let’s start with a couple of definitions from Wikipedia.

Team: A team is a group of people who have a certain task to complete. In order to meet their target, the members of the group must cooperate with each other.

Successful team: A group of people tend to meet their target without facing any sort of barrier.

Unsuccessful team: A group of people who have a very difficult time when attempting to complete a certain task. The members of the team think only of themselves and create an uncomfortable environment for other members of the team.

You hope that your scrum team can be called a successful team but how successful they can be depends on how well they cooperate and integrate themselves. This is why co-location is such a valuable team attribute. It’s much harder to cooperate and integrate through distance, time zone, and cultural differences.

When learning scrum some team members bring baggage with them from the Waterfall process. One piece of baggage is the idea of a specialist who can do only one type of work. On a typical scrum team of 7 +/- 2 people if you have more than 1 specialist within the group you’re in danger of scrumbut. Sometimes true specialists are necessary as in the case of a shared resource that has some level of knowledge that can’t be transferred to others easily. In most cases I’ve been able to debunk the myth of more specialists are a good thing. Let’s be clear, we’re all specialist in one way or another. I happen to be a great C++ coder but only okay at writing Stored Procs. It’s just not a good idea on a small team to have a bunch of people who can only do one thing. It creates a very dependent, serialized development process flow. Fortunately this issue is really more of a mindset than a true liability. On my teams I encourage each member of the team to be a specialist in an area that they might be particularly adept at but I also encourage them to learn what the people next to them are doing.

Some at this point might question the logic in asking someone to do something that someone else on the team can do better. Consider this, what do you do when your one and only specialist decides to take a vacation, have a baby, or worse yet ends up under a bus. The more cross functional the team can be the more they understand the bigger picture of what they are doing. This will make integration smoother, more testable code, and allow your team to increase its velocity over time as you end up with more people who can do the same work. An added benefit is that your story estimating should also improve the estimate accuracy since more people understand what’s involved by doing the actual work.

One last area to mention here; the baggage of “that’s not my job”. Going back to the Wikipedia definition of unsuccessful team you’ll see how this person clearly aligns with that way of thinking. It’s everyone’s job on the team to ensure the success of the sprint. It means wearing different hats, doing work that may not have been initially assigned to you, even if you consider that work to be less difficult than what you normally do. In one particular case I’ve heard the argument that developers were selected to be developers because they have an aptitude to write code not test it. I’d assert that way of thinking means that we are in danger of failing as a team; we’ve serialized the effort it takes to develop our product within a given sprint. We must be able to do whatever work is in front of us, regardless of what your role on the team is; if we want a highly functioning team, get over it.

If you see this type of behavior on your team, you may be in the Scrumbut zone.

Avoiding ScrumBut: Why can’t test go in the next sprint

There are many possible failings that can occur when transitioning between Waterfall SDLC and Agile. You can skip daily stand ups, let a single sprint iteration go for months, don’t use a daily burn down, let the scrum master assign work, have talking chickens, or skip sprint planning. Any one or more of these makes your process begin to smell (Mike Cohn: http://www.mountaingoatsoftware.com/system/article/file/11/ScrumSmells.pdf). One particular agile principle that I see questioned often is why does all of the testing have to be done in this sprint; why can’t we do dev one sprint and do testing the next. It’s not very efficient for dev to write code and test it at the same time.

These are all trappings of ScrumBut; looks like scrum, feels like scrum, but definitely doesn’t smell like scrum; in fact it smells very bad indeed. One of the key principles of scrum that shouldn’t be discarded is creating complete work within an iteration. If your organization has a history of constantly changing priorities, half finished work, and low team morale I would strongly urge you to focus on the principle of finishing your work during a sprint.

As software development professionals we should count on changing priorities, it’s the nature of business to reflect and adjust to meet the constantly changing needs of the marketplace and to effectively compete in today’s global market. Half finished work is work that has high potential to be thrown away because it can’t offer immediate value. Team morale suffers when hard work isn’t recognized by shipping to customers. In general this is something that we want to avoid whenever possible.

Going back to the question of why can’t we do dev in this sprint and test in the next; what happens when the CEO (or other senior manager) decides that you should immediately begin work on the “next” thing that will make an impact on the market. Testing a half finished product feature probably doesn’t qualify as a high priority and risks being tossed.

Teams that find themselves in this situation are kidding themselves if they think they can predict the future. As a Scrum Master I often find it difficult enough to ensure discipline to the current sprint without asking that we hold an additional sprint to finish what we started. When agile is proposed to management it’s pitched as being complete within a single sprint (narrow feature scope, complete work). If we remove this benefit from management we should expect them to question other areas the team finds beneficial (self organizing, trust, committed).

Let’s be disciplined to completing the work, don’t drag along technical debt and deliver high quality products to market faster. Yes, it’s a little more coordination effort on the part of the team but it’s also something that needs to be done to deliver on the value of agile.

Management's perspective of Agile development

What do managers want from Agile?

If you're an executive with your job on the line when it comes to shipping a product on time you want assurances if not guarantees that a quality product will ship on time. Experienced managers who are used to waterfall will want frequent checkpoints, detailed reports, and updates on blocking issues. As Waterfall team members we do our best to plan for the work including contigency plans if things go awry. Guess what... things almost always go awry at some point. The biggest failing of Waterfall is that it often causes surprises at the end for management because our crystal ball is very clouded on all except the most trivial projects.

Let's go back to what managers want; a quality product shipped on time. While Agile doesn't guarantee this it does provide frequent feedback along the way that should remove the typical end of cycle surprises that occur when the project goes off the rails. Holding multiple iterations, using burndowns to measure progress and not incurring technical debt will go a long way towards towards meeting what managers want. We need to give managers a choice to make decisions along the way; not in terms of quality but in terms of resources, release date, and features shipped. These are the four variables in the software development equation.

Managers are about results, as long as we can show results that it works I don't think they care as much about what process we use. In this case works = sustainable, predictable, quality delivery of the product.

Product Backlogs

These days there are so many discussions on how many product backlogs to use, what to put in the backlog and who should be able to update the backlog.

I see the experts weighing in on this topic and I begin wonder if they have put their advice to practical use. Having used a single product backlog and multiple product backlogs for a large number of iterations over the years I feel that my experience and intuition is to not follow their advice of a single backlog.

Let's weigh out some of the benefits of a single backlog:

• Single place for all of your user stories.... Check
• Single priority list.... Check

That's where it starts to break down for me. Beyond these two significant advantages I'm at odds to call the rest of the reasons benefits.

What are some of the disadvantages:

• A single point of access; unless you want to buy a tool to manage this you'll need to manage access to the file manually; usually a file share or a single person to make changes to the document.
• There are rarely if ever a single priority list.
• Because some stories are a better fit for a specific team due to subject knowledge the stories are rarely if ever taken in priority order.

In my experience I find that if you have a consistent team and team skills remain largely unchanged it's best to have one backlog per team. This also takes effort because you need to communicate effectively among the other stakeholders on your priorities and dependencies. Something also required for a single backlog. Allowing teams to focus is important and a backlog per team that contains the list of prioritized stories and defects is a great way to make that happen. In your team backlog you would find all of your team's stories and defects along with work other teams require you to do to support them. This dependency is implied in a single backlog due to the relative priority but fails due to the fact that teams aren't interchangeable.

I know my position is a bit controversial and I look forward to hearing your comments.

Innovation in Scrum: The plus 1 week

Scrum is all about delivering business value for the customer, delivering it in the shortest time possible with high quality. This is what your team strives for sprint after sprint. So what happens after you've been doing sprint after sprint for a year? Surely you have delivered a lot of great value for your customer but what about innovation for your product? Innovating often requires time to try out new technologies, improve your work flow processes, and invest in what you're already doing. You can try to do this via a research story or a spike but often doesn't give you the focus to create one great improvement.

My team's used a technique we called, "The plus one week". This technique comes from Mike Cohn's book Agile Estimating and Planning. This technique allows your team time to recharge and focus on improving the process. This improvement may come in the form of tools that speed the delivery of tasks that were previously done manually, or to investigate some new technology direction, or trying out a new interesting feature the Product Owner hadn't requested.

Each team member would pick one or two projects that they could complete within the week's time. They would then work independently during the week and at the end of the week we would hold a "Show N Tell" session where we would invite all of the other scrum teams to see the work that was done. It made for some very interesting sessions; many of the ideas that were generated ended up in the product as a new feature. One idea ended up being it's own product. In the end it was highly successful for the team and the product to invest in the plus one week.

I've heard some comments that managers are worried that the plus one week would be misused and the engineers would spend the week surfing the web and watching YouTube. What we found in reality was that the team looked forward to this time to work on pet projects and that having the end of week demo focused them like any other deadline.

Getting the most out of your next retrospective

Retrospectives are the course correction points in an agile project. If you've done a retrospective well you know how useful they can be. The challenge with retrospectives are in using them to get the most for your team. Depending on how long your team has been doing retrospectives you may find that your team eventually ends going through the motions of holding the meeting and coming up with action items that may or may not ever be completed.

Not that long ago I had the pleasure of meeting and holding a retrospective with Diane Larsen (Co-author of Agile Retrospectives). She helped me work with my team to understand why the team was having difficulties ramping up. As it turned out we had some obvious issues ( Not all team members bought into scrum, team too large) and some non-obvious issues that she was able to coax out of the team through a variety of exercises.

The thing that struck me the most about her retrospective is that she used different techniques to get everyone involved, keep things interesting, and focus the team on what THEY wanted changed.

Since then I've put these techniques to work; like retrospective participant type. An exercise to get a team to anonymously identify how they feel about participating in retrospectives. This can tell you a lot about how effective your retrospectives are. Participant types are Explorer, Shopper, vacationer and prisoner. This is a scale with Explorer getting the most from the retrospectives and prisoner not getting anything at all. So if you have a room full of prisoners you need to make some significant changes to your retrospective.

Another exercise I like is the learning matrix. It's a way of calling out not just the good and the bad, it includes two other areas. Gifts and Ideas. Gifts gives the team a chance to call out those who provided extra effort during the sprint that may not have even been on your team. Ideas can be offered to improve what the team's doing.

I use the learning matrix by writing it on the board and write down each comment as the team calls it out. I've tried using sticky notes that team members post but that leaves less discussion which is the primary reason to hold the retrospective.

The great thing about Diana's book is that it is chock full of ideas on how to mix things up and keep it fresh; exactly what your team needs to remain agile. If you're looking for ways to mix up your retrospective I highly recommend Diana's book.

Quality in the scrum process

Ever wonder why your last sprint tanked? Was it because of changing requirements, undiscovered work that was found during the sprint, or perhaps because your team finished on time but the quality was too poor to release. Let's hope that the retrospective brings these issues to light and your team has the courage to make positive changes.

On the last note, of poor quality, this happens to teams more often that I'd like to think. Since software development at some level is a serial process you can find that we put our test and quality assurance team members in a tough spot... Hurry up and test the product now that we're done coding.

Has this ever happened to your team? During sprint planning your team picks the right stories, they diligently task them out and the team gets started. Of course being the excellent QA engineers they are, they do all the test case creation and automation they can before they see the features coded for the first time. Giving QA a code drop before it's final helps them finish their test cases and gets them started on setting up automation runs but it eventually comes down to having the first finished build they can test the features with.

The software developers do the coding and unit testing before handing it off to QA. Now here's the rub. Often the developers end up using nearly all of the available time in the sprint to finish their features, leaving precious little time for testing. I'd like to say that my teams have never run into this but that's not true. Even after talking about it at retrospectives this is an area where we continued to be challenged. Eventually we did something non-scrumy, we created a deadline for features to be finished by so that the team could complete all of the required testing. While the agile purists out there are surely grimacing this worked great. It allowed the developers to have a firm deadline for hand offs to QA and allowed QA enough time to finish all of the functional testing, regression testing, performance testing and final pass system testing. Now some might say that the developers should have done the testing too which we did but do you really want the person who wrote the code to do the testing too? I don't think so. We had developers test other developers code and over time we were able to reduce the amount of time it took to test everything. In the end we were successful but it required some different thinking.