Sunday, August 21, 2011

Where should I sit?

Inevitably, there will be some change to your team.  Someone will leave or perhaps you will have new members joining you.

Either way, you will be asked the question "Where should I sit?".

Do not take this question lightly.  You have the opportunity to make significant changes with the addition or departure of a team member.

There are many different types of personalities in a team.  Because of this, you cannot realistically expect the same personal interactions between people sitting next to each other.

More importantly though, it is your responsibility as a Scrum Master, Mentor or Coach to consider the positive adjustments which can be made during this great opportunity for change.

A simple example to get you thinking about this could be....

  • You have a developer sitting at an end station with a slightly restricted view from the rest of the team.
  • This team member does not ask for help when he or she needs it.
  • You will be adding a developer to your team.

Trying to talk to the developer who does not ask for assistance, may help.  However, why not consider using this opportunity to solve this problem in a different way.

If the developer is moved to a more central location, they will not be as separated from the group.  Perhaps this would give them more opportunity to ask for help, increase their communication level with peers, and if you are lucky, the other team members will more easily recognize that this is happening an spur this person on to get them to ask for help.

So, where do you put a new developer ?... Certainly not off at the end by themselves.  The new person will feel isolated, and will have a harder time integrating.

The team is already a very close unit and has gone through the team development stages of Forming, Storming, Norming, and Performing.  With the addition of the new team member, this cycle will start again and will make it even harder for them if they are on their own at the end of the seating layout.

Reminding the team of the four stages of team development before a new person comes on board can be a big help.  It reminds all team members of how hard it is to integrate new members and the likely result of the addition.

Many people can get attached to their desks or workstations.  Therefore, moving people around in a traditional environment can be a painful experience.  In an Agile team, life is about change, adapting, adjusting to what is happening and making positive changes to improve productivity and enjoyment.

As team members move locations, they will learn different skills and ideas from the person sitting next to them.  It will also be common place to adjust as necessary.

Changing team member locations also helps change things up and gets rid of complacency.  A danger for an Agile Team is no longer attempting to make changes and progress because everything is "fine" or "perfect".  If you are hearing these things from your team in Review or Retrospective meetings, perhaps it is time to change desks just to get change happening again.

There may be other personality or non-team type things you wish to address.  Instead of bringing that person into an office and talking to them, you could solve things by simply changing desk locations.

Better yet.....  If you have a team that has embraces and practices Consultative Decision Making, why not ask the Team where the new person should sit to be most effective!


Scrum Master - Scrum Alliance
Consultative Decision Making -
Open Agile Institute
The four stages of team development

Monday, August 1, 2011

What if your first cycle ends up with Zero Story Points Completed?

I recently introduced a small software development company to the ideas of Agile development, the culture of Agile, and of course some of the fundamentals of working in incremental steps.  We focused specifically on OpenAgile.

They started their first cycle with great enthusiasm and with as much attention to detail as possible, but still ended up completing zero story points in their first cycle. Is this is a disaster ? The short answer... NO.

The company has gone through two major releases based on non-agile methods with limited success. One of the owners of the company has been a long time friend and we discussed doing some Agile training with his employees to "see how they felt" about learning about OpenAgile.

There were no commitments made to it. The idea of "Hey, let's learn about this and see if it's right for our organization" was the goal. All the team members were told that the company was considering (with emphasis on considering) switching to OpenAgile and would not do it if everyone didn't feel like it was worth the effort and made sense for them. It was stressed that OpenAgile is not a silver bullet and may not be right for them. The effort was purely exploratory in nature.

As this company is in software development, Agile development easily made sense for them. They were so excited by the OpenAgile training, the developers and the owners decided to immediately abandon their existing plans for development and refactor.  The fact they felt they could do this shows true management leadership and support for the process.

I have to congratulate my friend for his courage in supporting his team.

The team determined that they were working on functionality which would not provide the greatest Return on Investment and decided to adjust their priorities accordingly.

A great deal of our time was spent during the training on the ideas of Consultative Decision Making and encouraging openness between those involved in the process. All team members are encouraged to be open about their opinions during planning and if they find something wrong during the cycle, to speak out.

I find that having management and stakeholder support and encouragement in the process is almost mandatory for Agile to work. Without the understanding from the owners of the company, the culture required to make it work will inevitably cause friction "around the edges" of the Agile team.

We spent time on the concepts of ROI (return on investment) and how to apply it to estimating, planning, re-estimating, and selected work. In using OpenAgile, we want to work on the tasks that give us the biggest value over effort factor or ROI.

We followed the OpenAgile syllabus. As an OpenAgile trainer and mentor, I had easy access to material to teach in an organized fashion.  Their environment is complicated by owners in multiple cities and developers in 3 different cities including an overseas component.

Openness about the potential pitfalls of remote teams made a big difference to the attitudes of those taking the training and the final outcome. Learning OpenAgile, Scrum, XP Programming, or any Agile process is difficult enough without adding the component of two remote teams and overseas development.

Many people leave their OpenAgile training realizing that it is a very effective framework and are anxious to get rolling. Because this company and the team decided to continue with OpenAgile, they started the preparations for the first cycle to begin the following week (after a long weekend break).

The cycle started, cards were created as Story Points, and the work began in earnest. They had many surprises. I had been unavailable through their first cycle and had very little ability to keep up with how they were doing because of a new Scrum Team I was working with. In retrospect, I am glad I was not there to give advice. They did fine on their own :->

In true Agile form, they figured out on their own what was going wrong and when I talked to the owner several weeks later I found out that they had already determined their mistakes.

The team was actively taking steps to improve the next cycle.

If senior managers encourage the right environment and let the team self-organize... you know what.. they likely will :->

Things that went poorly

  • Two days into the cycle, some of their overseas developers went "to visit family". They did not realize at the time, this was local code for "going on holidays". I heard from the owner later that if they had not asked why they did not get responses to emails, they would not have known the other developers were away.
  • The Stories were Too Big. Because of the combination of the new way of doing things and the excitement about how much could get done as an Agile team, the team bit off more than they could chew.
  • Attempts at Test Driven Development did not go well.
  • The first two week cycle stretched to 3 weeks because the team didn't want to have Zero velocity as they felt this was a failure
  • One display bug crept into the first demo related to two different ways of refreshing data on the screen

Things that went well

  • The team talked regularly about how they were doing and worked on regular status updates to determine where they were during the cycle.  This is also how they found out about the missing developers.
  • The owners and managers had an active involvement in helping to remove obstacles.
  • The team found an intriguing way to determine how many story points they could actually commit to in future cycles.
  • The team figured out how to deal with code sharing and peer review type issues related to being at opposite ends of the earth.
  • The team stayed together and focused on the goal of creating potentially deliverable product
  • They were able to successfully work on two simultaneous streams of work on different parts of the system.
  • During the demo, the team was able to demo functionality that could potentially be brought to a customer after only two cycles.


I had a discussion with the owner recently and he told me they all sat down and realized their mistakes of their first cycle. They consider OpenAgile to be a success.

The team was so worried about not completing story points, they considered it to be a failure to not finish at the appropriate time. You need to let newcomers realize that not completing all the story points of the first cycle may happen.  This can be compounded by added complexities of your working environment or project.

Since they were pushing to get the points completed, they were sacrificing quality. They were rushing because they knew they had gone past the end of the cycle and it was causing more problems each day it continued. Thankfully, they stopped the cycle and decided to do the right thing and demo where they were and talk about their progress.

They simply took on too much work, didn't account for all the other overheads of a new team setup and issues that would take place with their remote environments. This did not mean failure. They learned how to re-organize themselves for future cycles.

With the support of the owner and a little bit of moral support from myself, the team realized they had accomplished a great deal already in their first cycle.

They realized they need to put some better controls on the holiday schedules of the remote teams overseas or at a minimum find out what is expected in this regard.

The team realizes it has a deficiency with Test Driven Development and is working on plans to allocate some time for training on this very important task. Perhaps their one bug from the first demo may not have been there with Test Driven Development in place. They will continue to work toward improving this.

One of the great things to come out of their first cycle.... A potentially deliverable product within the first two cycles!

When I reviewed this with the owner he told me the completed work is already faster and better than their previous system which took 5 years to write. Considering the remote component they are dealing with, this is truly great news for them. Their first cycle has produced software which can now simply grow organically.

Some advice here which I shared with my friend.. Make sure that you have at least one story that can be finished in the next cycle, no matter how small.  Consider it of huge Value to the Agile process.

You need to provide some positive feedback for the team members now.  This does not mean the team should agree to less work than they think they can accomplish. Simply encourage some work that can be completed to be included in the next cycle.

For my friend, although they completed zero story points in the first cycle, they are happy to know that if they just adjust the size of their stories for more attainable results and use what they learned from the first cycle, OpenAgile will work out well for them.

The concepts of Consultative Decision Making, Continuous Learning and the Learning Circle allowed them to truly excel and will allow them to continue to do so into the future.

They are looking forward to shipping their new product in record time :->

One comment that was made to me was something along the lines of "Hey Mike, this reminds me of when we used to work together in the garage when we started the company. We all worked together on whatever needed to be done. That's what made us successful in the first place.".... Hmmmm.

Mike Caspar, CSM, OA2/5

References: OpenAgile -