Author Archive

Was Our Velocity Seriously Zero?

November 20, 2009 · Filed under Point2 - Process and People · Tagged ,

Two Sprints ago something happened for the first time since I have been a Team Lead – my team’s velocity was a big fat zero. As a team we are fairly experienced in Agile and Scrum and quite self-organizing, yet somehow our Scrum board was portraying us as a rookie crew. The first question that may come to your mind is, “did you guy’s have to deal with a lot of production bugs or injected stories?” Sadly the answer would be, no. The team obviously wanted to get to the bottom of this anomalous Sprint so performing a root cause analysis seemed like the right thing to do.

After working through a root cause analysis exercise as a team (this is actually something we do on a weekly basis) we had a pretty good idea of what had contributed to us delivering a big fat goose egg. There were no real surprises revealed, but it did help to get some stuff written down and in front of our faces. On a positive note, the team did agree that even though we didn’t burn up any stories, a lot of work actually did get done. So what went wrong?

  • The was a lot of technical unknowns in the new project we were working on resulting in stories with fuzzy boundaries.
  • The team was unsure when they were done a story, and as a result they dragged on longer than they should have.
  • Our stories were obviously poorly broken down.
  • We were not representing the work that was actually getting done properly on our Scrum board.
  • The knowledge gained from earlier spikes may not have been leveraged to their full potential.
  • We had gotten a little too comfortable in our Sprint planning process. Our previous projects (in the recent past) were usually well defined and understood. Because of this we found ourselves spending less time planning because we could get away with a just in time mentality. This didn’t work for our current project.

Naturally we want our root cause analysis exercises to result in some sort of action plan. With an understanding of what led to our questionable Sprint, the team was able to put some corrective measures into place for the start of the next Sprint.

  • For each story/task on the Scrum board, represent hurdles and stalls visually. Even though we talk about them in daily stand-ups, seeing them on the board can help show severity if it goes on for a long period of time.
  • During our kick-off meeting break down each story into small, bite-sized tasks and use these on the Scrum board. They should be small enough that we have no cards on the board that have a complexity value over 1 – the smallest size possible on our scale.
  • Do not end the kick-off meeting until all task cards are completed, prioritized based on importance and dependencies, and a commitment has been agreed upon.
  • If we find ourselves doing something that is not represented on the Scrum board,
    1. ask yourself if you should even be doing it.
    2. if you should be doing it, write up a new card and put it on the board to ensure that everything we do is tracked.
  • Continue with one week Sprints.

So how did the team fare after putting their plan into action? They met their commitment. The kick-off meeting resulted in a Sprint plan that was straight-forward and well defined. It provided a clear-cut set of tasks that the team could easily base their commitment on.  During the Sprint they were more mindful of the work at hand and made decisions as to whether it belonged in the iteration or not.  As a whole we re-focused on areas that we had gotten too comfortable with and neglected.

It was very satisfying to see the team face this problem head-on. They calmly analyzed it, devised an action plan, and executed it. They could have easily panicked, but they didn’t. They proved that they were a mature team that could recognize a problem, and use their agility to correct it.

By Hemant J. Naidu

Leave a comment »

Shuhari and the Evolution of the Team

November 13, 2009 · Filed under Point2 - Process and People · Tagged , ,

The concept of Shuhari was mentioned on more than one occasion while I was at Agile 2009 in Chicago this past summer. Alistair Cockburn was the first to mention it in his keynote speech I Come to Bury Agile, Not to Praise It. It then surfaced again when Declan Whelan spoke about Learning is the Key to Agile Success: Building a Learning Culture on Your Agile Team. Shuhari originated in Japan as a martial arts concept describing the stages of learning to mastery. The word is actually three words combined.

Shu – protect or obey. It is based on traditional wisdom where the student learns all they can from their master, and accepts any instruction and criticism they are offered. The master acts as a protector, steering the student and watching out for their best interests.

Ha – detach or digress. Up until this point the student did everything based on fundamental teachings. At this point the student will start to break with tradition and apply more imaginative techniques, building on what they have learned. They will also start to question and start to evolve based on their own personal experience.

Ri – leave or separate. At this point the learner transcends to a point where there are no longer specific techniques that are being followed since everything now come naturally. The student has learned everything they can from their master and leaves. The student bases their learning almost completely through self-discovery with no actual instruction.  Ideally the student should have surpassed the master, allowing for the art to progress.

I found this concept to be very intriguing and it got me thinking about how it applies closer to home.  The development team at Point2 is always in a state of learning. In many instances the student and the teacher roles are obvious. A new college graduate will likely be paired with a veteran developer in a mentoring role, while more experienced developers will pair with each other, hopefully learning from one another.  I really believe that the last point in the Ri description is key. In order for the art to evolve and progress, the student must surpass their teacher.

A dilemma arises when everyone reaches that Ri stage and no one is able to get back into the Shu mindset. If everyone believes there is nothing new to learn, an obvious problem is created – your team will likely fail because they will lose their ability to compete. This is where having a culture of learning is paramount. People have to think of ShuHaRi as a circular idea that has no beginning and no end. If an entire team is dedicated making their colleagues the best that they can be, and are willing to learn from each other, the possibility of stagnating as a team fades away.

How is Point2 attempting to keep Shuhari a cyclical pattern? We mentor our new recruits, putting trust in our veteran developers to lead them down the correct paths. We pair program nearly 100% of the time, ensuring that developers are always teaching each other new techniques and skills. We dedicate Friday afternoons to personal professional development. People can choose to present or lead a workshop for a group, get together to develop a small application, or just spend some me time reading a book or watching a webcast. The point being is that our development team understands the value in learning and can see the relationship between the development of their careers and the success of the business.  Shuhari may not be a well known concept in the halls of Point2, but that doesn’t mean it’s not alive and well.

By Hemant J. Naidu

Leave a comment »

With Etudes, Practice Makes Perfect

November 6, 2009 · Filed under Point2 - Process and People · Tagged

Professional development is very important at Point2, and we are always looking for ways to foster that culture of learning. Last week I introduced my team to etudes, an idea that was very briefly touched upon by Declan Whelan in his Learning is the Key to Agile Success: Building a Learning Culture on Your Agile Team talk at Agile 2009. Most people understand an etude to be an, “instrumental musical composition, most commonly of considerable difficulty, usually designed to provide practice material for perfecting a particular technical skill.” Taking that definition, the concept of an etude in the software development world doesn’t seem too far-fetched.

Many people are starting to view software development as a craft that can be improved upon with practice. This is evident in the emergence of Code Katas, self-contained coding exercises designed for developers to hone their skills. An etude is similar to a Code Kata, but is usually smaller and can be completed in a reasonably short period of time. I wanted the etudes on my team to be very small and designed in a way that would allow the developers to continue working on their current tasks.

After explaining the concept to the team at a recent Retrospective we all agreed to come up with at least one etude by the end of the next Sprint. To our disappointment there was virtually no information or ideas on the net so we had to rely solely on our imagination. I even contacted Declan for ideas, but was told that he had similar problems finding helpful resources on the subject. Once our Sprint wrapped up the following week the team had managed to come up with some ideas.

  • No mouse for 30 minutes
  • Pairing ping-pong for an hour
  • No looking at the keyboard for 30 minutes
  • Print off shortcut list for IDE and don’t use menus for 30 minutes
  • Paraphrase every instruction/comment that your pair makes for 30 minutes

On Wednesday at about 2pm I stood up and announced to the team that they could not use their mouse for thirty minutes. After the gasps subsided the mice were set aside, and the the pair continued with their work. As one member of the pair struggled with certain commands we often found that the other member knew the shortcut and passed on the knowledge. Some developers were smart enough to print out the shortcut list a few days prior.

So what was the point of this exercise? While working in an IDE such as IntelliJ, shortcuts can be invaluable in how fast one can work. Learning to use the keystrokes as opposed to moving back and forth between the mouse and keyboard is a goal for many developers, and removing the mouse from the equation forces them to learn them. And as we also found out it can help a pair of developer share their knowledge.  Just like in music, you can’t do a musical scale once and be an expert.  The idea is that the more often you practice the scale, the better you will get.  This particular etude we tried will help the developers learn the keyboard shortcuts as long as we keep practicing them.

This was the only etude we tried in the Sprint, but the plan is to continue throwing them out there when it seems appropriate. Let’s just say that I wouldn’t have announced the etude if we were in the middle of fixing a high priority production bug. But just think, by continuing to do these performance enhancing exercises, we should be able to get those production bug fixes (and new features) out the door that much quicker.

If you have any etude ideas we would love the hear from you.

By Hemant J. Naidu

Comments (4) »

Turning the Daily Scrum Upside Down

October 30, 2009 · Filed under Point2 - Process and People · Tagged ,

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

Leave a comment »

Coping with Change

October 23, 2009 · Filed under Point2 - Process and People · Tagged , , ,

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.

Resistance

  • 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.

Chaos

  • 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.

Integration

  • 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

Leave a comment »

Let’s Get Cooking

October 16, 2009 · Filed under Point2 - Process and People · Tagged ,

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.

Solidifying

  • 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.

Gelling

  • 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.

Cooking

  • 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.

Burning

  • 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.

Attractors

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

Boundaries

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

Identities

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

Diversity

  • 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.

Environment

  • 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

Leave a comment »

10 Temptations of an Agile Coach

October 9, 2009 · Filed under Point2 - Process and People · Tagged , , , ,

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.

Consequences
- Takes away from team ownership.

Tips
- 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.

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

Tips
- 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.

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

Tips
- 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.

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

Tips
- 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.

Consequences
- 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.

Tips
- 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.

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

Tips
- 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.

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

Tips
- 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.

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

Tips
- 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.”

Consequences
- Issues go unresolved and team becomes frustrated.
- The team grows apart.

Tips
- 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.

Consequences
- Your team misses valuable growth opportunities.
- You miss coaching growth opportunities.

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

By Hemant J. Naidu

Comments (2) »

A Vivid Imagination Isn’t Just for Kids

October 2, 2009 · Filed under Point2 - Process and People · Tagged , ,

Last night I had the pleasure of seeing Sir Ken Robinson speak at the University of Saskatchewan as part of the Gail Appel Lectureship in Literature and Fine Arts series. His talk was titled Out of Our Minds: Learning to be Creative which focused on how our educational system and businesses are structured in ways that suppress creativity and imagination. He is convinced that we are at the start of a revolution as we are starting to recognize these limitations we have placed on ourselves.

Robinson presented an interesting study that showed how 98% of 1,500 children between the ages of three and five scored at a genius level in regards creativity. With those same children that number dropped to around 40% only five years later. By the time they were over the age of fifteen, the number was a measly 2%. The reason for this as Robinson posed, was that the children had been educated in our system. They had been conditioned to believe that there is ever only one answer, or one way to solve a problem.

If children are being taught to solve problems this way then they are obviously taking this with them to the workplace. What we end up with is people who feel they have a job and not a career. They feel that they are limited in what they can do, and are expected to work a certain way – the normal way. That natural sense of creativity has been suppressed for so long that the idea of trying to readopt it is not even on the radar.

What we have to do as educators and business leaders is create an environment that fosters creativity and imagination. The good news is that this is starting to get recognized in many organizations, and is being addressed. I’m happy to say that Point2 has been taking on this battle for the last year or so. We understand that creative minds will not only make our company a leader in the industry, but will also grow our team professionally and personally.

Like I said above, this is a battle. You don’t just say you are going to do it and it will magically happen. What we have found in our quest to create a culture of learning is that we have to come up with creative ideas to get the ball rolling. It’s kind of a catch 22 – we have to be creative in our ideas to develop a creative work environment.

We have implemented a weekly professional development program for our team and are constantly trying to make it more useful. We encourage trying to solve problems in a variety of ways and failing fast is always an option. And I love Marcos Tarruella’s idea in his most recent post, Six Impossible Things Before Breakfast.  And keep in mind that it is not just the leaders driving this, but the entire group as a collective.  As always I am interested in hearing from others on how they get their teams’ creative juices flowing.

Sir Ken Robinson spoke about the myth that a human’s number of brain cells is finite, and as we get older we kill more and more of them off in a variety of ways. As it turns out humans can stimulate the growth of brain cells by exercising their mind through creative thought and imagination. I’m not sure how many brain cells actually exist at Point2 at the moment, but I’m pretty confident that it is rising.

By Hemant J. Naidu

Comments (1) »

How Scrum Saved My Wedding

September 18, 2009 · Filed under Point2 - Process and People · Tagged , , , , ,

So what does a couple do when they are getting married in less than two weeks, and there is a pile of things to get done for the wedding? Well, when the groom-to-be is me, the obvious answer is that they organize the work using Scrum. I had floated the idea to my fiance a little while ago, and she wanted nothing to do with it. In her mind she felt that a list on our whiteboard would be just fine.

When we found ourselves a mere two weeks from the big day, I once again asked, “are you ready to do Scrum yet?” She reluctantly agreed, tweeting her displeasure for the world to see and we got underway. We knew there was a pretty big list of things to do so we started off with a Blitz Planning session.

I grabbed a stack of sticky-notes and we started to blurt out tasks that needed to be completed if this wedding was going to fly. As the tasks were identified I jotted them down onto the sticky-notes. Once we felt that we had a fairly comprehensive list, we took a few minutes to give each story a complexity value. A value of 1 was fairly trivial such as “pick up the wedding rings from the goldsmith”, while a 5 was reserved for things such as, “write our wedding vows.” We stuck with the Fibonacci numbers to allow for uncertainty in the larger tasks.

Since we had approximately two weeks before the wedding it made sense for us to have two, one week Sprints. With a table covered in pink sticky-notes, we moved each of the stories into one of two piles representing each Sprint. Now we were able to do a more fine-grained planning of each Sprint.

We knew that the more complex stories had higher risk associated with them so we made sure to start those as early as we could. We did however remain mindful to not overload Sprint 1 with only the large stories. There were some stories that needed to be done on certain days, and some that had dependencies on other teams which required some clever shuffling.

It didn’t take very long before we had our Scrum board organized into two Sprints. We split the board into columns representing each day allowing us to put the story cards onto the day we intended to complete them. This gave us a really good visual representation of the work ahead. This layout is actually very similar to the Scrum board my team at Point2 uses. Having a visual representation of when stories are scheduled to start and expected to finish is a great tool for the team, as well as stakeholders to get a sense of how well the Sprint is going.

We’re about halfway into Sprint 1 and things are going as I was expecting. Stories are being burnt up on a daily basis, while some of the more complex ones are taking longer than we had initially estimated (sanding and re-staining the kitchen light fixture…..which needed to be done prior to our rehearsal dinner at our house). Some stories we had hoped to start on a certain day have not yet started, while some were completed early. We’ve also seen a couple of new stories injected into the Sprint requiring us to reshuffle the board.

Obviously the Scrum process at home can only be, “Scrum-like”, but as the Sprints progress I am seeing many of the same things that my Scrum team at Point2 experience from Sprint to Sprint. So maybe Scrum isn’t actually going to save my wedding since I don’t think it was ever in jeopardy, but I do think it was a great exercise to see how applying an Agile method in a completely non-technical area yielded many of the same results seen in the software development industry. If anything, applying Scrum to the wedding preparation was a useful tool in devising a plan, allowing us to visualize and execute that plan, and have a little fun along the way….geek-style.

By Hemant J. Naidu

Comments (2) »

Operating From Above the Line

September 11, 2009 · Filed under Point2 - Process and People · Tagged , ,

When something goes wrong all humans tend to respond to the problem in the same way, no matter how big or small. At Agile 2009 Christopher Avery described what he called the Responsibility Process – five mental states that people naturally enter before reaching a true level of responsibility. But keep in mind that not everyone is able to successfully move out of all states of mind prior to responsibility, as Avery described. In order to be successful at this one must apply these techniques themselves, and recognize that they are in a specific state of mind. The graphic below illustrates the five states of mind.

The Responsibility Process

Lay Blame
After a problem is discovered a person will naturally try to account for the failure. They will try to externalize the cause as laying outside of themselves. Their first response is more-or-less, “there is no way that I caused this issues, so it must have been someone else.”

Justify
Once it is realized that the problem may have been caused by oneself, a person will try to justify why it happened. They are still trying to externalize the problem when they make excuses such as, “well there is no wonder that broke since I was being rushed to complete it.”

Shame
Once you move past trying to justify the cause of the problem a person will start to acknowledge that it was in fact their fault. While in this state of mind people tend to beat themselves up with statements such as, “oh I totally screwed that up. I can’t believe I made that mistake. It was totally my fault.” We must be careful not to confuse this with responsibility – it is actually self-shame.

Obligation
After self-shaming oneself a person will start to feel that that yes, they caused the problem, but the circumstances they were in didn’t give them any other choice. People will make statements alluding to having no control, or feelings that they are in handcuffs. “Well, that is just the way we were told to do it so I did it”, is a telling statement.

Responsibility
If one can move past obligation a person will move above the “line” and reach responsibility. The previous four states of mind are considered non-learning states – or to put it bluntly, we are stupid while in these states. We are in a coping stage and any decisions we make will probably be poor. But as we move above the line into responsibility we will find ourselves back in a “learning state”. It is here that we can make good decisions, and can start to produce value. Hearing things like, “the problem happened, but now let’s figure out how to fix it”, is a key indicator that someone is operating from responsibility.

The two grey stages in the diagram are not states of mind, but are additional stages. We are usually in a denial, believing that everything is fine and no problems exist. However once a problem is identified some people will not be able to cope. For instance the mental anguish of shame and obligation can lead a person to check-out without reaching a proper resolution. By quitting, a person does not learn anything and will likely be faced with the same problem in the future.

In order to get above the line, there are three keys. Intention states that a person must be committed to doing something. A person must also be aware that they are in one of the levels. To do this we must look for it in ourselves, and ask for the help of others to identify where we are. Avery suggested recognizing how you feel in each of these stages, and use that feeling in the future to help identify your state of mind. And finally we must confront the problem – you cannot interact with something until you are able to face it.

Obviously this stuff is based on behavioural science and it can be easy for technical people to dismiss. But be honest with yourself and think about these states of mind the next time you face a problem (this works in all aspects of your life – personal and professional). I know that my first reaction to a problem is to assume that someone else caused it. The key is to realize this and get past it. As one gets better at identifying what stage we are in, the quicker we can move from state to state. We always want to be producing value, so the goal is to operate from responsibility as quickly as possible.

By Hemant J. Naidu

Leave a comment »

« Previous entries
Next Page »