Archive for October, 2009

Turning the Daily Scrum Upside Down

October 30, 2009 2 comments

At the start of the last Sprint my team decided to move our Daily Scrum from 8:30 in the morning to 4:45 in the afternoon. Typically these meetings are done first thing in the morning, and for the last eighteen months that’s the way my team has operated. The change was not made because our morning stand-ups weren’t working, but after a little bit of conversation and observations over the last few months we thought we could make them better.

The workday for most Point2 developers starts at around 8 am, and wraps up at 5 pm. Since I’ve been a Team Lead I’ve held all of my teams’ stand-ups at 8:30. The idea was that it gave people a reasonable amount of time to check their email, get their coffee, and take care of whatever else they needed to prior to diving into the day’s work. Below is some of the things that we thought weren’t working as well as they could.

  • The previous day’s work was anywhere between 11 and 20 hours in the past, and no longer fresh in the developers mind.
  • We were seeing an awkward period of time in the morning between 8 am and 9am where developers were unsure what they should be working on. Do the pairs from the previous day get back together for 45 minutes?
  • Stand-ups would often go over the 15 minute time-box since the team was sometimes “too thorough” in their contributions.
  • There were four other teams having their Daily Scrums more-or-less around the same time in the morning, making it difficult for some representatives (systems, technical support) to attend all of the ones that were relevant to them.

So it has been a week since we began the experiment and during today’s Sprint Retrospective, this is what the team has observed.

  • The contributions made by each of the developers seems very thorough, with them no longer forgetting to mention something of importance. I personally think that the quality of the contributions have increased as well. All week phrases like, “I forget what my pair and I did in the morning, but….” were not heard.
  • As the developers start to roll into the office in the morning at around 8 o’clock, they already know what they are going to be working on since we setup our plan the previous day, including who they are going to pair with. Once they finish checking their email and grabbing their coffees they can get started on their day’s work. That awkward 45 minutes seems to have been eliminated.
  • Since we have some team members that need to be out of the office at 5 pm our stand-ups now have a hard time-box. People have obligations outside of the office and will make an effort to ensure their contributions are on point and efficient.
  • Our stand-up no longer coincides with any other teams’ so anyone who needs to attend can do so.

We understand that there are some scenarios we didn’t encounter that will take some creative thinking to overcome. Since we are devising our plan the day before, a developer calling in sick, or a production issue popping up overnight will throw a wrench into our plan. We agreed that these scenarios are not a regular occurrence and can be dealt with on a one-off basis.

As a team we have decided to continue our experiment during our next Sprint which kicks off on Monday. Despite all of the positive things we have seen so far everyone still feels that one week isn’t quite enough time to fully evaluate the modification. However one thing is for sure – we are all comfortable in making changes to our processes when something isn’t working, or just needs to get better.  Being agile has allowed us to flip an entire process upside down without second guessing ourselves.  We’re all out to make the best team we can, and are not afraid to make some course corrections along the way.

By Hemant J. Naidu


Coping with Change

October 23, 2009 Comments off

While attending Declan Whelan’s session Learning is the Key to Agile Success: Building a Learning Culture on Your Agile Team at Agile 2009, he mentioned the Change Process Model introduced by family therapist Virginia Satir. Declan only touched on Satir’s model, and I found myself wanting to know more after I left. With Point2 going through a high degree of change in the last two years, I was very curious as to how the Satir Process Model fit in.

The Satir Process Model was initially introduced to help families deal with change, but coincidentally enough it was also used at an organizational level. It’s no secret that businesses have to change in order to stay competitive. However problems can arise as those changes are introduced, and what Satir’s model helps us understand is the natural stages encountered along the way. There are five stages.

Late Status Quo

  • The subject group is at a familiar place.
  • The group has a strong sense of identity, and are comfortable with each other.
  • Behaviour of individual group members can be predicted.


  • Something foreign is introduced to the group which requires some sort of response.
  • The change is usually introduced by a small minority.
  • The rest of the group sees this as a threat to how things work, and fear losing their sense of familiarity.
  • The group will generally try to undermine the change, or avoid it completely.


  • The group fully plunges into the change.
  • Relationships may change.
  • The group may no longer behave as they used to.
  • The group will lose their sense of belonging causing them to become anxious and vulnerable.
  • In this stage the performance and productivity of the group take a sky-dive.


  • Something clicks and the group starts to embrace the foreign element. They see ways to use it in a positive way.
  • The group begins to form new relationships, and a new sense of familiarity starts to emerge.
  • Performance and productivity starts to climb.
  • The group starts to experience genuine excitement.

New Status Quo

  • The group now levels off into a new comfort zone with new relationships, and have a sense of stability again.
  • Performance and productivity are now at a higher level than the Late Status Quo stage.
  • There is an overall sense of accomplishment.

The image below does an excellent job of illustrating the model.

Being aware of the stages of the Satir Process Model, and looking back at some of the changes Point2 has underwent, I can definitely see this model’s relevance. A good example would be a recent shift from product-centric teams to feature teams. Up until this point Point2 has always had each team focus on one product (or suite of products), but this approach made it difficult to ensure that the highest priority work items for the company were always being worked on.

Feature teams seemed to be the way other companies were dealing with this problem so the change was introduced. Sure enough there was resistance (including from myself), performance and productivity were hit, and the teams could no longer function as they once used to. But the teams did not give up, and  continue to push through their uncertainties. I believe we are still in the change process, but have recently started to fully understand and embrace the benefits of feature teams as the Integration stage implies. I don’t think it will be long before we reach that new status quo.

Understanding the Satir Process Model has given me a new perspective on change, and I look forward to seeing how Point2 copes with it in the future. I think it’s a great exercise, and recommend looking back at changes your organization has gone through while identifying behaviour that was encountered at each stage. Having that awareness is only going to make change that much easier in the future.

For an excellent post check out Steven M. Smith’s The Satir Change Model.

By Hemant J. Naidu

Let’s Get Cooking

October 16, 2009 Comments off

In a previous post I mentioned the ABIDE principle along with a cooking metaphor to explain a team’s flow. This was one of the topics during Joseph Pelrine’s Coaching Self-Organizing Teams workshop at Agile 2009. As Joseph pointed out, a team will be at its highest level of self-organization and productivity while they are in a so-called cooking state. The key is for the team to stay out of the other four states to ensure that they don’t get into trouble.

Joseph presented us with the Ideal Gas Law.

pV = nRT

For those who do not remember their high-school chemistry class, here’s the breakdown of that formula.

  • p is the absolute pressure of the gas
  • V is the volume of the gas
  • n is the amount of substance of the gas
  • R is the gas constant
  • T is the absolute temperature

So if we were to apply this theory to how we run a team (to some extent) we should be able to find the ideal environment for a team to function in. This is where Joseph’s cooking analogy was introduced. Essentially there are five states a team can be in. The team can function in any one of these states, but each state has a different level of effectiveness.


  • No energy to do anything.
  • Usually highly bureaucratic.
  • Very exhausting to keep a team at this level; lots of energy required.
  • Team becomes neurotic.
  • Very brittle, and it is not uncommon for things break.


  • Little room for movement; People still feel stuck requiring a lot of effort to get things done.
  • Requires a lot of energy to get out of this state.

Cooling (I like the word Simmering better)

  • Heat is not high enough for cooking to happen.
  • Things start to break down.
  • Discipline starts to break down.
  • This can be the most dangerous state.
  • There is still a lot of flexibility for things to happen.
  • Change can go in different directions.


  • The energy level is high enough that people are interacting regularly.
  • People get away from their ingrained behaviour patterns.
  • Stress levels are low.
  • This is the ideal level.


  • When people are at this heat level, they experience too much stress.
  • Fight or flight attitudes emerge.
  • It is not uncommon for people to burn out.
  • Things become charred, and you may turn into a solid once again.

I’m sure that many people have experienced at least a couple of these states throughout their career. Many teams just settle into their current state and remain there. It is clearly in the best interest of the team to get to the cooking state, but what can they do to get there? You need flow, which defines the optimum state of productivity.

As the above graph illustrates, when you are below the Flow Zone you experience boredom because your skills typically outweigh the challenges that you are presented with. And when you find yourself above the Flow Zone, anxiety sets in because the challenges are beyond your skillset. Over time we push ourselves to avoid boredom. As we get better at what we do, we naturally start looking for more challenging problems. Keep in mind that there are adrenaline junkies who like to be way outside of their comfort zone. The key is to find that right balance.

So how do you find that balance to get cooking while riding the Flow Zone? ABIDE gives you five things you can change to help you do just that. It is to be noted that these all can work in conjunction with each other. For example, changing the environment can be an attractor.


  • These are the people, positions, situation, ideas, that others tend to be attracted or driven to.


  • Who’s in, and who’s out?
  • The boundaries of your team.


  • The roles and responsibilities that people on the team have.


  • The makeup of your team including skillset, culture, gender, etc.
  • Keep in mind that a homogeneous system will not self-organize properly, and dominance will emerge.
  • Bring in someone new and it will surely trigger change.


  • Change the circumstances of the team’s environment, and they will have to change how they work ex) tear down cubicle walls and introduce an open work environment

If you know that your team is capable of cooking maybe some of these ideas of Joseph Pelrine’s can help. I believe he has presented some very useful strategies for making good teams great.  We must realize that it is up to us however, to play with the ingredients and temperature dials, and to renovate the kitchen in order to find that perfect recipe for success. I think with a little creativity we can all be chefs.

By Hemant J. Naidu

Aligning Purpose

October 14, 2009 Comments off

In August I was fortunate enough to attend the Agile 2009 conference.  I saw two excellent sessions presented by Pollyanna Pixton.  I later found out that four other sessions (attended by Tefon) included recommendations of the book Stand Back and Deliver, authored by Pollyanna and 3 of her colleagues.  These presenters were so convincing Tefon even purchased the book while still at the conference.  It was a good read, but the chapter on the “Purpose Alignment Model” was by far my favorite.

The Purpose Alignment Model is a simple tool designed to do exactly that – facilitate an alignment of purposes.  The underlying premise is all product features or development that a company performs can be placed on two scales:  how critical and how differentiating they are to the operation or success of the company.  With everything placed on these scales, they can then be combined into a graph.

Purpose Alignment Model

Purpose Alignment Model

This simple graph can make discussion about any number of product features or work processes significantly easier and more effective.  When discussion about a feature starts by first placing it on the graph above, it is placed sharply into perspective.

What constitutes a mission critical differentiating feature?  One simple method for determining this is to ask ‘Could this feature be the center of an advertising campaign for the product?’  These features are the driving force to a product’s adoption and define the identity of the company.  If every feature gets a ‘yes’ answer to this question the model is being used wrong.  Trying to differentiate with every feature will result in little more than a mediocre product.  A select few features should be placed in the ‘Invest’ quadrant and these are the features that, naturally, should receive heavy investment.  If these features aren’t the most polished and solid in the product, get to work.

If an honest assessment of everything about a product is completed with this model, the majority of what might initially have been placed in the investment quadrant will end up falling into the parity quadrant.  The parity quadrant is interesting.  Most of a product’s features will invariably not be differentiating, so why waste resources trying to develop them?  These features are mission critical, make no mistake about it, they have to work and they have to work well.  Parity features will drive the sticking power of an application, thus it is still critical to get them right.  The key point, however, is that parity features only need to reach parity.  No wheel reinventing required.  Parity features aren’t innovative.  Look at what the market is doing.  What is the accepted best practice?  Do that and nothing more.

If a feature is differentiating but not critical to the success of the business, find a partner.  Don’t waste resources that could be spent getting parity features to parity and investing in mission critical differentiating features.  Find a partner who is investing in the feature and use them.

If a feature is not mission critical and not differentiating, who cares? If a feature in this quadrant is being worked on, ask why.

If every feature to be worked on is placed properly relative to each other on this graph the result is an amazingly powerful communication tool.  Suddenly everyone from the CEO to the developer implementing the feature can easily be on the exact same page.  With an aligned purpose across the whole team, from executive to business to development to IT, more time is spent making a profit and less time debating about how to make a profit.

By: Dustin Bartlett

10 Temptations of an Agile Coach

October 9, 2009 3 comments

When you are in a position of leadership on an Agile team, there is no shortage of mistakes that you can make. Some of these mistakes may be trivial, but there are behaviours that can really limit the progress and efficiency of those you are supposed to be leading. While attending Agile 2009 in August, Stevie Borne gave a quick talk on what she felt were the top 10 Temptations of an Agile Coach. Whether or not you are in a coaching role, being aware of these temptations will help you identify them, and hopefully get them dealt with early.

1) Meddling
– Interfering with the team’s activities when you shouldn’t.
ex) technical work, updating story board, writing stories, creating acceptance criteria, etc.

– Takes away from team ownership.

– Allow team to make mistakes.
– Make suggestions, but let the team experiment.

2) Impatience
– Unrealistic progress expectations, and pushing the team to go faster than they can.

– The team becomes discouraged.
– The coach may burn out.
– End up spending unnecessary time and resources.

– Remember that change takes time.
– Find a coaching mentor to help with these situations.

3) Mastery
You have all the answers, so you freely give them out.

– The team fails to problem solve.
– The team become afraid to fail.
– It becomes your process, not theirs.

– Ask the team how they would handle it.
– Provide ways for them to solve problem, but let them choose what works best for the team. (guide through process of discovery)

4) Changeful
– New idea every iteration giving the impression of constant change for no good reason.

– Team loses the chance to get the feel for new techniques.
– Become too focused on the how, not the why.

– Let the team try changes for at least 2 iterations.
– Make sure there is a good reason for the change, and make sure that it is well communicated.

5) Inflexibility
– Believe there is only one way to do things.  Worked good on one team, so it will work well on this one.
– Dogmatism.

– Team loses sight of the value behind the practice.
– The team becomes alienated from you.
– The team allows the process to replace their own thinking.

– Learn new techniques to accomplish the same goals.
– Focus on principles, rather than practices.

6) Control
– Take control of the team through work assignment.  Often occurs when team faces delivery pressure.
– Injected work items.
– You start speaking for your team.

– The team is no longer empowered.
– The team team loses respect for you as coach.

– Force yourself to step back and re-engage the team.  Give control back to them.

7) Utopia
– Preach that Agile will solve all problems. It’s the only way to work, and everything will go as planned.

– The team loses faith in Agile principles.
– The team feels as though they have failed.
– The team is unprepared for potential disaster.

– Understand that discomfort during change is normal.  Admit it and learn to be OK with it.

8)  Love
– You want everybody to like you.
– Can’t take negative feedback.
– Avoid being bad cop.

– Your feelings end up get hurt.
– The team stops being honest with you.

– Need to develop a thick skin.
– Stay objective, and only mention the facts.

9) Fuzziness
– Problems are talked about in vague terms with no path towards a resolution. ex) “we have so many meetings.”

– Issues go unresolved and team becomes frustrated.
– The team grows apart.

– Ask the team questions. Use the 5 Why’s to find out what the real problems are.
– Name the issue and create an approach to attempt to resolve it.

10) Avoidance
– Avoid failure – unwilling to try new techniques.
– Avoid conflict – unwilling to challenge the team when things go awry.

– Your team misses valuable growth opportunities.
– You miss coaching growth opportunities.

– Understand that occasional failure is OK.
– Find a coaching mentor and ask for help.

By Hemant J. Naidu

University of Saskatchewan Programming Contest

October 7, 2009 Comments off

U of S Programming ContestMarcos and I attended the University of Saskatchewan Programming Contest where students were competing for prizes and the chance to attend the Regional Programming Contest at the U of S on Oct 30, 2009.

The contest had eight coding problems to solve. To win you just needed to correctly solve the most questions. However, in the event of a tie the team who solved the problems in the shortest amount of time wins. The questions ranged from very simple to extremely difficult. If you are interested in seeing some sample questions (Or would like to test yourself!) you can check the U of S Programming Contest sample page.

Students competing in the contest ranged from novice to advanced, however there was also an opportunity for anyone interested, to form a team and compete for fun! (count us in for next year). The contest is not just about writing code, but more about focusing on problem solving where you prove your solution with a small program. Of course the competitors who are able to solve each problem with small simple applications definitely have an advantage.

While at the programming contest we had the chance to meet the co-ordinator of the programming contest, professor Christopher Dutchyn. He gave us an overview of the contest, how scoring was handled, and walked us through some of the problems teams were attempting to solve. During our discussion, Marcos chanllenged the winners of the U of S contest to a programming contest with Point2 employees.

During our weekly professional development time we plan to put together a team to practice similar problems to the ones solved in the programming contest. We hope to prepare ourselves for a fun challenge. We know the competition will be tough, but we hope to give students a fun practice session before they go on to another competition. We hope to set something up some time over the next few months. If not, then we will enter a team next year and compete for fun.

At the end of the contest there was an awards ceremony where some prizes donated by Point2 were presented to the contest winners. Marcos and I also had an opportunity to tell the students a little bit about Point2. We hope to see many of those students applying for positions offered through the U of S Internship Program for next spring.

After having a chance to spend a day on campus it sure makes me miss my time their as a student. The faculty and staff were great hosts.

by Brian Richardson and Marcos Tarruella

Taking A Stand

October 7, 2009 2 comments

Earlier this year my role with Point2 changed, requiring me to switch from a desktop to a laptop.  I’ve never owned a laptop before and have never used one for extended periods of time before.  The switch to a MacBook Pro presented an ergonomic challenge.  At Point2 there are a hodgepodge of styles for working with a laptop.  They range from simply using the laptop, to about every combination possible of external mouse/keyboard/monitor.  The resulting mess gets placed on as many (or more) MacGyver contraptions for getting it all organized on your desk.  Although a few of these look cool, they either don’t work well or take up a lot of space on your desk.

So the obvious, simple solution would have been to just order something from Ergotron.  Most of their stuff looks quite functional while making an art deco terminator endoskeleton fashion statement.  Small problem though, the one I’d want costs $300.  Less obvious solution: fire up Google Sketchup and start designing the smallest form factor, relatively simple to build, laptop stand I could.


Two hours with Sketchup resulted in the design you see above.  It will work best with a 15″ MacBook Pro and a Dell 2009W monitor.  I showed the design around, and ended up with requests for 9 to be built in total.  Several months of sporadic work later, Emily and I spent a total of 45 hours combined to get them built, painted and delivered.

A few miscellaneous thoughts:

  • Here is the design: Laptop
  • I highly recommend the use of the CutList 4.0 plugin for Sketchup to either export a CSV or directly generate a cut sheet.
  • All the tapered cutting in this design is also infinitely easier to deal with using a good guide system and a circular saw rather than a table saw.  If you really look into Eurekazone’s products with an open mind you might even decide, like I have, that a table saw is an obsolete tool.
  • The Kreg K3 Master System is also an exceptionally well designed and effective tool.  I wish all my tools worked as well as this one does.
  • If you are wondering where I got the legs for the stands, go here.
  • Raw material wise, the stands cost about $30 to build.


So far I’ve had 3 requests for more to be built.  Not sure what will be required to get more built, now that I have one on my desk.

By: Dustin Bartlett