Saturday, March 26, 2011

Just ask the team for comments

Recently, the team I am working with really made me smile.

The company I am at has started on a new project involving the exchange of data over the internet.  During the design phase, our communications parameters and methods were established based on existing ways of doing things.

The Agile team I am on is relatively new to Agile proceses.  They are just getting used to the idea of opening up and sharing their ideas.  They know that they can say whatever they feel is appropriate (professionally of course), and they will not be chastised in any way for speaking.  I encourage all constructive comments from any team member.

I am so happy that I have brought this culture into our work environment :->

This particular project involved creating a complicated system of token creation and disposal. For obvious reasons, I can't say too much more than that.

I decided to take our "design document" (very rough overview) of how the system is intended to work and send it the team as a final check to ask them if they see any flaws or have any ideas.  The document was just about to go out to a third party to start work on.

One of the newer developers had the courage to speak up and say "Hey, why don't we do this instead"..... And this is why I encourage teams over individual processes any time.

None of us had known that this junior developer had worked on a project in the past that used such different technology. If he had not been given the opportunity to speak, we would have never had the benefit of learning from his experience.

The new design allows us the same level of security for our application in a significantly simplified manner.

If you're managing a team, don't think that if a developer is considered Junior to you or your company that their input is not valid.  This can really lower the team's potential development.

I am not encouraging a long debate or forcing everyone to speak. However, if someone has something to say, it might be worth listening to.  Of course, time-box responses from those that have something to say to avoid long debates.  If the idea is valuable, it will quickly become evident.

There are of course costs associated with changing a general design near its' start date, so ideas should be considered based on overall value to the company or project.  This can never be taken away.  Remember, the key word here is Value.

However, do yourself a favor and simply ask the team if there are any improvements you can make.  Some may be minor.  Some may be major and simply too huge to accomplish.

Make it clear that you may not use their ideas but that you do value them.  Keep comments time-boxed if someone wants to speak.  This will force the exchange to stick with the real value of the suggestion.

Sometimes though, it may surprise you what a simple "Does any one have any comments?" can do for you.

A foundation of OpenAgile, for instance is Consultative Decision-Making*.  This to me is the idea that all decisions that will effect the team will be reviewed openly with the entire team so that everyone understands and has the ability to make some input into the process.  

To me, this  is a great idea. It allows all team members to feel like they are part of the finished product and allows buy-in at an early stage.  This will be important later during problem solving sessions.

In our case, it will likely save us weeks of developer time, improve our product and make any future changes considerably easier.

Mike Caspar, CSM,
Open Agile Level 1 Certificate Holder

References : Consultative Decision Making* - OpenAgile.

Wednesday, March 16, 2011

Agile and it's interaction "around the edges"

Over 20+ years of development using an iterative approach to development, I have noticed a common thread to the process which anyone adopting Agile should consider.  The reaction from those "around the edges" is a common source of conflict.  A little bit of knowledge and information prepared for them can help.

Recently, during another Agile training seminar, I was again reminded that Scrum, OpenAgile, XP, or even to some degree Kanban will cause conflict around it's edges.  I also was pleased to be reminded that there is always something new to learn.

I don't intend on having a long discussion with you about the pitfalls other than to say that anyone doing Agile Development should be prepared for problems "around the edges".

As a company grows with Agile, it will inevitably show problems with systems, processes, ways of doing things, technology and other as yet unknown problems. This often happens within the first or second iteration or cycle.

This can cause an immediate dislike for Agile as it generally means that productivity first falls as people deal with the newly discovered problems.

Don't fear this!  As you find problems with your processes, you will fix them.  Some can be fixed immediately, and some may take many iterations to fix.  The most important thing to realize is that as each iteration passes, everyone's life will improve due to improved stability of the system, less bugs, or whatever your pain.

The most important thing here is that as new problems are found, everyone resist the strong temptation to finger-point.

Focus on the processes and improving them, not those involved.  This will take out the negative aspects. Once everyone knows Agile is about improvement and not blame, people will let down their guard regarding what happens and true progress can begin.

Most importantly; as time goes by, the team and the processes will become more efficient. After a while, if all goes well, the speed and lack of problems  will soon surprise your stakeholders with its' efficiency.

Again, don't be surprised.  If you are learning and agile approach to work, you will discover problems quickly.  This is considered one of the benefits of Agile development.

That being said, I believe it is important to help yourself and educate those around the team if at all possible.

I recently did a little training session for a new team I am working with to show them the benefits and practices or developing in short cycles, and working on a Product Plan.  I explained the idea of Return on Investment or "Value Drivers" (something which was new to some of them).  They learned about committing to a Sprint or Cycle plan and were given a small non-technical project to do to learn these processes.

It was a project they could not complete in the alloted time and one that none of them had any experience with.  It was non-technical and not related to IT.  This allowed the team to focus on the processes and working together and not get bogged down in IT technical arguments and discussions.

I made sure I let the team know about the concept of Forming, Norming, Storming and Performing before starting, so they would know what was to be expected.  It helped considerably with the exercise.

What was interesting to me was that during our 2 hour training, there was interest from other groups within the company and a variety of comments, but mostly the feeling that we were simply doing "team building" exercises, which is unfortunately only partly true.

Others in the company were curious about what the Team was doing.  This got me thinking...  It's obvious that the people around the "edges" don't know what our processes are and what they are about. This could be a reason for much of our "edge" based confrontation.  Also, there seemed to be some genuine interest from others as our team is clearly becoming very efficient.

I would suggest that if you are in a situation where you are introducing Agile processes into your organization, you spend some time to educate or at least introduce those near the edges to your processes.  They may not understand them or even appreciate the benefits, but they will know that you are working towards a specific way of working.  Peers will have a better understanding of why your team does things "differently".  For me, at least, this appears to have already helped where I am.

Other leaders in the company have been given some basic information about Agile and what it is about and some links for them to follow.  It looks like it was a great idea.  The more transparent we are about our processes, the less stress at the "edges" there seems to be.  What a great feeling.

Mike Caspar

Sunday, March 6, 2011

What to do about team members who do not want to participate

I recently went on a course related to Agile Development put on by Berteig Consulting.  It was about 3 different Agile methodologies.  Scrum (which of course is very popular today), Kanban (Manufacturing Industry readers will know this, but also useful for software development) and OpenAgile, an intriguing methodology with some enlightening ways of handling iterations and team/company dynamics and a central concept called "The Learning Circle". The course was great and it was truly inspiring to see how close teams could get in only 3 short days !

I've becoming more involved in OpenAgile since reviewing the material and taking the course.  Consider taking a look.

While I was at the course, I met a manager (I'll call him Fred).  Fred was asking me about a problem he had related to team members who did not want to co-operate with the Agile processes.

Specifically, his problem was an employee who always chose the easiest work during the selection of which tasks he would like to perform during the upcoming cycle.  In Scrum and OpenAgile the Team members self-organize to best figure out how to complete the work they will perform during an iteration or cycle.  What are you to do about this ?  After reviewing some of the failures and successes of the teams I have been on, I thought I'd share some thoughts about this and Maybe some ideas of my own.

Firstly, for Fred. Of course, Fred has already tried many other approaches including private discussions to no avail.  Fred doesn't want to be forced into a situation where he has has to let one of his senior developers go.  It should be noted, that everyone is not prepared to work in a team environment and you should be prepared to deal with this type of situation or at least see it coming. Hopefully reading this while assist you with some ideas to prevent that from happening.

I suggested to Fred that he line up the team members in front of the Task board and blindfold them and therefore allow them to choose their tasks at random.  The fact that Fred is going to try this, shows he truly wants the individual to succeed and be part of the team.  Of course, as Fred recognized almost immediately, the Entire team will see right through what is happening.  Maybe though, that's exactly what is needed.  Teams have a way of getting non-participating members to join in and pull their fair share without you needing to get involved in that process.  Let the team work it out.  Ultimately, no matter how much you push, you will not be as effective as the team at doing this.  At a minimum, the team will hopefully see you are trying to salvage the situation in inventive ways.

I have had my share of non-team oriented individuals to work with and have had varied success in helping them join the team dynamic.  I would say for me personally, I have noticed that the biggest reason someone does not want to participate with the team is that they fear their team will bring them down and they will suffer for it; whether it be monetarily or through condemnation.  The individual is not "prepared to fail or succeed along with the team".

All you can do is create an atmosphere of non-confrontation, a no-blame environment and an environment where failure is just "part of the process" and to be learned from.  Getting upset at a team member, or specifically singling one out for a failure is the worst thing that can be done!  This will simply solidify the reason they were worried about being on a team in the first place.

As a team leader or manager, you need to be able to take the heat on behalf of the whole team if something goes wrong.  Do not ever allow a problem to be directed at a specific developer or person on your team.

For most team members, over time they see the value of the team working together and start to come around.  Usually as the team starts to form bonds, the non-participant will desire to be part of the work ethic and passion displayed by the team about doing a great job.  They will eventually participate because it simply is more pleasant for them.  Once they get their first benefits of team work, they will be a convert forever.

Occasionally, you may have someone who just is not a team player and never will be. They do exist. Unfortunately, no matter how hard you or the team tries, they will never want to participate.  This is truly a sad experience as likely that person will not stay.  To deny this fact would be a bad idea.  Please do not get me wrong; forcing a group of developers who do not want to work as a team to do so just because Management says so, is also just as bad of an idea.

Working on teams requires dedication to the team, an understanding of one's responsibilities and a desire to work together on a common goal.  The key here is common goal.  A team with no goal will definitely flounder.  I have talked with non-team oriented people and often I find it is not specifically the fear of failure but the feeling that the team itself does not share the same ideals as the individual.  This is the root cause. "They don't get how important it is to make a nice UI", "No one on the team seems to care about the speed of the database" are typical of the types of  responses I've heard from the non-team person.  For each of these, there are some easy ways to address this.

Consider having a team meeting with the whole team explaining how you feel that UI is important and database speed is important (from the example above).  A few comments here.  I would not suggest doing this Immediately.  The rest of the team will think it was just the "complainer" again trying to force his way.  Explain to the individual that you care about his concerns and want to show that you are serious about his concerns.  Explain that you will wait a few days and then bring it up at a random meeting so it does not appear to be specifically from him.  Explain that he will see that his team members are receptive to the idea as well.  Of course, why would they not be :->  Be honest though and explain that you will show him you will review it but you firmly believe in the Team's decision.  If for some reason the team finds something else to be more pressing now, he or she needs to be prepared for the result.  This is what true teamwork is about.

I would like to say here, it would be a very bad idea to come out of a meeting with the non-teamer and immediately force everybody into a meeting about changing the entire teams' goals for this person's specific requirements.  This would only serve to give the idea that they are no longer a team, but rather pawns of the non-teamer.  It's a fine line.  Usually, common sense prevails and over time the team will build bonds over common goals which is when the true beauty of a team will show itself.  Then one day, something will happen (maybe after some new members join, etc.).  Someone from the team will come to you and say, "Hey, I think we could do better with UI and none of the team members seem to care " (which of course will include the original non-team member) :->  It's a great circle of learning and truly enjoyable to watch.

Of course there are many other classic ways to build teamwork skills.  Usually group outings or even video afternoons are a great idea.  There are many books about that topic so I won't talk about that too much here.  The most important thing though is that you need to be prepared to protect a team who is willing to work as a team at all costs.  I have been in situations many times where I have had to choose between protecting the team or my job.  If you plan on keeping your job as a member of a team (especially if you are in management), you had better be prepared to protect your team.  If not, you will find they won't trust you and the game is over.  You might as well leave now.  Trust is a two way street and if your team feels you aren't there for them, you won't be their team leader for long.

I recently learned some very interesting terms regarding teams and how they build.  The terms are "Forming, Storming, Norming, and Performing".  For those of you trying to get teams off the ground, I would suggest learning a bit about these.  I have already passed the information on to my current team and they have already seen that some of their team "growing" pains are totally natural and part of the normal process of team building.  I believe it will be a great help to future team building, especially when bringing on new team members.

The bottom line....There are no magic bullets.  Just stand up for your team and the ones that are non-participants will eventually see the light and/or want to be part of the energy of the team. Things will work themselves out.  Educating your team members about how teams form will help as well.  The education part it a very important part as far as I am concerned.

External references (in alphabetical order):

ps: "Fred", please let me know how things worked out.

Mike Caspar