Comfortably Scrum: How Scrum Are You?

Many Agile pundits think that you are either Scrum or you are not. I disagree with the concept that being Agile or Scrum is a bit flag. Some companies cannot (or will not) adopt all of the Scrum/XP practices initially. You can call them ScrumBut, Scrummerfall, or whatever, but these companies can (and do) still get value from adopting some of the practices of Scrum/XP. They will not get as much benefit and their gains will depend on what combination of process and practices they do adopt. True some of these combinations can actually be counter productive, but I do not think it is fair to shun anyone who is trying their best to implement them.

So when someone tells me they have adopted Scrum, I usually ask a handful of questions to see what they have adopted and to what extent. These questions mainly come from the Nokia Test and specifically the version Jeff Sutherland introduced at my Certified Scrum Master training.

The Nokia Test is to be taken with a grain of salt since it mainly measures the mechanisms you have adopted and only slightly gauges then intent (or ideals) behind them. I do think it is a decent, initial litmus test to see how far your implementation has gone. I have added a few sections to the test aimed at the complimentary XP practices I think are needed for a well rounded Scrum shop.

Here is my version of the test based on Jeff's 2008 version. Determine how many points you get for each question, add them together and then divide by 10.

Question 1: Iterations

• No iterations - 0
• Iterations > 6 weeks - 1
• Variable length <>
• Fixed iteration length 6 weeks - 3
• Fixed iteration length 5 weeks - 4
• Fixed iteration 4 weeks or less - 10

Question 2: Testing

• No dedicated QA - 0
• Unit tested - 1
• Feature tested - 5
• Features tested as soon as completed - 7
• Software passes acceptance testing - 8
• Software is deployed - 10

Question 3: Specification

• No requirements - 0
• Big requirements documents - 1
• Poor user stories - 4
• Good requirements - 5
• Good user stories - 7
• Just enough specification - 8
• Good user stories tied to specifications as needed - 10

Question 4: Product Owner

• No Product Owner - 0
• Product Owner who doesn’t understand Scrum - 1
• Product Owner who disrupts team - 2
• Product Owner not involved with team - 2
• Product owner with clear product backlog estimated by team before Sprint Planning meeting - 5
• Product owner with release road map with dates based on team velocity - 8
• Product owner who motivates team -10

Question 5: Product Backlog

• No Product Backlog - 0
• Multiple Product Backlogs - 1
• Single Product Backlog - 3
• Product Backlog clearly specified and prioritized by ROI before Sprint Planning - 5
• Product Owner has release plan based on Product Backlog - 7
• Product Owner can measure ROI based on real revenue, cost per story point, or other metrics - 10

Question 6: Estimates

• Product Backlog not estimated - 0
• Estimates not produced by team - 1
• Estimates not produced by planning poker - 5
• Estimates produced by planning poker by team - 8
• Estimate error <>

Question 7: Burndown

• No burndown chart - 0
• Burndown chart not updated by team - 1
• Burndown chart in hours/days not accounting for work in progress - 2
• Burndown chart only burns down when task in done - 4
• Burndown only burns down when story is done - 5
• Add 3 points if team knows velocity
• Add 2 point if Product Owner release plan based on known velocity

Question 8: Team Management/Disruption

• External management disrupts team - 0
• Product Owner disrupts team - 1
• Product Owner or Scrum Master assigning tasks - 3
• Scrum Team assigns tasks - 5
• No outside disruptions, only Scrum roles - 10

Question 9: Build Automation

• No build automation - 0
• Continuous Integration build automated - 1
• Nightly build automated - 3
• Unit Tests run during nightly build - 5
• Feature tests run during nightly build - 7
• Deployment to other environments automated - 10

Question 10: Daily Scrum

• No Daily Scrum meeting - 0
• Daily Scrum meeting everyday - 1
• Daily Scrum meeting same time, place - 3
• Daily Scrum runs <>
• Add 2 if reported Impediments are logged
• Add 2 if tasks are directly updated during meeting
• Add 1 if only Scrum Team are allowed to speak

Keep in mind that Jeff told us his best client has a score around 8 and most shops score 6 or 7. I believe this shows that there is no perfect adoption and that all of us are working towards making our implementation better. My best client was around a 7 and it was a great shop to work in.

Let me know where your company lands and where you can improve!

Cool Utility: DeskPins

I stumbled upon a very cool utility called DeskPins which allows you to "pin" an application so that it will stay on top of all other applications regardless if it loses focus like Task Manager does. I use it for quite a few scenarios like having a Hulu TV show in the corner while I code, having notepad up while I cut and paste from various applications, and having a little application timer I wrote pinned to the corner during my presentations. It runs in the tray and you can use Ctrl + F12 to pin the current application window to the desktop. A little red pin shows up on the title bar.

5 Tips for Making Your Code Presentations Easier to View

When presenting I am normally in front of 50+ people in a large, dimly lit room. Since I have sat through many presentation myself where I was straining to see bullet points or code samples myself, I try to design my presentations to be easy to view in a large, dark room. I also utilize some Visual Studio settings and other tools to help make things easier to see.

Making your presentation content starts with your slides themselves. The two main areas I work on is the amount of text on each slide and the format of the text and slide background together.

TIP #1: Use Less Bullet Points

I have blogged before about the book "Beyond Bullet Points" that has some good ideas about presentation styles. I do not agree with all of them, but I do try to have as little purely bullet point slides in my presentations now. Here is a simple, single slide with multiple bullet points. It is very bland and the content blends together. With more content the font size has to get smaller and it gets hard for people to see.

So I take a slide like this one and split it into multiple slides. The title of the bullet point list would be on a separate, distinctly formatted slide to set it apart as the title (or theme) for the next series of slides. Each bullet point would get it's own slide. This way the font size can be much larger so that the text is easy to read. I try to keep each sentence fairly small and simple to that it can be read quickly. Using contrasting font colors to stress the primary words helps also. There is also usually enough room to add a graphic or animation that helps bring home the point of the slide. Here are some slides formatted in this style.

TIP #2: Use Dark Backgrounds and Light Font Color Schemes

You can search the web and find just as many people telling you to use dark text on a light background as you will people with the opposite view. For printed materials dark text and light background is the easiest thing to read in ambient light, but in a dimly lit room with the content projected on a screen the opposite is true and this post does a good job of explaining the reasons why. To prove the point take a look at the images below.




Imagine that you are in a dark room and you are viewing dark text on a white background. Your eye actually take in the outline of the white container first, then view the text. With a dark background that can blend into the dark room, the light colored text is the initial focus.

I also use a pattern in the background like a subtle gradient or waves that helps break up the slide a bit more.

TIP #3: Format the Visual Studio Editor to Use a Larger Font and a More Viewable Color Scheme

In most of my presentations I am showing code in Visual Studio. This is usually the hardest thing for someone a few rows back to see. I do a couple of things to make this easier for them.

• Increase the font size - I normally go 20 pt for the font size to make sure even the people in the cheap seats can see. The default font looks pretty bad at that size so I also change the font to Consolas which looks pretty good at that size.


• Change colors - Just like the slides, I change my colors to be lighter text on a dark background. I found a nice scheme called Midtone from Coding Horror that I like.

Once I have it setup the way I like it I export the settings so that I can switch to them when I give a presentation (since I do not code normally with my font at 20pt).

When I open a section of code to show, I also switch to full screen mode by pressing Shift + Alt + Enter which hides everything bu the main menu to give me the most screen real estate for showing the code.

TIP #4: Use a Mouse Magnifier

Unless you are using your original PS2 mouse from 1997, you probably have a mouse with extra buttons that can be mapped to all sorts of neat features. I use the Microsoft Presenter Mouse which is great for giving presentations. It comes with Microsoft Intellipoint (which you can download for free) which allows me to map one of the extra buttons to a magnifier. Since often all I can enlarge is the font in Visual Studio and other applications, if I have to show a toolbar or icon I can use the magnifier to enlarge a section of the screen to make it more visible.

TIP #5: Format Your Command Prompt for Larger Fonts and More Screen Space

Quite often I open a command prompt to show something at the command line. Just like viewing code, by default these windows are hard to see in a presentation. You can open the command prompt (I normally use the Visual Studio 2008 Command Prompt) you can right click on the title bar and choose Options.

In these options you can increase the font size as well as the size of the window although I try to go full screen. When you save your changes you can choose "Modify the shortcut that started this window" so that the next time you use that shortcut you will have the same settings.

Conclusion

I have found the above techniques make my presentations much easier to view in large, dimly lit rooms. Your attendees are going to thank you!

Comfortably Scrum: IIBA Presentation "Introduction to Agile Development Using Scrum"

Tuesday, January 20th, I will be speaking at the International Institute of Business Analysis luncheon held at Belmont University. I will be presenting my Introduction to Scrum content with a more Business Analyst twist to it.

Rational Team Concert/ Jazz Platform: Serious TFS Competitor?

So I have been taking a look at Rational's Team Concert and their Jazz Platform for software delivery. The have a beta client out for Visual Studio and if you take a look at this demo you will see strikingly similar features as compared to Team Foundation Server. There is a session for this proposed for the Agile 2009 conference that I am hoping to make it to this year. It will be interesting to see this product demonstration and compare it to the VSTS/TFS feature set.

Team Foundation Server Installation Troubleshooting Guide

I hate re-blogging posts from another blogger, but Brian Harry's post about the new guide for Troubleshooting Installation for Team Foundation is worthy of breaking my rule. A few months ago I was at a client performing an upgrade of TFS 2005 to 2008 and we hit a snag in the middle of the installation where the setup could not configure the SQL Reporting Services web directories in IIS. We spent 4 days on the phone with Microsoft who finally advised us to slick the server and install TFS 2008 from scratch then restore the databases. I have already seen some of the symptoms we experienced in this guide.

It also has some post installation configuration issues I have seen many times. These also pop up after service pack installations or similar events that alter the configurations of any of the supporting services.

Definitely keep this guide handy!

Comfortably Scrum: Man Cannot Live on Scrum Alone (Throw in a Little XP)

Many detractors of the Scrum framework claim it to be too thin and does not include the prescribed Agile engineering practices like XP. Scrum is actually supposed to be a very light weight framework for a company to adopt into the development process. It is minimalistic on purpose.

As far as the engineering practices, one does not have to search too hard to find all the primary originators of Scrum stating that it is a management wrapper for XP. The Control Chaos website has a good summary of the xp@scrum approach here. During my Scrum Master training, Jeff Sutherland himself featured the graphic below prominently in his first few slides and stressed how the engineering practices of XP were essential to getting more productivity out of any Scrum implementation. Ken Schwaber has also co-authored an article about combining Scrum and XP.



All of this information has been around for quite awhile and is fairly prominent, so I find it astounding that so many still see these approaches and not compatible. Jeff also told us in our training of the infamous email he received from Kent Beck in 1995 asking for more information about Scrum so he could incorporate it into his approach:

"Is there a good place to get reprints of the SCRUM paper from HBR? I've written
patterns for something very similar and I want to make sure I steal as many
ideas as possible."

In general, Scrum leans more towards a management process that supports Agile development processes like the ones prescribed in XP. I personally believe that you cannot be very successful with Scrum without implementing things such as Continuous Integration, Unit Testing (TDD), Coding Standards, Small Iterations, Sustainable Pace, etc.

I also think Scrum is a bit more acceptable to the masses (which some people also site as a detractor) that a pure implementation of just XP. It is called extreme programming for a reason!

Hopefully this combined approach will be what people implement rather than just adopting the Scrum mechanics and continuing to develop with their same, non-agile methods. This would most likely lead to failure and that usually gives people the impression that the reason for the failure was Scrum.