Thursday, July 23, 2009

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.

Wednesday, July 15, 2009

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.

Tuesday, July 14, 2009

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.

Monday, July 13, 2009

How do bugs fit into Scrum

Zero bugs; it's the nirvana we all strive for as software professionals, it's also unfortunately a myth. The only way to write code without bugs is to not write code. All software has bugs, it's simply of matter of how hard you look to find them. You'd like to think that the top companies somehow have come up with a way to create bug free software. After working at two of the biggest, Intel and Microsoft I can tell you they haven't figured out how to ship bug free code either.

Scrum isn't a magic process that doesn't have to deal with finding and fixing bugs. Like waterfall it focuses on the delivery of the product and with the product comes bugs. If you're using scrum how do you account for fixing the bugs that exist in your legacy product or dealing with the new ones you're creating as you write code this sprint.

Most of us should be familiar with bug triage and assigning severity and priority to bugs. All well and good but that doesn't get the bugs fixed and regression tested. I recommend an approach to assist with first managing the current load of existing bugs and to deal with any new bugs found.

  1. If you aren't holding a weekly bug triage do this now. I've been on teams that didn't emphasize triage of bugs. It came back to bite them. As a scrum master on these teams my job is to facilitate and schedule these weekly triage meetings which is the first thing I did when encountering this issue. Second, make sure that you show up prepared with a query that can identify open high priority bugs, bugs awaiting triage bugs fixed but not verified, and all bugs that fail regression. This should give a quick look at the overall health of your product wrt bugs.
  2. Now that you've got a regularly occurring bug triage meeting let's account for the time it takes to fix legacy bugs. On my past teams we've taken on the highest priority bugs during the sprint planning meeting by having a story for fixing the 'X' highest priority bugs. Note: this is an estimate, you will not be able to fix all of the bugs in the bug database. This bug "bucket" allows the team to carve out enough time for the highest priority bugs while still leaving time for the team to focus on features.
  3. Developers are writing code during the current sprint, bugs are being created too. Your development team shouldn't be using the entire sprint to develop code, there has to be time to do testing and find/fix bug loop. If the team doesn't leave time to do this you will either ship low quality code and/or push technical debt into a future sprint. Which isn't good because the Product Owner is expecting the team to be ready to start the next set of features in the next sprint, not fix the left over issues from the last sprint.

Your mileage may vary but I've been relatively successful in keeping technical debt low, shipping high quality features, and meeting the needs of my team and customers using this technique.

Friday, July 10, 2009

Making the leap from Project Manager to Scrum Master

So you've gotten your certification from PMI as a certified Project Management Professional (PMP) but the world starts to change around you. Something new is on the horizon called agile software development and it's moving fast. Everywhere around you people are talking about it, it routinely shows up in job descriptions, and you feel woefully unprepared. First, don't panic. Today agile SDLC is gaining mind share among software professionals but in practice you still find waterfall SDLC deeply rooted. Even organizations that say they are doing agile are trying XP, Lean, or Scrum on a trial basis and often with a heavy overtone of waterfall processes.

Whew, you've still got time to prepare. So you ask yourself, how do I prepare myself for Agile SDLC. Fortunately there are courses you can take, books and blogs to read to get you better acquainted with this process. I recommend you start by reading blogs and books, it's by far the cheapest way to get an introduction. Attending a local meeting of an agile SIG can also introduce you to the terminology and ideas. I attend a local group that meets monthly to discuss a variety of agile topics. Everyone is welcome and there are no dumb questions.

One thing you need to be prepared for are some of the bigger differences between Waterfall and Agile. In Waterfall you don't do anything until all of the preparation is complete (MRD, PRD, Functional Specs, Technical Specs, Design Documents, Test Plans, Release Plans, and finally a schedule); in Agile (Scrum in this example) you follow the agile manifesto principles which value conversation over documentation and working software over a well written plan. I've heard agile documentation referred to as "Just in time documentation", meaning you don't write it unless it's absolutely needed. On my teams we often do this on a wiki to keep the information easy to access and easy to update by anyone on the team.

I've just scratched the surface on some of the differences between Project Manager and Scrum Master. More later.

Thursday, July 9, 2009

Scrum with an absent Product Owner

What is scrum? Scrum is a set of principles/activities that allows a group to coordinate actions and deliverables so that something useful is delivered (has business value) when finished. It's also an agile process for delivering software.

Scrum to many is just a word that can conjure images either of complete anarchy or nirvana depending on your understanding of it. Scrum is successful when all involved coordinate based on roles on the team. You have your pigs and chickens as roles; you have your team member, scrum master and product owner roles as well. As team member on the team my role is to produce output that in it's entirety has business value. As a scrum master my role is to ensure the team meets daily, identify and remove impediments, and act as the liaison to the Product Owner. As the Product Owner I'm the one ultimately responsible for delivering business value to my stakeholders.

What happens to the team if the product owner role isn't filled or even worse has someone who only takes that responsibility semi seriously? For many teams they will overcome and in the short term be successful. Unfortunately in the long term they fail; mainly because they are focused on the sprint or next couple of sprints. There is no overall strategy or vision. A product owner who rarely shows up at daily standups or decides that attending the end of sprint review is optional for them is doing a dis-service to the team and ultimately to the company.

If you find yourself with an absent product owner I recommend taking action by talking to the product owner and letting them know the value that they add by being an active member of the team.