Categories
Cocos2d-iPhone Programming

Cocos2d Tip #2: Using CCTimer in Your iPhone Game

If you’re writing almost any type of game, from a puzzler to a FPS to an RTS, tracking time is critical element of the game play. (Except for Angry Birds. You can ponder an Angry Birds level until your iPhone battery runs dry without penalty.)

Cocos2d-iPhone provides several means for tracking time in your game and scheduling methods to be called at both regular heartbeats and at arbitrary points in the future. The easiest way to manage time in a Cocos2d-based game is to use a CCLayer’s scheduleUpdate or schedule methods. Both methods are explained nicely in the timers section of the Cococ2d Best Practices guide. The guide also explains why you should try to avoid using iOS’s NSTimer class. (Your game will miss out on automatic pause and resume if do use NSTimer.)

But what if you can’t use scheduleUpdate or schedule in your game because you’re putting your game logic into a custom class instead of a CCLayer or CCSprite?

For the sake of simplicity and portability I don’t subclass CCSprite in my games. Instead, I create custom classes to represent my game objects and call update:(ccTime)delta on them from CCLayer objects to make stuff happen. I needed a nice timer class and started to write my own. About halfway though this project I ran into Cocos2d’s CCTimer. Since I’m trying to write as little code as possible I abandoned my timer. CCTimer is a nicely written, lightweight timer class that uses NSInvoker to create callbacks and still integrates will with the rest of the Cocos2d-iPhone framework.

Here’s how it use it…

First, I store a reference to a timer in my non-Cocos2d class:

// Zombie.h
#import "cocos2d.h"
@interface Zombie : NSObject {
    BOOL _resurrectable;
    ccTime _resurrectionCountdown;
    CCTimer* _resurrectionTimer; // own
    float _rebirthPenalityPercent;
}
@property (readwrite, nonatomic, assign) BOOL resurrectable;
@property (readwrite, nonatomic, assign) ccTime resurrectionCountdown;
@property (readwrite, nonatomic, retain) CCTimer* resurrectionTimer; // own
@property (readwrite, nonatomic, assign) float rebirthPenalityPercent;
- (void) startResurrectionTimer;
- (void) stopResurrectionTimer;
@end
// Zombie.m
#import Zombie.h
@implementation Zombie
@synthesize resurrectable = _resurrectable;
@synthesize resurrectionCountdown = _resurrectionCountdown;
@synthesize resurrectionTimer = _resurrectionTimer;
@synthesize rebirthPenalityPercent = _rebirthPenalityPercent;
+ (id) getInstance {
    CCLOG(@"%@: %@", NSStringFromSelector(_cmd), self);
    return [[[self alloc] init] autorelease];
}

- (id) init: {
    CCLOG(@"** %@: %@", NSStringFromSelector(_cmd), self);
    if ((self = [super init])) {
        self.resurrectable = YES;
        self.resurrectionCountdown = 30.0f; // half a second
        self.resurrectionTimer = nil;
        self.rebirthPenalityPercent = 0.10f; // 10% less health
    }
}
@end

Second, I define a call back method to stop the timer:

// later on in Zombie.m
- (void) stopResurrectionTimer {
    CCLOG(@"%@: %@", NSStringFromSelector(_cmd), self);
    if (self.resurrectionTimer != nil) {
    // the only way stop a timer is to deallocate it
        [_resurrectionTimer release];
        _resurrectionTimer = nil;
    }
    // do stuff when the zombie dies...
}

Third, I define a method to start the timer:

- (void) startResurrectionTimer {
    CCLOG(@"%@: %@", NSStringFromSelector(_cmd), self);
    if (self.resurrectionTimer != nil) {
         // if there is an old resurrectionTimer then deallocate it
         // (this is the only way to stop a timer)
        [_resurrectionTimer release];
        _resurrectionTimer = nil;
    }
    //  allocate a new timer with a built-in factory method
    // the stopResurrectionTimer method is called when
    // the time is up!
    self.resurrectionTimer = [CCTimer timerWithTarget:self 
                                             selector:@selector(stopResurrectionTimer)
                                             interval:self.resurrectionCountdown];
}

Fourth, I add a call to update the timer in my CCLayer’s update method:

// ZombieGameLayer.m
- (void) update:(ccTime)delta {
    [self.zombie.ressurrectionTimer update:delta];
}

Finally, Somewhere deep in my game logic I start the timer at the right dramatic moment.

// somewhere else in Zombie.m
- (void) die {
    // call when killed
     CCLOG(@"%@: %@", NSStringFromSelector(_cmd), self);

    // if resurrectable start resurrectionTimer
    if (self.resurrectable) {
        [self startResurrectionTimer];
    }
}

It’s important to note that at the time of this blogging, the CCTimer documentation claims the interval value used to determine the length is in seconds, but really it’s in milliseconds (that is 1/60 of a second). If want your timer’s call back to run in 2 minutes set the CCTimer interval to 160.0f.

It’s also important to note that CCTimer is independent of frame rate: This might be obvious but sometime you want to execute an action every frame an sometime you want to execute it every few milliseconds.

If things aren’t working make sure you’ve told your layer to schedule updates in it’s init method and make sure you are updating your timers from your layer 🙂

Categories
Cocos2d-iPhone Programming

Objective-C Memory Management For Newbies

Below you will find a list of memory management rules that will make your Coco2d game coding experience easier and your games less buggy. But before you dive in please read the caveats below:

  • These rules are based on several sources written by engineers with much more experienced than me in Objective-C and Cocos2D development. Any mistakes are my own, any good idea belong to them.
  • My sources include this tutorial by Ray Wenderlich and the comments by fufie. Ray’s tutorials should be read by every aspiring Coco2d-iPhone developer!
  • I also found this Stack Overflow question and answer on property declarations and this blog post on properties by CocoaCast really helpful as well.
  • Of course all this info is contained in Apple’s Memory Management Programming Guide in greater detail. RTFM, as they cheerfully remind us in IRC, is a great way to learn.
  • In many ways this blog post is just a briefing on all of the above material and my motivation for posting this info is just to have it all in once place and neatly summarized.
  • Finally, these rules are guidelines for inexperienced developers, not laws. Engineers who are experienced with Objective-C memory management and Cocos2d don’t need these rules and shouldn’t even bother to waste their time and read my post. Following these rules will keep newbies out of trouble with their first game or two.

10 rules that make memory management a breeze…

Rule #1: Always create properties for your ivars in your .h and synthesize them in your .m.

// in MyClass.h
@interface MyClass : NSObject {
@public NSString* _moniker;
}
@property (nonatomic, copy, readwrite) NSString* moniker;
@end

// in MyClass.m
@implementation MyClass
@synthesize moniker = _moniker;
@end

Rule #2: Use an underscore so the compiler can distinguish an ivar from a property with a common root name. When synthesizing remember to associate the ivar with the property. This way the compiler will yell at you if you try to set an ivar as if it were a property.

@synthesize moniker = _moniker; // ivar = property

Rule #3: Always access your internal properties through self using dot syntax to ensure proper memory management through property declarations.

self.moniker = @"Betty"; // the ivar _moniker now refers to a new copy of the string "Betty"

Note: In C, C++, and Objective-C the operand on the left must be an lvalue so you can’t chain assignments. Code like

self.rectangle.top = 10;

generates a compiler error.
Instead you have to unpack the object and assign it back to the property:

Rectangle* rect = self.rectangle;
rect.top = 10;
self.rectangle = rect;

Rule #4: Always provide an object factory class method to create an instance of your custom objects using autorelease for simple memory management.

+(id) getInstance {
	return [[[self alloc] init] autorelease];
}

Rule #5. When declaring a property for a basic type or for objects you don’t own use the assign attribute.

@interface MyClass : NSObject {
@public int  _counter;
@public NotYourObject* _notMyObject;
}
@property (nonatomic, assign, readwrite) int counter;
@property (nonatomic, assign, readwrite) notMyObject;
@end

Rule #6: When declaring a property for a subclass of NSObject use the retain attribute to retain the object on assignment and release the original object (if any) associated with the property.

@interface MyClass : NSObject {
@public Something*  _thing;
}
@property (nonatomic, retain, readwrite) Something*  thing;
@end

Rule #7: When declaring a property for an NSString use the copy attribute to create a copy on assignment and release the original string (if any) associated with the property. You probably want the assigned string and the original string to be two independent objects.

@interface MyClass : NSObject {
@public NSString*  _moniker;
}
@property (nonatomic, copy, readwrite) NSString* moniker;
@end

Rule #8: Use the autorelease to automatically release objects when you are done with them.

self.thing =  [[[SomeThing alloc] init] autorelease];

Rule #9: Apple API calls that begin with “init” or “copy” need to be managed by you and released when you’re done with them. You can use rule #8 to make releasing objects at the end of a method painless.

self.moniker = [NSString stringWithFormat:@"%@ number %i", @"Betty, 2]; // already autoreleased
self.moniker = [[NSString initWithFormat:@"%@ number %i", @"Betty, 3] autorelease]; // needs autorelease

Rule #10: Always use the nonatomic attribute when declaring properties unless you are working with multiple threads–and if you are working with multiple threads you are way above the level of these rules.

@property (nonatomic, assign, readwrite) int counter;

Rule #11: Always use the ivar in your delloc method to release objects you own and set them to nil (to ensure safe subclassing).

[_moniker release];
_moniker = nil;

A thought on static analysis…

Xcode’s Build and Analyze (Shift-Cmd-A) always drives me crazy with false positives. First, it finds potential issues with the Cocos2D framework source files and I’m not about to worry about or fix any of those. Second, all the issues it finds in my source files are either trivial non-issues (an assignment hidden inside an if-then-else block) or not problems at all (releasing object that it thinks I don’t own). But perhaps it’s my coding style that needs to improve. I hate letting warnings go by unresolved and as soon as figure out a way to write code the makes static analysis happy I’ll let you know.

Categories
Cocos2d-iPhone Programming

Cocos2d Tip #1: Changing a Sprite’s Image Simply

I’m writing an iPhone game using the Cocos2d-iPhone framework. It’s been smooth sailing except for one little detail: I want a sprite to change it’s image based on a touch.

I think the problem is that there are a dozen ways to do this in Cocos2d. I wanted to find the simplest way to do it. A quick Google search pointed me in the direction of CCAnimationCache and CCTextureCache.

CCAnimationCache is used for running multi-frame animations inside a single sprite. I only have 2 frames for my sprite! CCAnimationCache could do it but it’s a more power than I need to respond to a touch. (If you want to give animation a try check out Ray Wenderlich’s wonderful tutorial.)

CCTextureCache would have been the way to go if I hadn’t already used CCSpriteFrameCache to load all my sprite images at the start of my game. CCSpriteFrameCache uses a plist that divides up a large image into rectangle so you can pack all your sprite images into one memory saving “texture atlas.” And you can use Zwoptex to generate the image and the plist for you. CCTextureCache is the manual way to do what CCSpriteFrameCache and Zwoptex automates for you. (If you like to be hard core check out Ben’s post on optimizing texture loading.)

I figured there had to be a way to use my sprite frames in my existing cache without having to resort to manually loading textures or creating animations I didn’t need.

There was! It’s simple and here’s how to do it…

First, create your texture atlas with Zwoptex and add the .plist and .png files to your Resources folder in your Xcode project.

Second, load the texture atlas into the shared frame cache early in your game…

CCSpriteFrameCache* frameCache = [CCSpriteFrameCache sharedSpriteFrameCache];
[frameCache addSpriteFramesWithFile:@"textureAtlas.png"];

Third, create your sprite in your layer’s – init method…

// Note: niceSprite is a CSprint* instance variable so we can reuse it
niceSprite = [CCSprite spriteWithSpriteFrameName:@"initial_image.png"];
niceSprite.position = CGPointMake(240, 160);
[self addChild:niceSprite z:0 tag:0];

Fourth, in your – ccTouchBegan or – ccTouchesBegan method add the following code to change the image associated with your sprite…

CCSpriteFrameCache* frameCache = [CCSpriteFrameCache sharedSpriteFrameCache];
CCSpriteFrame* frame = [frameCache spriteFrameByName:@"new_image.png"];
[niceSprite setDisplayFrame:frame];

That was easy!

Categories
Tech Trends

I Bought A New MacBook Pro and Didn’t Pay an Arm and Leg!

Apple had a sale over the Thanksgiving weekend. The savings we’re exactly in Crazy Edie territory but $101 off a new MacBook Pro just about covers the tax (in NJ). My last MBP has been sitting in pieces on the bookshelf behind my desk at home. I bought it in 2008 and two years of daily commuting between NJ and NYC literally shook it apart. I used Apple’s sale as the thin, poorly veiled, excuse to buy a new MBP. The truth is I’m just addicted to shiny new computers and I had to feed the monster.

When it comes to buying a computer I have three criteria:

  1. Don’t buy something that will become obsolete in a quarter.
  2. Don’t buy less or more power than I need.
  3. Pay as little as possible while still buying something that won’t embarrass me in front on the cool kids.

When I met my wife she explained to me that you can tell a lot about a person by their shoes. A cool hip guy might walk around in an outfit from Target but the brand of his shoes will tell you if he is being ironic or a showoff or a cheapskate. In the 21st century you can apply the same criteria to computer laptops. Some guys (or gals) buy the most expensive luxury desktop replacement money can buy as if to say: “I’m bad!” Other guys buy the cheapest under powered plastic toy “puter” that buy.com has on sale as to say: “I make Scrooge McDuck look like Bill Gates! (The current Bill Gates not the earlier one who acted a lot like Scrooge McDuck before he got married.) Then there are understated nerds like me who try to say something nuanced with their laptops: “Yes it’s not the fastest, but we know that RAM and HD speed are more important than raw CPU speed for real world applications.”

After much research and discussion with my hardware otakus this is what I bought and why:

I bought a 15″ MacBook Pro with a 2.40 GHz Intel i5 core CPU with 320 GB hard disk and 4 GB of RAM. This is the least expensive 15″ model Apple sells at $1799. I asked Apple for one extra: A higher resolution LCD display (1680 x 1050 instead of 1440 x 900) at only $100 more. With the Apple sale I got the hires screen for free but at only $100 for 30% more pixels it’s a bargain–one of the few true steals to be found in the Apple Store.

The display resolution is why I bought the 15″ and not the 13″. More pixels means less scrolling and more productivity. But I could have bought the 17″ MBP with a whopping 1920 x 1200 screen resolution. But I’ve used the 17″ model before and it’s not really portable. As a hard core northeastern corridor commuter I need something that fits into a standard backpack, weighs less then a 3KG medicine ball, and actually fits on my lap in the crowded train car.

Apple has options for much more powerful (i7 core) and faster (2.8 GHz) CPUs. But while benchmark software will show you a 25% to 30% performance boost between the 2.40 GHz i5 and the 2.80 GHz i7 pure CPU speed isn’t the problem unless you’ve unclogged all the other performance bottlenecks in your laptop.

The the real roadblocks to a laptop snappiness are memory and storage speed and size. Modern operating systems accommodate today’s bloated software applications by organizing memory usage into “pages” and swapping these pages in and out of disk as needed. Adobe Photoshop is the exemplar: It can’t let you edit that 21.1 megapixel image without shuffling pages of memory around. Some operations, like filters, are CPU intensive, but most operations (reading, writing, zooming, scrolling, copying, pasting, …) are memory bound.

To lessen the bound of memory I ordered a 4 GB ram stick and a 7200 RPM 500 GB hard disk from a third party: Not Apple! Apple charges extraordinarily high prices for RAM and hard disk upgrades. To buff up my MBP would have cost an additional $550. The third party RAM and HD only cost me $154.31 and 1/2 hour to unscrew the back of the MBP and install everything. In the end I had a sweet new MBP with 6 GB of RAM and 1/2 a terabyte of storage. Photoshop is happy.

There is a risk that by upgrading you’re Mac you’ll ruin it and void the warrantee to boot. I alway get help from my hardware friends who show me how. There are also some good videos from MacSales that we’re really helpful. The voiding of the warrantee went from a definite yes to a maybe in the last few years. Apple reserves the right to blame your MacBook problems on you if you don’t use an authorized service provider.

For me, it was worth the Geek Cred to personally upgrade my MBP so I could have a great ice breaker at Starbucks:

“Oh, this that new MBP you got there?”

“Yes, but I haved $400 bucks by upgrading it myself and I got the hires screen for free on Black Friday.”

“OMG! 2G2BT! CSA!”

Categories
Agile Principles

The Three Laws of Agile Process

As early as 2007 Agile practitioners, or at least people who blog about Agile, began to observe that we live in a post-agile world. I’m not sure what means but Agile is a conversation about the best way to manage the software development process that has been going on for a long time. Has it been too long? What comes after Agile?

Eventually all wisdom becomes dogma.  Many engineers feel strongly that we’re already there with the process for process’ sake when the scrum master moves into the cubicle next door. Fair or unfair it’s a criticism needs to be explored. However nobody has put forth a process to succeed Agile–one that builds upon it’s strengths and shores up it’s weaknesses. At this point in the history of software development were we to abandon Agile we might as well go to ouija boards and seances to plan our projects.

So in truth, we make it up as we go along. That’s what most experienced scrum masters mean when they say they are flexible about adapting the processes of Agile to the culture and business needs of an organization. Poor Agile implementations are only a few second-guesses away from good ones.

Perhaps it’s time to take what we’ve learned in the 10 years since the framers of the Agile Manifesto met in Snowbird and create something that fits even better with the technological and business climate of the Mobile-Cloud-Long Tail-Social-Search Driven-Virtual world we log into every morning.

I’d like to start with the very first value of the Agile Manifesto:

Individuals and interactions over processes and tools

Do we still value people over process? Is it that simple? From this value the principles of customer satisfaction, working with business people, building projects around motivated individuals, face-to-face conversation, sustainable development, and team reflection are derived. Change this value and we change the equation for all of Agile. Do we weaken it? strengthen it? or replace it with something else?

Even with the unique challenges of developing software for servers you can’t touch and cell phones with fingerprints all over them we know what true process-for-process’ sake is like. We call that Waterfall but it was many more manifestations. It’s the paperwork you fill out in the emergency room and the electronic EULA you click “agree to” without ever reading.

So we have to keep it. In fact I would argue we have to make it much more imperative: A rule that is never broken which says it’s OK to break the rules!

I don’t mean we should give up our process at the drop of a hat (or the crash of a market). But we must give it up when our people will be rendered ineffectual. Issac Asimov’s Three Laws of Robotics can inspire us with a new rendering of what is, perhaps, the most important value of Agile:

  1. A process may not injure a team or, through inaction, allow a team to come to harm.
  2. A process must obey any orders given to it by a team, except where such orders would conflict with the First Law.
  3. A process must protect its own existence as long as such protection does not conflict with the First or Second Law.

If it will keep our robot overlords from killing us it will work for keeping an overzealous Agile process in check!

Categories
Programming

Turning Bold into Strong with Regex & NotePad++

I’ve been hand coding a site and I was a little lazy. Instead in using the strong tag to make text look bold I used the bold tag.

Ok, that might not be a big deal to you but to some HTML fanatics the difference between <b>Hi There</b> and <strong>Hi There</strong> is ground for excommunication from the cool kids club. Being lazing I figured the difference was not important enough to warrant me typing an extra 10 characters for each tag. But in the middle of the project I saw the light. (Modern browsers, text readers, and future things we have not invented yet will “do the right thing” with strong tags. Bold tags are just fossilized formatting.)

So now I had a bigger problem: How do I turn all those <b>’s and </b>’s into <strong>’s and </strong>’s? Of course regular expressions would work–if I could figure out the syntax. I mean, it’s been a long time and I always found regex to be the classical Latin of the programming world. Boring but important 🙂

To complicate things I am using NotePad++ to edit my hand hold HTML. NotePad++ is a great editor (and it’s free) but often does things it’s own way. It’s the Frank Sinatra of Window’s text editors.

To refresh my memory of regex syntax I found a great site, RegExr, that let’s you experiment with regular expressions until you beat them into submission. It’s written in Flex 3 and is a fine example of both a programmer’s tool and an Adobe rich media application.

After a bit of fooling around I discovered the pattern to capture a string inside a bold tag…

/<b>(.*)</b>/gim

and to replacement was

<strong>$1</strong>

This magic would not work if the bold tags had any attributes but I would have used an actual CSS style if I needed any more complexity than bold text.

Anyway this didn’t quite work with NotePad++. A little more digging (via Google and Stack Overflow not the NotePad++ help system) and I discovered that NotePad++ doesn’t need the regex switches and uses / instead of $ for captures. The working search and replace strings are…

<b>(.*)</b>
<strong>/1<strong>

Yey! Now I can continue to be lazy and fix it later!

Categories
Programming Tech Trends

Android SDK Compatibility with Eclipse and JDK

I recently switched my development workstation from a MacBook Pro to a Windows desktop PC. Yeah, I know, I’m going against the trends but it’s a sweet machine I assembled myself based on recommendations from Ash.

Immediately I ran into compatibility problems with Google’s Android SDK and the current versions of Eclipse (Helios) and the Java Developer Kit (JDK Version 6). In a nutshell Google’s cool Android dev tools don’t work with Helios–you need to install Eclipse 3.5 (Galileo). Galileo require’s JDK Version 5. All this info is prominently featured on the Android system reqs page–but who reads any more?

Digging up old versions of Eclipse is easy. You can find Galileo here.

Digging up old versions of the JDK is a bureaucratic nightmare. You can find JDK Version 5 here but to install it you have to fill out a form, give away PII, and then wait for an email.

One way around Sun Oracle’s walled garden is to install Open Office 3.2.1 which installs Java 1.6 (JDK Version 6) in such away that everything compiles.

Now that Google is throwing away all their Windows PC’s I’m sure this compatibility nonsense will get even worse. Here is a note from Google about enabling debugging of Android Phones:

If you develop on Mac OS X or Linux, you do not need a special driver to debug your application on an Android-powered device.

Damn it! I might have to go back to coding on the Mac and only using my PC for trival tasks like gaming and web browsing. Ironic huh?

Categories
Agile Principles

Communication Flavors

It’s not even funny how human networks and computer networks exhibit the same behaviors. I know we’re all patiently waiting for the singularity, for the event where computer networks become sentient and life as we know it changes forever. But given how the current example of networked sentient beings behave I fear that switching platforms (from organic to silicon) won’t improve anything. Collaborators will still compete, confuse, and confound each other, just at faster bit rates.

Dynamic network communication behavior is important to help us understand the 6th principle of the Agile Manifesto:

The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.

At first glance the idea that F2F (face-to-face a type of peer-to-peer) communication is the most efficient and effective method of communication is non-obvious. After all, if I want to tell something to many people a broadcast is much quicker than a pointcast. Implicit in the idea of F2F communication is talking. (I doubt the framers of the Agile Principles want us to pass notes to each other.)

It’s not immediately clear that talking (realtime streaming) it is much more effective than detailed written instructions (store and forward). F2F communication means lots of clarifications, and repetitions when words and whole sentences can be lost due to network noise or an inattentive client.

The problem is that we are comparing F2F and written instructions in terms of abstract efficiency outside of the time-bound world we live in. This is a common error. We tend to think of our priorities and tasks as critters that live in independent time-space bubbles. Thus we don’t take into account logistics, dependencies, and elapsed time when estimating how effective or efficient a flavor of communication is.

There are not 24 hours in a work day. Really there are 4. The other 20 are taken up with sleeping, eating, commuting, and status meetings. That leaves 4 uninterrupted hours for work. Imagine if you baked this idea into your communications habit. You don’t have the time waste on writing or reading long, detailed emails and wiki posts. You need a communication strategy where you can cut to the important stuff. That means finding the right co-worker (peer) and talking to them directly.

A true co-worker is someone who knows you’re strengths and weaknesses, knows when you are joking, respects you, and doesn’t want to you see fail. Unfortunately, even if you have super social skills, you can only manage 5-7 relationships like those at a time, and most of these are with your family members. Most of the people you are working with either just don’t know you very well to be able to parse your text get the message without errors. You can’t simply write a detailed enough specification or requirements document to get though the noise.

Given the shortage of time and deep relationships you have to talk to co-workers F2F. You have to interrupt and be interrupted. What seems like a slow process, like a four hour F2F planning meeting, is actually much more efficient than a  100 page document.

Categories
Agile Principles Management & Leadership

Volunteer Scrum Master Handbook

I have to disclose upfront that I am more of an Agile guy than a Scrum guy. Which is to say I feel more at home discussing Agile in general than Scrum in particular. (I’m not even sure how to capitalize it–SCRUM or scrum?)

Over the years I’ve made my peace with Scrum and as I dig into it’s theory and history I find I have few real arguments with the brainchild of Schwaber and Sutherland. My arguments are not with Scrum but with Professional Scrum Masters.

Over past 19 years that Agile/Scrum have reshaped the process of software development many of the traditional roles of software engineering have drastically changed or simply gone away. Technical Writers, Business Analysts, and non-coding Development Managers aren’t needed much by self-organizing teams that talk directly to Product Owners and write up their backlogs on sticky notes. But the one big role that Agile/Scrum has made obsolete is the hard nosed, battle tested, two fisted, lock jawed, steely eyed, organization shaking, cat herding Project Manager.

Back in the day it was the Project Manager who got things done. The good engineers were taught to be sheep and good senior managers were turned into putty by the power of the Project Manager. Microsoft’s variety of Project Manager, the TPM, is still a legend in the industry. It was Windows Vista epic failure and not Agile/Scrum that finally dethroned the TPM.

So when an organization finally buys in to Agile/Scrum where do the people who filled the roles of the waterfall process go? Product Managers became Product Owners. Development Managers who could code became team members or even team leads. Spec writers and Business Analysts moved on. Often Project Manager became Scrum Masters–If the non-coding Dev Managers didn’t beat them to it first.

It is where I got my first bad taste of Scrum: Project Managers turned Scrum Masters who were still doing Project Management. These pseudo-Scrum Masters were the ones with the Microsoft Project plans detailing every sprint from here to release. They demanded status explained in non-technical terms during the daily standup. They stuffed the sprint backlog too tightly (or sandbagged it) and argued with Product Owners over priority. What a mess! It was all Bagile and Fragile.

At least with the non-coding Dev Managers who become Scrum Masters the social graces were respected and they generally stayed out of the way (lest a technical question come their way).

To combat the pseudo-Scrum Master I like to use the role of the Volunteer Scrum Master (VSM). This is just one of the team members (either a coder or a tester) who plays the role of part time Scrum Master. It’s a volunteer and rotating position which can be filled by anybody but the Product Owner. Most of the time the VSM writes code or tests. When the need arises the VSM laces up his boots and does Scrum Master things: Calls for help to scare away any chickens, reminds everyone to follow the process, and let’s me or the full time Scrum Master know that those servers need to be updated by Ops. The VMS removes impediments to the success of the sprint by communication not coercion.

It’s not a glamourous job. There’s no extra pay. There is no authority. You don’t get to wear a uniform or the keys to the executive washroom.

While the job of a VSM is simple and straight forward it can be hard for a new recruit to know where the Scrum Master job starts and ends. So I ask each VSM to think of his part time job as a journalistic one. Observe what is going in the scrum. Take notes. Report findings to the full time Scrum Master or one of the Engineering Directors.

Note: Team members should be responsible for managing themselves. A Scrum Master is not Mom or Dad or a Police Officer. The best way to remove impediments is to communicate them to someone who can address them.

Let’s review how the VCM fits into the role of the Scrum Master…

Responsibility Pro Scrum Master Volunteer Scrum Master
The Scrum Master is not the leader of the team In Theory Yes
The Scrum Master teaches the process Yes Has to learn it first
The Scrum Master has no authority and may not make commitments That’s idea but… Definitely yes
The Scrum Master surrenders control to the Product Owner Hopefully 100% Yes
The Scrum Master is an enforcer of rules Sure Nope
The Scrum Master sets up the meetings If she has time Nah, set up your own meetings!
The Scrum Master maintains the backlog and updates the Scrum board Busy work All team members should pitch in
The Scrum Master explains to management what the team is doing Bad idea (It’s the Product Owner’s Job!) Wouldn’t bother
The Scrum Master acts as a buffer When there is no other option Dials 911

As you can see the Pro Scrum Master has to be careful. As the Scrum canon defines her job there is some inherent contradiction with the job of Product Owner and even some chicken-like (i.e., management) responsibilities. The VMS has no such ambiguities. He’s just passing through–his sense of self-worth isn’t caught up with the role.

Using VSM enables an organization to limit the number of Pro Scrum Masters, minimize political struggle, and help the team members learn the game of Scrum (the best way to learn is to volunteer).

Here are some sources that help define a Scrum Master’s Role:
Categories
Agile Principles

Agile Fables

I love a good fable. The kind that Aesop used to write with animals acting out human morality tales. Of course, if you do the research, you quickly find out that Aesop didn’t write most (if any of the fables) we ascribe to him and like Shakespeare he probably never existed. I don’t let reality like that spoil my appreciation for Aesop’s work.

For Scrum Masters, Project Managers, and fans of Getting Things Done there is nothing like the fable of the Tortoise and the Hare. The slower, but diligent tortoise wins the race over the quicker, but arrogant hare. The only problem Agile process lovers have with this fable is that it’s not true! The tortoise (Waterfall) always loses to the Hare (Agile).

But we have a paradox: Most chickens (managers, stakeholders, investors) and even some pigs (engineers) agree with Aesop! The tortoise always beats the hare because the tortoise makes a plan and executes it well, even if he is a bit slow. (If the tortoise fails it’s because a chicken yells at her to hurry up and so she speeds up and screws up. Call it the “Fable of the Spineless Tortoise and Impatient Chicken.”)

To resolve this paradox I’d like to tell the “Fable of the Tortoise, Hare, and Monkey.”

A Hare one day ridiculed the Microsoft Project plans and change control documents of the Tortoise. The latter, laughing, said: “Though you be swift as Google Go, I will beat you in a race to deliver working software.” The Hare, deeming her assertion to be simply impossible, assented to the proposal; and they agreed that the Fox (VP of Product Management) should choose the requirements, and define the release. On the day appointed for the race they started together. The Tortoise never for a moment stopped, but went on with a slow but steady build cycle straight to the end of the course. The Hare, trusting to his native widgets, cared little about unit testing and user feedback, and lying down under his desk after long night of coding, fell fast asleep. At last waking up, and logging on as fast as he could, he saw the Tortoise had reached the goal, and was demoing to the Fox.

But the story doesn’t end yet…

By the time the Hare caught up with the Tortoise and the Fox he saw the Tortoise slam her laptop shut and slump away. The Hare asked for an explanation. “Why didn’t he Tortoise win?” The Fox explained that what the Tortoise delivered was very late to market and the requirements were were out of date. “But,” the Fox said, “Happily for all, the Monkey has delivered working working software that meets most of our customer’s high priority needs!”

“Monkey? Where the hell did the Monkey come from?” Exclaimed Hare.

“Ah yes,” sighed the Fox, “While you were crashed out under your desk, the Monkey came and delivered a working prototype. I told her that it wasn’t quite right so the Monkey went away and came back a little while later with a revised prototype. It took a few tries but eventually the Monkey got it right and won the race. In fact the Monkey’s working prototypes helped me understand what I was asking for. You see when I gave the requirements to you and the Tortoise, there were a few stories I missed and during the race a new competitor entered the market. Even if you hadn’t fallen asleep you would not have won as I had to keep moving the goal. Our customer, Mr. Zeno, is a hard man to please!

Just in case you’re not into reading between the lines here’s my analysis of this fable (since I wrote it my analysis should hopefully be accurate).

The Hare lost the race because he had to fight the Law of the Handicap of a Head Start. This principle states that pioneers and innovators lack a clear signal. They are out in front, they have no one to follow, and so their advantage becomes a handicap. Often the first movers are stuck building their software on immature technology that becomes obsolete before it is finished. The United States has this problem with its Internet and telecommunications infrastructure. We got there first but now we are lagging in connectivity. The Hare development process, starts out fast and light but never stops to get feedback–its one big long sprint. A lot of code is written. Little of it is ever used.

The Tortoise lost the race because we no longer live in the world of the 4th century BC. Slow and steady hasn’t been a winning strategy for a long time. The goal keeps moving. Actually the ancient Greek philosopher Zeno wrote his own fable where he counters Aesop. In Achilles and the Tortoise, the Hare-like Achilles can’t catch up to the Tortoise (who has been given a head start) because every time Achilles reaches the spot where the Tortoise was, the Tortoise has moved on. This is the problem of accomplishing an infinite number of tasks in a finite amount of time. Somehow we do it every day (but if you really think about it your brain hurts). The Tortoise development process, creates dichotomies every step of the way: Design, Development, Test, Release, Post Release, et etc. Dichotomies are full of infinite regressions and thus are never finished.

The Monkey won the race because he used an Agile development process. First the Monkey took a prioritized subset of from the list of infinite tasks (and every project has a never ending number of bugs and feature requests) and delivered them to the Fox (Product owner) as working software. It was was rough but the Fox had the results in plenty of time to give feedback and course corrections. Thus the Monkey was not subject to the Law of the Handicap of a Head Start. Second the Monkey kept repeating these short sprints of implementing the high priority tasks and getting feedback on a real working system so that as the goal moved she could quickly change course. The Monkey development process, done right, treats every sprint as a whole, where no dichotomies are created. The software is released to the user, it does what it does, feedback is gathered, and the process is repeated until a winner is declared.