Scriptogram?

Hello! This is my first blog post, hosted by Scriptogram. Let's see how it goes!

:)

Scriptogram?

Hello! This is my first blog post, hosted by Scriptogram. Let's see how it goes!

:)

Someone recently asked how programmers and designers might communicate daily impediments if the programmers feel the designers either can't understand their impediments nor contribute to their solution.  
Designers aren't usually going to jump in and suggest a code fix, but if the programmers feel that the impediments are mainly code issues, I sense another potential problem.
The greatest challenge in making games is "finding the fun": exploring mechanics and isolating the core gameplay that will draw players.  This creates daily challenges of "how to get there".  When the primary challenge becomes how to write the best architecture or how to create the most optimized physics, then the focus is on the plan, not the game.
David Jaffe said something during the last IGDA Leader Forum that stuck with me.  He said that when developing Twisted Metal, they didn't create vehicle physics.  They created a player object that acted like a hockey puck and then pasted some vehicle models in.  Their focus was on creating the gameplay and let the player fill in the "fantasy of driving a vehicle".  
Our arcade racing games always suffered from a tug-of-war between the vehicle simulation physics and gameplay.  We should have let gameplay lead the vision.  This doesn't mean that designers have the only important work.  It means that every discipline is focused on delivering core value.  Design asks the questions and the entire team seeks the answer….daily.  Seeking those answers should create frequent, meaningful conversation.  If it doesn't, I suspect the team is answering the wrong questions.

Even after all these years, I take too-big steps while coding. In less finicky languages (or finicky languages with good tool support), I can get away with it, but I can’t do that in C++ (a language I’ve been working in the past two weeks). So I’ve had to think more explicitly about taking baby steps. And that’s made me realize that there must be some refactoring literature out there that I’ve overlooked or forgotten. That literature would talk about composing small-scale refactorings into medium-scale changes. The only example I can think of is Joshua Kerievsky’s Refactoring to Patterns. I like that book a lot, but it’s about certain types of medium-scale refactorings (those that result in classic design patterns), and there are other, more mundane sorts.

Let me give an example. This past Friday, I was pairing with Edward Monical-Vuylsteke on what amounts to a desktop GUI app. Call the class in question Controller, as it’s roughly a Controller in the Model-View-Controller pattern. Part of what Controller did was observe what I’ll call a ValueTweaker UI widget. When the user asked for a change to the value (that is, tweaked some bit of UI), the Controller would observe that, cogitate about it a bit, and then perhaps tell an object deeper in the system to make the corresponding change in some hardware somewhere.

That was the state of things at the end of Story A. Story B called for two UI widgets that would be about changing two hardware values (with the code to change story B’s hardware wildly different from that used in story A). The change from “one” to “two” was a pretty strong hint that the Controller should be split into three objects of two classes:

• A ValueController that handles only the task of mediating between a ValueTweaker on the UI and the hardware value described in story A.

• A new ValueController that does the same job for story B’s new value. The difference between the two ValueControllers isn’t in their code but in which lower-level objects they were connected to.

• A Controller that does whatever else the original Controller did.

The question is: how to split one class into two? The way we did it was to follow these steps (if I remember right):

1. Create an empty ValueController class with an empty ValueController test suite. Have Controller be its subclass. All the Controller tests still pass.

2. One by one, move the Controller tests that are about controlling values up into the ValueController test suite. Move the code to make them pass.

3. When that’s done, we still have a Controller object that does everything it used to do. We also have an end-to-end test that checks that a tweak of the UI propagates down into the system to make a change and also propagates back up to the UI to acknowledge that the change happened.

4. Change the end-to-end test so that it no longer refers to Controller but only to ValueController.

5. Change the object that wires up this whole subsystem so that it (1) creates both a Controller and ValueController object, (2) connects the ValueController to the ValueTweaker and to the appropriate object down in the hardware, and (3) continues to connect the Controller to the objects that don’t have anything to do with changing the tweakable value. Confirm (manually) that both tweaking and the remaining Controller end-to-end behaviors work.

6. Since it no longer uses its superclass’s behavior, change Controller so that it’s no longer a subclass of ValueController.

7. Change the wire-up-the-whole-subsystem object so that it makes two ValueControllers, not just one. Confirm manually.

I consider that a medium-scale refactoring. It’s not something that even a smart IDE can do for you in one safe step, but it’s still something that (even in C++!) can easily be finished in less than an afternoon.

So: where are such medium-scale refactorings documented?

You can drive your week or your week drives you.   One of the ways I add sanity to the chaos of my week is the Monday Vision, Daily Outcomes, Friday Reflection pattern.   It’s a simple way to setup a rhythm of results for the week.

Monday Vision – Three Wins for the Week
On Sundays or Mondays, I identify three wins I want for the week.   For example:

1. Alignment on approach X across the four teams.
2. A baseline information architecture for “fast-pathing” cloud architecture.
3. A usable prototype for cloud strategy “on a page.”

Power Hours for Exponential Results
Some of the work requires “heavy lifting” in terms of extreme concentration and focus.   To do that well, I make sure that I allocate some of my “Power Hours” to these problems.   This will help me take cover more ground in a better, faster, and simpler way.  For me, my best hours tend to be 8am, 10am, 2pm, and 4pm.   I’ll use these to move the big rocks each day, or at least chip away at the stone.

When I make the mistake of working on a tough problem during a non-power hour, I end up wasting time, unless it’s exploration and creative work.   If I need to make significant progress, my single best move is to use my Power Hours.   That’s how I do ten hours of work, within a single hour.   It’s me at my best.  It’s firing on all cylinders.  I can do mental sprints during those hours, and deal with the worst setbacks, and still make the most ground.

Stories to Light Up Meaningful Work
I use simple, “one-liner” stories to make my goals or tasks more meaningful.  I try to connect my goals back to my values.   For example, I value customer impact, so instead of “call a customer”, I “win a raving fan.”   I also value adventure, so instead of just driving my project, I’m “leading an epic adventure.”   It takes practice to frame work in terms of more meaningful achievements, but the key thing to remember is …

You are always the most important meaning-maker in your life.

The story is in the change.   You are the actor.   That’s the empowering part.   Whether it’s achieving a private victory, or making great things happen in your world of work, it’s about inspiring yourself with skill.  You do that by connecting what you do to your values, and making a story out of it.   This also helps when you have to tell and sell the value of what you do, and for yourself when you need to recap what’s going well.

Daily Outcomes – Three Wins for the Day
Each day, one of the best things you can do is write down three wins you want to achieve.   It’s not activities.  It’s outcomes.   Focus on the end-in-mind, and you can use these three outcomes to help prioritize and focus throughout your day.  This is the best way that I turn laundry lists and end-less “To-Do” lists into more focused results.   It helps me deal with information overload and task-overwhelm.   It’s a very simple way to step back and see the forest for the trees, at least for the day.  

When you combine the idea of three wins for your day with three wins for your week, you can easily zoom in and out to keep perspective.   When you need to focus on what’s in front of you, zoom into your day and focus on your immediate win.  When you need a little more perspective, step back, and look at the wins you want for your day.   When you need even more of a balcony view, simply step back and look at the three wins for your week.

Friday Reflection – Three Things Going Well, Three Things to Improve
On Friday, simply carve out an appointment with yourself, and ask the tough questions.   Ask the questions that will help you bring out your best.   Ask the questions that will help you continuously improve and take your game to the next level.   To do this, simply ask:

1. What are three things going well?
2. What are three things to improve?

They are simple, but revealing questions.   This gives you a chance to celebrate your wins.   It gives you a chance to formally acknowledge what’s going well.    Maybe things aren’t going the way you want them, but congratulations for making the effort and taking the steps, and doing the tough stuff.   Catch yourself doing something right.   This is how you build momentum and carry the good forward.

When you ask yourself what are three things to improve, use this as a chance to really identify some actionable things you can do to make things better.   You can think of big changes, but I think little ones work just fine, if you actually do them.   The beauty is, you can use all next week to try out your little changes.  Each day is a new chance at bat.   Repetition and practice are the best ways to improve.

If you follow this recipe for results, each week you should notice that you improve your focus, you achieve more wins, and you get better results.   Another way to put it is, this recipe will help you spend the right time, on the right things, the right way, with the right energy.  

And that is how you flourish, while flowing value, and achieving meaningful results.

Additional Resources

• Getting Results the Agile Way – Kindle Edition (Amazon)
• Design Your Week (Getting Results.com)
• Time Management Checklist

My Related Posts

• Ability to Execute
• Agile Results with Evernote
• Time Management Best-Seller on Amazon – Getting Results the Agile Way

A twitter conversation between Zee Spencer and Ron Jeffries makes me think I’ve never written down my two-phase approach to release planning.

Phase 1: Someone wants something. They have a problem to be solved by a software system. There are probably a few key features that are needed, perhaps buried in a mass of requirements that pretend to more authority than they’ll turn out to have. If the key features aren’t delivered, the system isn’t worth having. (Or the new release of an existing system isn’t worth having - it doesn’t matter.)

The person who wants the system (or wants to sell it) might have a release date in mind. It might be based on real constraints, like the beginning of a school year or the Christmas sales season. Or it might be arbitrary. Doesn’t matter to me.

At this point, the development team’s job is to answer the question: can this team produce a respectable implementation of that system by that date?

“Respectable” is a somewhat tricky idea. One conceptually easy part of it is “provides the key features”. Another is, embarrassingly, fuzzier: more about whether something can be provided that feels like a “whole” rather than a collection of parts. This is the kind of thing that Jeff Patton’s story mapping is about. It also includes Jeff’s idea of the distinction between incremental development (where you develop by bolting on features one at a time) and iterative development (where you get something complete-for-some-real-purpose done quickly but crudely, then add flesh to the walking skeleton.)

The answer to the “can it be done by that date?” question is going to be something of a leap of faith. The estimate that “we can do that by then” isn’t going to be as reliable as, say, the use of yesterday’s weather in iteration planning.

One way to get a better answer is to just go ahead and start the project. As Cem Kaner has said, you know less about the project right now than you ever will again. Spend a month building the product, then ask: can it be built by the desired date? You’ll get a much better answer. [Note: I’d favor really starting to build the project, just as if you’d made a two-year commitment, rather than doing some pilot study. I’d be suspicious that a pilot study would ignore a lot of the grinding details that take up a lot of project time.] The risk here, though, is that an answer of “well, it turns out we won’t be able to do it” will be unacceptable.

(Whether estimating at the beginning or after a month, I’d personally err on the conservative side because my experience is (1) the development team is more likely to be optimistic than pessimistic, and (2) I favor pleasant surprises - “We can do more! Or release sooner!” - over unpleasant ones.)

Phase 2: At this point, there’s a commitment: a respectable product will be released on a particular date. Now those paying for the product have to accept a brute fact: they will not know, until close to that date, just what that product will look like (its feature list). What they do know is that it will be the best product this development team can produce by that date. It’ll be the best product because the team commits to being flexible enough to put features into the product in any order. Therefore, the most valuable features can go in first, then the less valuable ones, then…

So, in this phase, you can stop worrying about anything but the near horizon. For much of the project, all that’s required is occasional stock-taking. (”Do we still think we’ll have a respectable product by the release date?”) Toward the end, there might be some need to predict more precisely than “best possible, given this team and that date”. Not everything that needs to be done before release might be as changeable as the code. (It’s harder to un-train a salesperson than to turn off the code for a feature that won’t be done in time.) But you’ll be in a good position to make good predictions by then.

——–

My success selling this approach has been mixed. People really like the feeling of certainty, even if it’s based on nothing more than a grand collective pretending.

I recently had a revelation about the Title “Scrum Master” and why it seems to be so confusing in some companies, especially those that are moving from Command and Control to an Agile Environment.

I was observing the activities of a new team that did not have a Scrum Master but were trying to use the SCRUM Framework. The company had unfortunately not added this role in their new SCRUM team(s). The reasons why are not important. Let’s just say, they now have those roles.

When the Scrum Master was selected, some issues showed up over a perception of that person getting a “promotion” to a management type position. They were now the “Master of the Team” (or so the perception was).

I managed to help that team out by simply reminding them the intention is that the Scrum Master role is as a Master of SCRUM, not a Master of the Team.

There are some management type abilities to be a Scrum Master for sure, but they are more directed to interfacing with the outside world and removing obstacles for the team. There are some management skills required to be able to have the confidence to keep the rules of Scrum and push back and deal with different levels within the organization.

Remember, the word is SCRUM Master, not TEAM Master, Team lead, Project manager, etc.

Of course, changing the order of the words would be inappropriate, but perhaps explaining the distinction to others might help clear up some of the confusion for your teams.

The term is SCRUM Master

Mike Caspar

Stories in Pivotal Tracker have been given a serious upgrade. For the most part it’s all pretty self explanatory - the functionality you’re used to is all there, just in a format that’s more intuitive, user friendly and hopefully you’ll agree, more appealing. Our advice, play with it and then come back and read the rest of this post, especially if anything is confusing.

You’re back, so let’s continue!

One of the goals of Tracker has always been to make collaboration around your story backlog as easy as possible, so that your team spends less time managing your project and more of it actually building things. We think there’s room to make that not just easier, but more enjoyable, even fun! So to that end, great usability and user experience are major themes in our backlog for 2012, starting with this story redesign.

See below for all the highlights.

New Look and Feel

Like we said, stories look different, and are hopefully a lot easier to work with now. It's a complete redesign, with a color scheme that fits better with the rest of the Tracker UI, and that's intended to make the important information in a story stand out more - such as the story title, description, comments, code commits, and file attachments.

Besides visual appeal, we’re aiming to reduce clicks - for example, when creating a new story, it only takes one click to choose a story type or point estimate value. And, you can now start, finish, deliver, or accept/reject an expanded story with one click, with the familiar buttons.

Click to Copy ID and Story URL

We heard your feedback about having to scroll down in stories to find their IDs, to copy them to your commit messages (you are using the source commit integration, right?). So, we've moved the ID to the top of stories, and made it so that you can copy the ID to the clipboard with one click (on the ID button).

The same is true for the story URL, for when you need to send someone a link to the story. Just click the link button in the top left corner, and the story's full URL will be copied to the clipboard. Note - you’ll need Flash enabled in your browser for these to work. If you don’t have Flash, you’ll see the full URL on a separate line, so you can copy it the old way.

Less commonly used actions, including delete and view history, have been moved to the “More” menu, which is where we’ll be adding some other convenience actions soon.

File Attachments on Comments

One big change in this redesign is that files are now attached to stories as part of posting a comment, rather than as a separate list. This is because files are commonly uploaded and shared in the context of an on-going conversation, and it’s so much easier to refer to a file that’s actually part of that comment (e.g. “Here’s that icon”) rather than having to say “see the file named foo.gif at the bottom of the story”.

You can still drag and drop files from your desktop to stories, and entering an actual comment when adding files is optional - just drop your files on a story and close it.

View All Images and Comment Filtering

The truth is, thumbnails of mockups attached to a story can be indistinguishable from one another. Sometimes you just need to see them all full sized, on one page. Now, with just one click of the View All Images link above the Activity section, you can.

We’ve also made it easier to find what you need in a long-winded (all of it beautifully clear and vital) comment conversation - just use the filter dropdown menu at the top right of the Activity section to show just file attachments, just source commits, or all comments without commits.

Feedback

This redesign of stories is the first step in an on-going usability overhaul. We’ve got much more coming over the course of this year, but we’d like to incorporate your feedback at every step, so please let us know what you think so far, in the comments here or by email to tracker@pivotallabs.com.

When talking about motivation, many people will reference Drive with its three key factors:

• Autonomy
• Mastery
• Purpose

One of the main sources that Dan Pink used for Drive is self-determination theory, which also points to three key factors for human motivation:

• Autonomy
• Competence (which is perhaps not as trendy sounding as Mastery)
• Relatedness

Note the difference with the last factor.  Dan Pink used "Purpose" while self-determination theory has "Relatedness".
Imagine you're in a job.  You have very broad autonomy.  You are very good at the job and are constantly getting better at it.  The job contributes to a grand purpose to do good in the world.  However, you don't identify with anyone at work, you end up mostly working on your own because every interaction with others reminds you how disconnected and uncaring your workplace is.
Imagine you're in another job.  Again, you have very broad autonomy and you are very competent and getting better at the job.  This time, you feel very connected with your work colleagues and generally feel a strong sense of mutual caring.  However, if you really think about it, the purpose of your work is really nothing special.
Which job feels more motivating? Which job do we think will be more motivating for most people?

The following two pictures depict the latest Inception I participated at.

A little bit of history: For the past two years I have participated directly in 3 Inceptions, and indirectly in 5 inceptions. By directly, I mean, I was sitting in the war room for most of the Inception sessions. And by indirectly, I mean, I was participating on the Inception sessions over video from a Nearshore location (onshore is San Francisoc, USA, nearshore is Porto Alegre, Brazil).

I attribute the success of the last Agile Inception to 3 things: collocation, war room, and colorful post-it.

Collocation

Don’t under estimate the value of a face to face interaction. I am currently in Brazil and I am used to having effective meetings over video and phone with USA. I know that technology can bring people closer together, and, perhaps, we can work together without sitting next to each other. However, the face to face during Inception will bring the team together in a way that it will be worth each penny spend for making the collocated Inception a reality.

I compare it to dating and internet dating. Relationship development goes to another level when the whole team is at the same room. Think creatively on how to save on costs. In our case we were able to reduce the collocated period by having a pre-Inception period before the collocate Inception. Spikes, research, data gathering, codebase analysis were the sort of activities we did in the pre-Inception week.

War room

Keep a single room for the team during the intense Inception period: the war room! The room should fit all team comfortably. It must have a clean table and wall space. The room should also have a cabinet or a box with index cards, colorful post-its and pen.

The war room makes the environment for collaborative sessions. It also avoids the waste of time of people moving from one room to another. Another important point is about carrying the information between rooms. You can either carry all hand-written notes (index cards, post-its, flip-charts, etc) and put them back in the wall and tables, or upload them on a digital format and carry it on your laptop. The former option is a waste of time. The later lessens people interaction. There is no replacement for writing on and tearing apart colorful post-it or index cards. Once the information goes to the computer, it will not get back to paper. People interaction reduces as there is nothing on the table to gather around.

colorful post-its

Do not bring a list of existing user stories to the Inception. I am sure there is a list somewhere (excel, Jira, or alike). Use it for reference, but don’t use it for driving the Inception sessions. Print a few copies and bring them to the war room. Let people consume it if required. Try not to read items from a list during a collaborative session. In fact, do not build a list while in a collaborative session.

Group people around colorful post-its. Write and place post-its either on the table or at the wall.. Talk about them. Write a few more. Tear them apart. Make use of colors. Reorganize it. The collaboration from using such basic, low-fi technology— colorful post-its and pen—cannot be matched by any digital alternative (file sharing, projector, spreadsheets, etc).

The picture below depicts a great example from my last Inception. Without a previous encoding, the team decided to use the colored small post-its for personas. User Stories (in green post-its) were placed on white index cards containing numbers and estimated (with notes on the back).

On future posts: user story mapping for driving Inception, and a few notes on Inception facilitation

You ever wonder why your cellphone Apps seem like they have a new version every day or two? Dan Greening doesn't have to wonder, he knows why, they make better products, faster. - jj


Short release duration—the time from starting development on a feature set until it is tested for value, for example when customers pay for an upgrade—is an implied goal of agile methods and lean product management. Short release durations help companies test market theories to maximize profit, identify and mitigate deployment and usability problems, exercise the entire value chain of internal processes, and diagnose accumulating technical debt.


Attempting to reduce release duration may help drive agile behavior through a company. Shorter release durations motivate automated testing, high-availability architectures and streamlined configuration and deployment.


As an added bonus, release duration can be easy to compute: Finance departments often collect relevant data to satisfy capitalization and depreciation rules.
Citrix Online release duration history


After Citrix Online adopted Scrum [suth2011] and Enterprise Scrum [gree2010], release duration dropped from an average of over 35 months to less than 4 months, better than what it had as a small startup. Its market share rose during the same period. Data from another company, PatientKeeper, also seems to indicate that short release durations correlate with more profitable outcomes.


On February 7, 2012 at 11:00am EST, Scrum.org will host a webcast where I will explain how to measure release duration, how different forms of technical debt cause release duration to increase, and how limiting release duration can motivate paying down technical debt. Click here to register for the webcast.


On February 27 and 28th, 2012 in Los Angeles, Jeff Sutherland, Scott Downey and I will be teaching techniques to help you achieve similar outcomes, at our Certified ScrumMaster course in Los Angeles, . Click here to register for the Certified ScrumMaster course.


Dan Greening is an agile management consultant, specializing in enterprise-level agility, lean product management and finance. Dan joined Citrix Online in 2007, and became its Director of Engineering Productivity and User Experience from 2008 to 2011. He developed an agile portfolio management process. Dan co-founded several startups. He has been Principal Investigator on three National Science Foundation SBIR grants. He holds a Ph.D. in computer science from UCLA. Dan can be reached at dan@greening.org.


References

[gree2010]

Daniel Greening, “Enterprise Scrum: Scaling Scrum to the Enterprise Level,” 2010 43rd Hawaii International Conference on System Sciences (HICSS), Koloa, Kauai, Hawaii January 5-8, ISBN: 978-0-7695-3869-3 (10 pages)

[suth2011]

Jeffrey V Sutherland, D. M. van Solingen and Eelco Rustenberg, The Power of Scrum, CreateSpace (2011), ISBN 978-1463578060.

It’s 2012, everyone is back in the groove after December holidays, so it’s time to get the circles going again. We will be kicking off on Monday 13 February, atLots are people are asking me about coaching circles. How was the retro, when are they starting up again, can they join, etc. I though it might be time for a post.

Retrospective

Last year ended with a great retrospective on the final round of coaching circles, facilitated by Cara Turner. This was the first round of circles where we split into 3 types: mentoring, coaching and dojo. It seems the end result was very positive. People loved the new circle types! See the photo’s below for the outcomes of the retro.

 

 

 

First we made some posters about the sessions.

 

 

 

 

 

 

Then we talked about things we didn’t like (burnt toast), things we loved (ice cream) and things we’d like to try (experiments)

 

 

 

 

 

 

 

 

In the end we had some suggestions and next steps actions

 

Onwards and upwards

It’s 2012, everyone is back in the groove after December holidays, so it’s time to get the circles going again. We will be kicking off on Monday 13 February, at 6pm. Please signup if you will attend. If you are keen to join a circle or even just find out more about them to decide if they are right for you, then make sure you get yourself to the kickoff. As always those who can’t attend the kickoff may still join circles by adding their details to the coaching circles google doc. However please note, those at the kickoff get first preference for circles of their choosing. Also for newbie, it’s highly recommended you come to the kick off to get an idea of what’s involved and how it works. Remember we will need hosts who can offer venues, signup in the google doc if you can offer one.

Signup for the kickoff here!

 

In working with a client recently, we ran in to a rather sticky situation. We were setting up a route to “persons/:id”, and as you would expect, we wanted to load the person in question and display the details of that person. The trick, though, is that we needed to wait until the persons collection was loaded to be able to retrieve the person from the collection. If we navigate to this route from somewhere else in the application, this isn’t an issue. The persons collection was already loaded and everything goes on normally. If we use a bookmark to get to this url directly, though, then there was no guarantee that the persons collection was loaded because we had not previously run any code to load the collection.

Depending on how the application is architected, and when the persons collection is expected to be loaded, there are a few options that I can see for solving this problem.

Option: Fetch The Model From The Server

The most basic option, and probably the easiest to deal with, is just to fetch the model from the server based on the id parameter that you get from the route.

In this case you just need to create a new model instance, set the `id` attribute on the model directly and then call `.fetch` on the model. It will make the trip to the server to get the data. You can either listen to a “change” event on the model or provide a “success” callback in the fetch method, to know when the data has been returned so that you can load it in to your view and display it as needed.

personById: function(id){  var person = new Person();  person.id = id;  person.fetch({    success: function(model, response){      App.showPerson(model);    }  })}

view raw 1.js This Gist brought to you by GitHub.

The major problem here is that you have not loaded the persons collection at all. If the persons collection is expected to be loaded because it’s being used for something related to displaying or working with the individual person model, then this option might not work for you. You could run some additional code to load the collection separately (asynchronously, since it works that way by default). This might help get around any potential issues of needing the collection.

Option: Use The Collection’s “reset” Event

Another easy option may be to load the collection when the request for the route is made. You would set up a new collection instance, bind a callback function to the collection’s “reset” event, and then call `.fetch` on the collection. The callback method would be responsible for retrieving the specific model from the collection and then creating and displaying the view.

personById: function(id){  var persons = new PersonCollection();
  // note that "bind" is now "on" in Backbone v0.9.x  persons.on("reset", function(collection, response){    var person = collection.get(id);    App.showPerson(person);  });}

view raw 2.js This Gist brought to you by GitHub.

There are some potential issues with this solution, though. If you already have the persons collection loaded, then you’re going to load it a second time just to get the one model from it. To mitigate this problem, you would need two different entry points in to the display of the person: one for when you hit the route directly through a bookmark, and one for when the user is already in the app and navigates to the person display through other means.

Having two different entry points in to this part of the app may not be a bad idea. This largely depends on how the application is architected. You wouldn’t want to duplicate all of the code that sets up the display of the person’s details in both of the entry points, but you wouldn’t want to have a bunch of ugly if-statements in that code to determine how to set things up, either. Some simple abstractions of the common bits would help keep this code manageable.

Option: Building An “onReset” Callback

The third option that I can think of – and the one that I implemented for this particular client project – is a variation of using the collection’s reset event. The idea is to build an “onReset” callback system that is aware of whether or not the collection has already been loaded or is still waiting to be loaded.

If you have the persons collection being loaded from some other application initialization code, then you don’t necessarily have the ability to use a simple reset event as shown above. You could try to use the reset event, but there’s a race condition that is introduced in low-latency, high speed networks (i.e. your local development machine).

If you don’t control when the `.fetch` method is called, then you may end up binding to the reset event after the collection has already been reset. In that scenario – which is very likely to happen when working in a local development environment – your view for the specific person model will never get displayed.

The solution I came up with is to have a callback mechanism built in to the collection, that pays attention to the collection’s reset event and knows to either wait for the reset event to be fired, or to fire the callbacks immediately because the collection has already been loaded. I’m calling this an “onReset” callback, for lack of a better description at this point.

The code to use the onReset callbacks would look something like this:

// App.js// ------// some initialization code that happens elsewhere, using Backbone.Marionette
App.addInitializer(function(){  App.persons = new PersonCollection();  App.persons.fetch();});


// PersonRouter.js// ---------------// The router callback that needs to get the person
personById: function(id){  App.persons.onReset(function(collection){    var person = collection.get(id);    App.showPerson(person);  });}

view raw 3.js This Gist brought to you by GitHub.

In this setup, adding an onReset callback guarantees the callback’s execution. If the collection has not yet been loaded, then it stores the callback and waits for the reset event to fire. If the reset event has already been fired, then it simply executes the callback immediately. Either way, your callback will be executed and you will have the collection available when it does.

Race Condition Reduced. Eliminated?

Here’s the implementation for the onReset code. It’s generally functional and I haven’t yet run in to any problems, yet.

OnResetCollection = Backbone.Collection.extend({  constructor: function(){    var args = slice(arguments);    Backbone.Collection.prototype.constructor.apply(this, args);
    this.onResetCallbacks = [];    this.on("reset", this.collectionReset, this);  },
  onReset: function(callback){    this.onResetCallbacks.push(callback);    this.collectionLoaded && this.fireResetCallbacks();  },
  collectionReset: function(){    if (!this.collectionLoaded) {      this.collectionLoaded = true    }    this.fireResetCallbacks();  },
  fireResetCallbacks: function(){    var callback = this.onResetCallbacks.pop();    if (callback){      callback(this);      this.fireResetCallbacks();    }  }});

view raw 4.js This Gist brought to you by GitHub.

You can then extend from OnResetCollection instead of Backbone.Collection to get this functionality.

I still worry that there’s a potential race condition in between the logic and the pop’ing of items off the array. I’ve travelled every logical path of execution for the asynchronous call and onReset call that I can think of, and I can’t find any issue. I would love to hear from someone more experienced with race conditions in JavaScript, though.

Keeping a Good Agile Estimation Practice

As part of our Scrum practice at vianet, we spent time as a team tending to the Product Backlog. We played planning poker and kept all our stories sized. We knew the entire size of the Product Backlog. Every Sprint we looked ahead and refined some User Stories.

Our velocity was stable and we could predict what User Stories would fit in a Sprint. The total size of the Product Backlog and the number of Sprints left projected that we would not hit the date promised to the customer.

Verifying the Estimates

The Product Owner started to question our estimates. He neither questioned the technique itself nor the merits of relatively sizing items, just the numbers we produced from this estimation technique.

We decided to spend a day with the Product Owner looking over the backlog. We looked at some of the work we’d finished to help calibrate sizes, and triangulated it with the items not yet started. Some of our User Story estimates changed. We sliced some of our User Stories thinner and even removed a couple. The Product Owner was convinced that our estimates were sound.

When we finished and totaled up the points, it was nearly the same as the beginning number. We learned that keeping the backlog sized is priceless and that reassigning points is useless. The total size of the Product Backlog had not moved a significant amount from all of our work, although we now were intimately familiar with it.

Time for a Talk

This didn’t help the fact that we all recognized that we needed to have a tough discussion with the customer.  We couldn’t deliver on the date we promised with the features they wanted.

First of all, the fact that I am only blogging about last months event, a mere two hours from the start of this months event, is definite grounds for an apology! Better late than never they say?

The first Thursday in December. Four confident looking presenters got themselves geared up. No walk in the park this. Each presenter had only 6 minutes to get their message across. Each slide had to be no longer than 20 seconds. What I didn’t know, until that evening, was that each slide had to automatically be set to transition after 20 seconds. No pressure!

First up was Sheetal Gordhan. Scrum is not for the faint hearted was her topic!

I’m looking at my notes now, and I see the Ken Schwaber quote: “Scrum is hard”. And right next to that I have Sheetal paraphase: “This kak is hard”. I like Sheetal’s version I remember us all having a good chuckle, leaned back in our seats and took in a nice big gulp on our drinks. Our evening was set, we were here to have some fun!

Sheetal’s presentation reminded us that only a small percentage of teams are actually successful in Scrum. It’s really not easy and we need to prepare ourselves when we embark on this journey. Even though there are 1,000′s of articles online, it’s still not enough to prepare us for what lies ahead.

I can honestly say that I, in 6 minutes, had learned more about what a newbie organisation to Scrum should expect than I have in any course attended or article read.

My favourite slide of Sheetal’s. Hmmm, this is a tough one, there are so many. I liked the Google statistics of how many results one can expect when searching for Scrum information. But one that really stood out for me was the All Blacks doing the haka. Titled ‘Scrum Rituals’.( Remember, this event was in early December, only a few weeks after the All Blacks were crowned World Champs!). What are your development teams rituals? The usual stand-up and retrospective, or do you have something unique?

Next up was Meloné van Heerden, with her presentation entitled, What makes a great leader. Meloné had recently attended a course on this subject, and used the opportunity to apply her learning’s into the software development, in particular, Scrum, environment. One could see that the learning’s had a big impact of her, as her talk was passionate and energetic.

The subject of an ‘authentic leader’. What is an authentic leader? Or rather, what makes a leader authentic? Mel took us through the 6 step of process of discovering the authentic ‘you’. A necessary self-awareness process. A look at intrinsic and extrinsic motivators.

My favourite slide of Meloné’s. I personally liked the way in which she modelled the need to effectively set a leadership example, with well-known figures. Nelson Mandela and Barrack Obama featured, with Obama’s family an example of how important it is to build a support network. But my favourite would have to be a slide which represented who we sometimes don’t change. Any guess who features? Have a look at the photo below.

Next up, the good man David Campey. David had an interesting approach. Each of his slides represented a photo he had taken of his agile working environment. We got to meet his team. His manager. His Product Owner.

It told a story of a project. Starting from a photo of his Product Owner, looking very visionary in a room with blue-sky type walls, through to photo’s of his team hard at planning, and ending with his team out on a boat trip

I’ve always found it fascinating to see how other organisations work. How they approach their Scrum repertoire. Especially local companies.

David’s presentation was recorded, so please have a look for yourself. I’ve already sent this out to my development teams. Motivational stuff!

And finally, Karen Greaves, who needed little introduction off course! Her talk was titled: “Agile Management: How to create a culture to help your team succeed.” It was awesome! Need I say more. Who thought a talk about management could be fun

Thank you to everyone that attended. And a big thank you to our four brave presenters. You were all superstars!

From Google: prag·mat·ic/pragˈmatik/ Adjective: Dealing with things sensibly and realistically in a way that is based on practical rather than theoretical considerations. Relating to philosophical or political pragmatism. I've never been one you could call academic.  I'd like to think that I've always had my feet firmly planted in the real world, however you define it.  My focus has always

Example 3: Using a Project Manager with Iterations and Kanban and Silo’d Teams

Here, the developers were in Cambridge, MA, the product owners were in San Francisco, the testers were in Bangalore, and the project manager was always flying somewhere, because the project manager was shared among several projects. The developers knew about timeboxed iterations, so they used timeboxes. Senior management had made the decision to fire all the local testers and buy cheaper tester time over the developers’ objections and move the testing to Bangalore. The Indian testers were very smart, and unfamiliar with the product, so the developers suggested the testers test feature by feature inside the iteration.

The project manager suggested they use cumulative flow diagrams and cycle time measurements to make sure the developers were not developing “too fast” for the testers. The developers, still smarting over the loss of “their testers” were at first, peeved about this. They then realized the truth of this statement, and developed this kanban board.

You can see in this board, that four items are waiting to go into system test. Uh oh. The developers are out-producing what the testers can take. This is precisely what a kanban board can show you.

The testers aren’t stupid or slow. They are new. They cannot keep up with the developers. It’s a fact of life, not a mystery of life. The developers have to act in some way to help the testers or the entire project will fail. The reason they are working in timeboxes as well as using kanban is that they have several contractual deliverables, that management, bless their tiny little hearts, committed to. The timebox allows the team or the product owners to meet with their customers and show them their progress. (They were deciding who would meet when I last worked with the team.) The kanban board help make the progress even more transparent.

Iteration planning: The product owner and the project manager jointly work on the agile feature roadmap, and the product owner owns the roadmap responsibility for it. The product owner owns and generates the backlog. The product owner and the agile project manager present a strawman iteration backlog to the team at the start of the iteration. They have had difficulty finding iteration planning time that allows everyone to be awake and functioning, bless the senior managers’ little hearts.

Daily commitment: They do a handoff, asking each other what they completed that day and what the impediments are. If you have read Manage It!, you know I modified the three questions to “What did you complete, what are you planning to complete, what is in your way?”

Measurements: cumulative flow, average time to release a feature into the product. They are experimenting with burnup charts and impediment charts. They are still having trouble bringing the testers up to speed fast enough.

Yes, they do retrospectives at the end of each iteration. Yes, the product owners own the backlogs.

I’ll summarize in the final part, the next entry.

(Want to learn to work more effectively on your geographically distributed team? Join Shane Hastie and me in a workshop April 17-18, 2012.)

Scrum Inc.'s Christine Hegarty wrote this today, just before she went on vacation, of course, so I'm posting it for her - jj
Here at Scrum Inc. we've been thinking a lot about the role of Product Owner recently. It's something that we see a lot of companies struggle with. It’s common knowledge in the Scrum world that a good Product Owner will increase revenue by keeping the backlog ordered so that we are producing the higher value sooner.  But just how they accomplish that isn't always clear. So we decided to offer the definitive Product Owner classes to help educate Product Owners on how they can increase business value and revenue. I've been working with Catherine Louis, CST, to launch our first Boston-area CSPO this month. At the beginning of March, Jeff will be teaching the Product Owner course he has developed in Los Angeles. 
In building the class, Catherine and I have spent a lot of time discussing the importance of the role to a great Scrum implementation. The following passages reflect some of our conversations about the role of the Product Owner and I thought they would be interesting for the community to talk about.    Q:  What is it that makes the Product Owner (PO) role particularly challenging? A:  The PO is the person who can answer this question: "Is this the right thing to do for the customer?"  That's a tough job!  The PO is someone who is market facing: he's able to craft and relay a vision. The PO is someone very close to the customer; the PO is the owner of a Product Backlog and focused on bringing value (and "delight!") back to the customer. He is also responsible for keeping a Product Backlog ordered such that the items at the top of the backlog are sized appropriately for the team to begin working on, and are ready to be taken in for the first Sprint. This is a role that can't be done alone: the PO is considered part of the team, and may need to have many stakeholders assisting in ordering the backlog, making sure we're taking into consideration the Pareto factor: i.e., the top 20% of the backlog should contain the highest value.

Q:  What are some of the key pitfalls? A:  Typically we meet new POs moving from a culture of traditional batch/phased development, dealing with larger and specialized teams, with a goal of upfront perfection and "requirements sign-off".
In traditional/waterfall development, the churn of requirements is discouraged, and there is a perfect plan and associated goal to deliver value at the end of a Release.  We cannot discount the massive cultural change needed to manage a Product Backlog that is emergent. We want to see a flow of value, customer collaboration, self-organized smaller and integrated teams, with value driven incrementally.   The cultural shift is one that moves us from crafting a fail-safe plan we want to execute and deliver at the end of a release, to a "safe to fail" framework where we learn and improve each iteration. Making this cultural shift allows us to turn this expected requirements churn into our competitive advantage. Q: So this cultural shift involves a lot more people than just the Scrum Team, including the Product Owner...
A:  The PO is key to the transition to Agile, but because it is a change of mindset for the whole organization, and a lot of players need to be involved from the beginning, roles not normally thought of as Scrum roles. Supporting roles in particular, should not be forgotten.
Take HR for example. We're now formed in self-organizing, self-motivated and self-managed teams, and the reward structure needs to be updated to acknowledge and reward team performance. Imagine what might happen if that doesn't change. Take Project Management:  We're now formed in these same teams, yet there is a Project Manager who is acting accountable for results asking for daily status reports in weekly meetings.
In making a decision to move from traditional/waterfall product development to Lean/Agile/Scrum, I recommend looking at everyone who is involved from initial decision, to delivery of value to the customer. Do not forget the cadre of supporting roles who need to be there as Servant Leaders to remove impediments, clear the path, and support the flow of value (the deliverables) to the customer.  Everyone needs to be on this page: For every decision you make, every day, ask yourselves "Is this the right thing to do for the customer?"  If the answer is "no", then don't do it. If the answer is "yes", say "hell yes!" and do it right away.  If the answer is "I don't know", take the decision to the Product Owner.
Catherine's Boston Product Owner Course will be held on Feb. 14-15 in Boston. Jeff Sutherland's Product Owner Course, for those of you on the West Coast, will be in Los Angeles Mar. 1-2.

Do you think team dynamics make a difference in business results?

© derby for Insights You Can Use, 2012. | Permalink | One comment | Add to del.icio.us
Post tags: management, teams

Feed enhanced by Better Feed from Ozh

This is the final part of a write-up of a talk I gave at a number of conferences last year. The previous post was about the science of economics

Scientific Management Revisited

Is scientific management still relevant for product development then? As I have already said, I believe it is, with the following clarifications. I am making a distinction between scientific management and Taylorism. Whereas scientific management is the general application of scientific approach to improving processes, Taylorism was his specific application to the manufacturing domain. Further, in more complex domains such as software and systems development, a key difference in application is that the workers, rather than the managers, should be the scientists, being closer to the details of the work.

Run Experiments

The used of a scientific approach in a complex domain requires running lots of experiments. The most well-known version is PDCA (“Plan, Do, Check, Act”) popularised by Deming and originally described by Shewhart. Another variation is “Check, Plan, Do”, promoted by John Seddon as more applicable to knowledge work because an understanding of the current situation is a better starting point, and Act is redundant because experiments are not run in isolation. John Boyd’s OODA loop takes the idea further by focussing even more on the present, and less on the past. Finally, Dave Snowden suggests “Safe To Fail” experiments as ways of probing a complex situation to understand how to evolve.

Whichever form of experiment is run, it is important to be able to measure the results, or impact, in order to know whether to continue and amplify the changes, or cease and dampen them. The key to a successful experiment is whether it completes and provides learning, not whether the results are the ones that were anticipated.

Start with Why

Knowing whether the results of an experiment are desirable means knowing what the desired impact, or outcome might be. One model to understand this is the Golden Circle, by Simon Sinek. The Golden Circle suggests starting with WHY you want to do something, then understanding HOW to go about achieving, and then deciding WHAT to do.

Axes of Improvement

One set of generalisations about WHY to implement Kanban, which can inform experiments and provide a basis for scientific management is the following:

• Productivity – how much value for money is being generated
• Predictability – how reliable are forecasts
• Responsiveness – how quickly can requests be delivered
• Quality – how good is the work
• Customer Satisfaction – how happy are customers
• Employee Satisfaction – how happy are employees

The common theme across these measures is that they relate to outcome or impact, rather than output or activity. Science helps inform how we might influence these measures, and what levers we might adjust in order to do so.

Lean

In these posts I have described Kanban in terms of the sciences of people, process and economics. However, this can actually be generalised to describe Lean as applied to knowledge work, as opposed to the traditional definition of Toyata’s manufacturing principles. The differentiation is also a close match back to my original Kanban, Flow and Cadence triad.

• Kanban maps to process, with the emphasis on eliminating delays and creating flow rather than eliminating waste.
• Flow maps to economics, with the emphasis on maximising customer value rather than reducing cost.
• Cadence loosely maps people and their capability, with the emphasis on investing in those who use the tools rather than the tools themselves.

References

The ideas in this article have been inspired by the following references:

• Kanban, David J. Anderson
• The Principles of Product Development Flow, Donald G. Reinertsen
• Brain Rules, John Medina
• Software by Numbers, Mark Denne & Jane Cleland-Huang
• Cynefin