Mike Caspar Personal Blog Page

Explaining "Why" is important.

2012-02-28T08:40:00.000-05:00

Direction ?

As your Agile adoption grows within the organization, you are going to have to let people know the "why" of the changes that are taking place.

....Read more of my post at agileadvice.com...

What responsibilities does a Product Owner Have

2012-02-28T08:10:00.000-05:00

A fellow Agile Coach, Michael Badali recently made a short, simple post about his ideas about what a Product Owner's responsibilities are.

Read more...

Agile Team Knowledge Retrospective - “Feeding the machine for corporate review season”

2012-02-18T10:36:00.000-05:00

For many Agile Teams in large corporations, the teams are being confronted with “Review Season”. No matter how hard Scrum Masters, Coaches or Team members try and change the corporate culture in this regard, the team needs to SURVIVE.

There are many sources of material about why this is not a great practice for the building of high-performance teams, so I won’t get into that here. I’ve put some links at the bottom of this post if you want to read more.

The purpose of this post is to introduce an alternative approach that will allow the team to regularly reflect on its’ own progress (not just once a year, but when the team decides will work for them), and at the same time possibly (PLEASE read…OPTIONALLY) use that knowledge for their inevitable yearly review.

Yellow / Red / Green Cards

Please don’t get me wrong. I believe teams should be considered as teams and my preference would be to avoid such a situation. The reality is that if your organization is transitioning from non-agile to agile or simply considers Agile to be for isolated teams, you will inevitably have to deal with this. It won’t go away until Agile becomes more mature OR it may never go away.

I started thinking about an alternative to just getting all my team members fired for saying NO and came up with this useful approach that seems to allow the team members to be comfortable and grow with each other, and IF THEY WISH, use that information as food for thought for their reviews. I cannot stress this enough. It HAS to be OPTIONAL for team members to use the information for their reviews. The TRUST relationship between team members MUST remain in-tact.

I originally used a method back in the early 90’s to help my team organize itself to complete a large project involving over 100 cities. We needed a way to improve each few weeks to make the project profitable. Self-improvement and learning new skills as we went was important. Every few weeks (usually 3) we got together to review how things were going and to decide what we needed to improve. What we did was take all the necessary skills, wrote them on cards, placed them on the floor and then had discussions about them from each individual about what we saw going on. It was lots of fun.

I recently saw something similar during an Agile Coaching retreat I participated in with Berteig Consulting.

I had been struggling with how to deal with the inevitable yearly review that was to take place for some newly formed teams in a large company with very strict procedures in place from Human Resources.

I realized that if I combined my experience from the past and with the great reminder from the recent retreat, I could create an exercise that could allow the team members to learn about each other and themselves. At the same time they could receive some “food” or “information” about themselves as it relates to them in their teams for their reviews (that being the secondary purpose). I thought I would try this exercise from my past. It worked well in the 90’s for team, building. Why would it not work now?

The results were wonderful. The team members got to know more about each other, and how the rest of the team felt they could improve to help the team. MOST IMPORTANTLY, it allowed the team members to express what the felt as INDIVIDUALS.

It was a great learning experience and I think could help many teams out. That’s why I’d like to share the idea here.

It is VERY IMPORTANT that you let the team know that what is learned during this Retrospective will be kept PRIVATE and within the team. Please be VERY open about the fact that you are doing this for the TEAM to improve and for them to learn about each other. Sharing the information is 100% OPTIONAL. DO NOT STAND DOWN ON THIS, or you will lose trust from the team.

Let’s assume you have a team which has been together long enough to start to know each other’s strong and weak points. They know what each team member can do for the team. The team will need to have Stormed already and be prepared to talk openly with each other.

I don’t think this exercise will work with a team who hasn’t gone through storming yet, but I may be wrong. I would simply be nervous to try it with a brand new team where trust has not been established yet. I think the results could be bad for team morale. Therefore, please be careful. If you do try it with a brand new team, please let me know. I’d be interested to know how that worked out (good or bad).

Here are the mechanics. Maybe you’ll find this will work for you.

Team Knowledge Retrospective:
A downloadable version is available in PDF format by clicking here.

Supplies, Rules and Guidelines.

For a team of 7-9, it would take about 1 ½ hours to do with proper discussion. For a team of 5, an hour may be fine. I haven’t tried with more people at the same time.
No one is invited except for individual team members. NO MANAGERS!
Make it clear “Our GOAL : Our INDIVIDUAL Contributions to Team Improvement”
Orange 4 X 6 Index Cards (approx. 20 should do). These are used to write “topics”
One Red, Yellow and Green card for each team member.

On the Orange cards, you’ll need to write some topics for the team to discuss. You’ll need to make up the cards the FIRST time. I suggest you don’t get a manager to write them the first time. They may want to control the cards to serve some purpose instead of just helping the team members to get to know each other. If you can, ask a Scrum Master or someone you trust to make the initial batch of cards. It would be best to ask someone who’s been coaching or WORKING WITH the team for a while as they’ll know what things the team might be struggling with or might be prepared to start learning. Just remember, it’s not about what can help the management, it’s about what can help the team grow (which in turn will help the management). I should note, if you have a good relationship with the managers in your area, DEFINITELY get some feedback from them if you feel it’s appropriate. That will have to be up to you.

Here is a starting batch of cards which might work for a Web Development Team.

Scrum/Agile	Network Architecture	French Language (I’m Canadian)
Product Quality	Getting Business Requirements	Development of System Scripts
Talking to Executives	Graphics Design	User Interface Design
Style Sheets	Test Driven Development	Mobile Device Programming
Business Skills	Accounting & Finance Skills	Communication Skills
Public Speaking	Other Programming Languages	Security Design
Infrastructure	High Volume data storage and video transmission (CDN)	Talking to End-Users
Documentation	Automated Testing & Deployment

Spread these cards out over the floor in a way that the team members can easily walk around and look at them without bumping into each other. They should be close enough though so that they feel they are “in this together”.

A sample orange card

Explain to the team why they are doing this and that the results are TOTALLY PRIVATE and that it MAY or MAY NOT be something they will use for their reviews. It’s important to explain to the team that something like this could be used on an ONGOING BASIS and doesn’t need to be restricted to only once a year.

Let the team know that if they like it, they could do it regularly at their option. It will not be mandatory. This allows everyone to be open-minded.

Make it clear there will be 3 ROUNDS.

The first TWO rounds will be for each team member to talk for themselves while the rest of the team listens. The third round, the team member may NOT TALK. The team will talk and the single team member should LISTEN. There will be a follow-up open discussion if everybody wishes.

Make sure everyone understands.

Then hand out YELLOW Cards. Ask each team member to write the cards as follows;

YELLOW – What new thing do I think I would like to learn that Excites Me that might help the team.
NAME:
DATE:
SELECTED:
NOTES:

Make sure they write the word YELLOW in the event the cards get photocopied for future use.

Now, ask the team members to walk around looking at the orange cards on the floor for which card BEST represents them as individuals. Re-enforce that individuality is important in an Agile Environment to help the team. All team members are important. Allow enough time for proper reflection while the team members consider their options. Hopefully you have selected some topics which are appropriate to what you have witnessed as being their needs and desires. Remember, this is for the TEAM.

When each person is standing by a card, explain and remind everyone that the goal here is for “us to learn about each other and what our individual goals and needs are. It’s important for the rest of the team members to LISTEN, REALLY listen to what makes your team mates excited. You will learn a lot from each other (something like that)”.

Ask them to write the EXACT wording on the card they are standing over in the SELECTED: field on the card. Remind them that these cards are PRIVATE and the NOTES section is JUST FOR THEM.

Keep everyone standing. Start at the right or the left from your perspective. Your selections SHOULD be random and not individual, so left to right or right to left will be fair AND ACCEPTED). IF possible, start with someone that you know will be receptive to this process to start the process off (especially the first time).
Ask each person to explain WHY they chose THAT particular card, explaining to the others to “Please listen. This is important to your team member and can really help the team to learn about each other”.

They MAY look down at their cards and start explaining, which should not be discouraged. The “lifelessness” of the cards is what helps here. They are just objects, not emotions.

There may be a tendency for the individuals to talk to you (as the coach or facilitator). Simply find a kind way or gesture to have them talk to their team members instead.You will need to let everyone know that there is a time limit for each team member. Make it long enough so someone can properly express themselves. 5 minutes should be fine.

If someone wants to pass, let them and give them another opportunity AFTER everyone else has spoken. They may surprise you (and themselves). Hopefully, by now the team members are already comfortable talking openly with each other.

When this is complete; do the SAME thing with the RED cards.

RED - What thing would I like to get better at that the team can help me with.
NAME:
DATE:
SELECTED:
NOTES:

Repeat what you did for the YELLOW Cards.

Remind them to write RED for photocopy reasons.

Allow the same private reflection and discussion.

For round 3:

Hand out GREEN Cards with the following format:

GREEN – What does the TEAM think I can get better at or learn to help the team.
NAME:
DATE:
SELECTED:
NOTES:

This time the process is VERY different.

Ask all the team members to SIT DOWN.

Ask for a VOLUNTEER if you can get one to be the FIRST person to try the Green Card. Ask the first team member to STAY SEATED and ask the rest of the team to Stand-up.

The person who is SEATED should LISTEN VERY CAREFULLY and TAKE NOTES. They may NOT say anything. They are to listen.

The rest of the team will wander around the cards discussing what THEY think the BEST card for the person sitting down is and WHY.

They have 5 minutes! The team members may ask if there is a special format. The answer is NO. It is up to the remaining team members to discuss amongst themselves what would be the most appropriate card to select and how to determine this. The ACT of discussing it amongst themselves will force open discussion amongst the rest of the team members as to what they should select. This MAY start off slowly. Don’t worry. Simply count down every minute to let the team know they must come to a consensus. As the time counts down there will be more and more comments (both positive and negative) from the perspective of the other team members. Encourage the person sitting down to only listen and those that are talking to talk AMONGST THEMSELVES and not to the person sitting down. Under one minute, you MAY need to remind them in smaller time increments. The team will eventually select something after a considerable amount of open discussion (which of course is the goal).

The GREEN card is a very important part of the process because it allows team members to know what things they can improve or learn from the team's perspective. The time-boxing is important to keep the team focused on POSITIVE discussion and improvements. Some negative feedback may come out, but it will be done with the intention of giving positive feedback to fellow team members. Remember, the time-boxed goal is something positive. The conversation should quickly return there.

Please give the “sitter” a chance to write all the notes they want.

Explain that AFTER we are done, each team member can talk about their experience if they wish.

Now, each team member takes turns sitting down and LISTENING to what the team has to say as cards are selected for them.

Some team members may learn of new skills that their team members think they might be good at or should learn that they were not aware of or never considered before. The results could be total unexpected, which is part of the experience.

What is important here is that the individual has been given their OWN voice twice and been able to listen to the TEAM’s voice once. It seems to be a very happy mix.

When the selection has been made the standing team members explain why they chose what they did to the person sitting down. You find it easier to just have them say "We have chosen X". Remember, the person sitting down has already heard the team talk about why.

I find this part of the exercise to be the most intriguing and amazing. In some teams, the members will select skills that complement each other. In some teams they select a skill that the “sitter” never expected. In some cases, members will select based on what the person sitting down originally said they had interest in during the first two rounds.

They all really get to know each other as individuals! The team learns how their individual desires and capabilities add up to help the whole team.

A few notes:

The reason for writing the EXACT names on the cards is to avoid specifics and to allow for future comparison. Eventually, it should be up to the Team, Scrum Master, or Coach to come up with some new cards if they feel it would be appropriate.

Likely, your managers will want to get involved in this. Deal with that the way you wish. My preference would be to obtain some input from the management and include their ideas IF it would be to the benefit of the team. For me at least, it’s about what the team needs. The management does have needs though as well which should be considered. If you can do it, it might be a good idea to ask for input (if not at first, but for future sessions for sure).

A card such as “Working more overtime” is of course inappropriate. If the manager knew they were trying to break into a new “Wireless” domain in the market, a card such as “Wireless Networks and Technologies” might be a great idea. Maybe no one will pick it. This is also not a bad thing. Perhaps the management needs to know that "Wireless Networks and Technologies" aren’t important to their staff and the company needs to do some education into the corporation’s future path. The message has obviously not been communicated properly. It’s just important the cards stay consistent for a while so there is a point of comparison for TEAM MEMBERS.

There may be some unintended positive results. The team, Scrum Masters and Coaches now have a “common vocabulary” for discussing team member motivations and ideas.

I found that after this exercise was complete, if I was sitting with a team member and wanted to help them to proceed, I could FIRST ask them “What was your Red Card if you don’t mind me knowing?” It was a great way to make sure that I was in touch with what the individual’s goals actually were instead of mine.

Encourage the teams to do this OFTEN. It allows them to really get to know each other as team members and improve as a team.

A happy by-product of this is that they have the OPTION of using that information for their yearly review process to make it less painful for themselves (and their managers).

I hope this method helps your teams to become more effective and to get to know each other better as individual contributors to the common goals of the team.

Mike Caspar, CSM, OA2

Links and references:

Storming: http://en.wikipedia.org/wiki/Tuckman's_stages_of_group_development

Download Instructions as a PDF: Download PDF

Berteig Consulting: http://www.berteigconsulting.com

OpenAgile: http://www.openagile.com

SCRUM: http://www.scrumalliance.org

Yearly Reviews and Agile :

This work is licensed under a Creative Commons Attribution-ShareAlike 3.0 Unported License.

This document may be reproduced in-tact without modification and retaining the attribution to Mike Caspar, 2012.

VOIP Phones can help Agile Teams in a Large Corporation

2012-01-21T12:37:00.002-05:00

I recently had a discovery about the value of VOIP phones that I never noticed was there for an Agile team.

Many team members in large companies are required to work in cubicles. Although, not a fan of the cubicle in the work-place I wanted to share a tidbit that might help some of your teams out.

Use a VOIP Based Phone System which supports DHCP.

VOIP phones can use DHCP to obtain IP addresses and settings automatically wherever they are plugged into the corporate network. This means a user's extension, phone settings and voice mail can move from one place to another without any significant work other than moving computer and phone and plugging into the right connection.

It might be a good idea to color code for "computer vs. VOIP phone" (if needed), but other than that, it's a pretty self-sustaining thing requiring no work from facilities.

What this means is that team members can easily self-organize and move themselves around As-Needed to whatever works best for them without needing to contact the "Desk Police" or Facilities in the organization. This can save the corporation significant expense.

After all; a team knows better than anyone where their new "test based thinker" should sit or where the "temporary subject matter expert" should sit to be effective with the team.

Of course, respect for size of office or cubicle, not stealing desks from another department and common sense still need apply. Setting a few "guidelines" makes sense. I have found that team members will generally make their own rules to ensure this doesn't get out of hand, so no need for managers to get involved.

If you're in an environment where Agile is the "frame of mind", then flexibility MUST be the norm. A wired phone system requires constant expense and work from the Facilities Department in your organization. An IP based phone system using DHCP allows teams to easily and quickly self-organize on their own.

Do not forget. When having Agile Meetings, Managers, Stakeholders and clients have busy schedules as well.

2011-12-31T13:42:00.000-05:00

I wanted to make a post about a disturbing trend I've been seeing in different Agile environments.

Agile Methodologies give the team members a certain level of respect and Responsibility.

Team members are empowered to self-organize, reach out of their teams, arrange meeting rooms, and basically Get the Job Done.

Product Owners, Managers, Project Managers, Stakeholders, Clients, and many other people are part of regular communications with team members where there was none before. This includes but is not limited to the Planning and Review meetings, constant email, voice and personal communication. This may be a new experience for many team members. In an environment where SCRUM or OpenAgile is NEW to the organization, this can be even more of a concern.

If for instance, your team has arranged a review meeting for a specific date and time, you REALLY should make a point of being there on time. After all; you are expecting other people in the organization to show up so they don't slow you down.

If you are a Scrum Master, acting as an OpenAgile Process Facilitator, or simply anybody interested in Agile as a framework, please consider not showing up for meetings on time to be a serious Obstacle or Impediment to success.

Those that are invited are supporting you and treating you with the necessary respect to allow you to work in an Agile Environment. The same respect is due in return.

Leaving a VP, CIO, CEO or any stakeholder sitting in a room waiting for 30 to 45 minutes while the team members meander in is not appropriate (and not very wise) in ANY environment. The difference when applying SCRUM is that this type of behavior, is MUCH MORE OBVIOUS and transparent to the organization.

Those same people you are making wait will some day need to stand in a room to fight for your rights as a team. They may need to explain to another executive why they should make time out of their busy day to attend a team meeting and put other business off for an hour.

Agile is not an open license to treat others as though their time is not valuable. The reason an Agile framework is successful is that it allows managers and those that used to "control" you to do other tasks which have their own significance and importance to the company or group you're in. They are ALSO busy!

Mike Caspar

----
References :
SCRUM
OpenAgile

The Pursuit of True Agility and Jazz Music

2011-12-12T20:49:00.002-05:00

A manager I am working with recently sent me this link. I have seen this topic discussed before, but never so nicely worded. Thanks Charles.

It is a discussion about how Jazz music is different than Classical music and how that knowledge could help to understand Agility.Great post. I think we'll hang this on the wall somewhere in the team room.Read more

Scrum Master, Process Facilitator, Growth Facilitator. Managers or Leaders or Neither?

2011-12-09T06:37:00.000-05:00

I have recently read abook my brother-in-law let me borrow titled First,break all the rules *¹.

It is written basedon results of a survey by Gallup of over 60,000 managers at 400Corporations. The book is based on writtenand actual in-person interviews. It has aninteresting concept regarding the differencebetween Great leaders and Great managers.

In short, the definitionsare as as follows;

-Great Leaders focus OUTWARD. This includesthinking about how the group, business unit, section, division, corporation,community will interface, operate and thrive in relation to the external world as his/her group moves into thefuture. The leader looks for upcoming obstacles, competition, market trends, and opportunities for growth within their realm. That realm could be at any level down to the smallest business unit or small group of people.

Great Managers focus INWARD. This includes thinking about the personal interactionbetween the people and businesses in their care. This might include providing feedback on waysto improve, recommendations for training, guiding career futures, and helping theirunit work efficiently as a group. Insome cases, managers will have direct impact on what and how the employeesunder their care will grow and learn.

I spent some timetrying to figure out how to map these ideas to the Scrum Master, Coaching rolesand to the Growth Facilitator and Process Facilitator capacities of Open Agile andhad some trouble with the mapping.

This got me thinking.

This MAY be the reasonwhy corporations have such a hard time defining the roles and fitting them intotheir structure.

Where does the OpenAgile ProcessFacilitator fit? A Process Facilitatoris neither. Well, maybe more of amanager?

What about the OpenAgile Growth Facilitator? Is that capacity more of a "leader"... Hmmm... doesn't quite fit.

The Scrum Master role iseven more obscure in this comparison.

The Scrum Master is notmanaging anyone, yet still enforcing the rules of Scrum, encourages theimprovement of skills and agile techniques and assists to protect the teammembers from outside interference. Theseclearly appear at first glance to be Manager attributes. However, the Scrum Master is not a manager.

The Scrum Master is lookingoutward for potential obstacles, working to try and grow Agile in theorganization and working hard to try and teach others as to its’ goals andpurpose. These appear at first glance tobe the role of a leader. However, theScrum Master is not a leader.

I now can see whyCorporations have such a hard time identifying the Scrum Master in theirorganizations. Scrum Masters basicallydon’t fit either category, yet most corporate hiring is done based on hiring of“leaders” and “managers”.

Interesting (to me atleast) :->

Mike Caspar

References:

OpenAgile http://www.openagile.com

Scrum http://www.scrumalliance.org

Gallup http://www.gallup.com
*1 FIRST, Break all the rules; Marcus Buckingham & Curt Coffman

Be truthful about working in teams! It's not for everyone

2011-10-29T10:28:00.000-04:00

I have beenthinking about some of the conversations I've had recently and in the past withdifferent team members and realized....there seems to be very little discussionand truthfulness about the reality that high-performance teams are not foreveryone. Some people will just never like it, some will tolerate it, some willlove it, and some will just simply move on.

So much timeis spent on the rah, rah of how great it will be for everyone, we need toremember to pay attention to the natural reactions and concerns of those thathave never experienced a high-performance team before.

Speaking asa developer myself, I remember how I started in I.T. back in 1984. Someonepresented me with a problem, and I sat in my apartment by myself working my ownhours, watching TV, working through the night and generally being a loner. I do admit, I enjoy those days.

My companygrew and eventually I found myself working with different types of people;developers, marketing types, sales people, accountants, graphic artists andmany more.

That's whenI discovered something I enjoyed MUCH more.... Working in Teams!

But whatabout those that are unsure about what to expect.

My advice...Be TRUTHFUL and LISTEN.

For thosethat have never worked in a high-performance team environment, the change canbe frightening. Allow new team members to talk openly about their fearsand concerns. Show them that you care.

The concernsmay not be real to you but they are definitely real to them!

Consider thefollowing situation;

· Youare working with a new team that has been told they are doing an Adoption.
· Theyare comfortable working totally on their own and interface with other team membersonly when necessary.

Ournatural tendency will be to try and minimize their negative feelingsor concerns.

After all,we totally believe in Agile and really just want them to come around to our wayof thinking. Instead, allow the person to say what they have to say andthen be honest with them.

Explain tothem that “Teams are NOT for everyone, and ask them to PLEASE give it a tryfirst and see how you feel about it in a year from now”.

“The goal ofthe company, me and everyone in the team is that you're here and enjoy it goinginto the future! I am here to help you in the transition.”

The LAST thingyou want to do is try and convince that person that their fears are not valid. They are valid to them. Explain that you are there for them to talkto at any time.

Explain thatyou believe in your heart that they will never want to go back to a non-agileenvironment. Don’t be afraid to talk about your own skepticism when you first started with an Agile team.

I personallyfind that honesty and truthfulness about the situation is the best way to approachthe subject. The recipient will gaintrust in what you say. After all, if you are willing to be honest aboutpossibly attrition, then they will realize you are being truthful about howthings might be if they ride it out.

For me atleast, the people who have argued with me the most about joining teams havebecome my biggest allies when a management change happened and the POSSIBILITYof breaking up the teams even came up in conversation.

My experienceis that the honesty and rapport you built up with the person who was"worried", "not sure", "didn't think they would likeit", etc. will be beneficial to both of you. The truthfulness you showedabout their situation will help that person have a healthy, open-minded view towhat will happen next.

Consider howmuch easier future changes will be when the person is totally aware they may beuncomfortable with them and is willing to give it a try.

A thought about Verbal vs. Written Communication in Teams

2011-10-22T16:02:00.001-04:00

The topic of verbal vs. other forms of communication has come up for me a fair bit recently with a friend of mine trying to keep an off-shore team working efficiently. His teams are using OpenAgile as a framework.

I decided it was time to make a post about the subject.

I came up with this example as a Flight Instructor when explaining to students about the difficulties that air traffic controllers face when talking to pilots on the Radio. The controllers cannot easily hear inflection in your voice, so the words used are very important and need to be completely accurate and follow specific rules.

This idea is even more significant when discussing the idea of ‘documentation’ or ‘email’ communication between co-workers and/or team members.

Consider the following phrase which is purposely designed to invoke emotion.

I NEVER SAID YOUR WIFE WAS UGLY.

Every person who reads this will read it differently!

Let me explain..... Follow this explanation by saying each of the following OUT LOUD.
The learning will be better that way.

The () characters are the explanation of the different possible interpretation.

Put a loud or raised emphasis on the bolded word.
Say the rest of the words without emphasis.
Leave a few moments before each attempt.

Here we go…....

I NEVER SAID YOUR WIFE WAS UGLY.	(Perhaps implying someone else did)
I NEVER SAID YOUR WIFE WAS UGLY.	(out right denial)
I NEVER SAID YOUR WIFE WAS UGLY.	(although I may have written it)
I NEVER SAID YOUR WIFE WAS UGLY.	(but I may have said someone else's is)
I NEVER SAID YOUR WIFE WAS UGLY.	(but perhaps your dog is)
I NEVER SAID YOUR WIFE WAS UGLY.	(but she is now)
I NEVER SAID YOUR WIFE WAS UGLY.	(I said she was beautiful)

As you can see, I may have had an intended purpose for my message to you. However, your interpretation could be considerably different than what I had hoped for.

Agile Frameworks such as OpenAgile or SCRUM, rely on high-bandwidth communication between team members.

Consider this example next time someone tells you that written communication is as effective as in-person or webcam verbal communication between members in high-performance teams.

If you are in an environment requiring remote communications, make sure that the remote workers have access to high-bandwidth communications capacity within their teams.

OpenAgile - http://www.openagile.com
SCRUM - http://www.scrumalliance.org

Disclaimer

2011-10-22T15:11:00.000-04:00

Once in a while, I need to re-post this disclaimer.

Any posts or comments in this blog are simply MY PERSONAL OPINION and not to be considered as any recommendations or facts provided by any manufacturer, employer, client or associate.

How to Introduce a Test Driven Mindset

2011-09-05T20:02:00.000-04:00

Recently, I was helping a friend of mine introduce OpenAgile into their environment. They are a software development house with some local and some overseas developers. I am occasionally following up with my friend to see how they are doing.

Their development has been going well since adopting Agile practices with the exception of a recurring problem with "returning bugs".

A bug will be discovered, fixed, and then several weeks later will show up again after some other modifications. This is a sure sign that Test Driven Development is not happening.

Consider the following:

There is a master data entry screen called "Shipment Entry". The first field on the form has a "Shipper" field that allows the entry of a Shipper Code.

If you press CTRL-N, you Should get a sorted list of Company Names ordered by CompanyName, paged 20 at a time, with a smaller selection if some of the characters of the company name have been filled out. The resulting list should appear within 3 seconds.

Today you downloaded the code, recompiled and find that the drop down does not sort anymore.

You know that you have fixed this before.

Introduce the Test Driven Development Mindset.

Instead of opening a ticket, sending an email, complaining or whatever your process is, consider trying the following and introducing something like this into your source / version control.

Shipment Entry Screen Tests
Shipper	Field is Empty, CTRL-N pressed	List Appears, paged 20 at a time, sorted Alphabetically by Company Name within 3 seconds
Shipper	Field has "ABC", CTRL-N pressed	List Appears (filtered to show all companies containing "ABC" in the company name), paged 20 at a time, sorted Alphabetically by Company Name within 3 seconds
Shipper	Field has an invalid entry "INVALID", CTRL-N pressed	Within 3 seconds, a pop-up appears indicating "NO COMPANY FOUND", the shipper field is blanked and the cursor is returned to that location. The popup disappears.

If any developer works on that screen, before checking in, they need to do all the tests on the SHIPMENT ENTRY TESTS document to ensure they have not broken anything.

Don't get me wrong. The idea is not to document the entire screen up front! Try to avoid designing the ENTIRE UI up front in this way. That has it's own non-agile problems. This is just an easy way to introduce future changes using a different mindset.

In my example above, there is a field called "Mode of Transport". It currently shows a list of numbers which internal employees "KNOW" from years of experience with the application. When that number is selected, it gets converted into something like "MAIL", "COURIER", when it is printed on the final document. Your team has agreed to do work to have it show the appropriate labels in a drop down on the screen.

Traditionally (non-test mindset), you would send out an email or open up an issue with a request for this change. Then, the cycle will continue again. As time goes by, you will always need to re-check this is working properly.

Try something like this instead:

When you have finished your planning and have decided this "story" or "feature" will be introduced to this cycle or Sprint, simply modify this document as follows;

Shipment Entry Screen Tests
Shipper	Field is Empty, CTRL-N pressed	List Appears, paged 20 at a time, sorted Alphabetically by Company Name within 3 seconds
Shipper	Field has "ABC", CTRL-N pressed	List Appears (filtered to show all companies containing "ABC" in the company name), paged 20 at a time, sorted Alphabetically by Company Name within 3 seconds
Shipper	Field has an invalid entry "INVALID", CTRL-N pressed	Within 3 seconds, a pop-up appears indicating "NO COMPANY FOUND", the shipper field is blanked and the cursor is returned to that location. The popup disappears.
Mode of Transport	Entry into Field	Within 1 second, when entering this field, a drop-down list appears show full descriptions, sorted alphabetically by Mode of Transport.

Granted, the tests will eventually become cumbersome. However, please remember that someone will eventually be testing these screens and find these bugs in a never ending circle. My friend found that every morning they were having to go through all the screens to see what "new things" were broken.

Why not just try to get it right during your Cycle or Sprint ?

In the above example, as soon as someone takes on this task, they will have a failing test (Red), they will do what they need to do to get the test to pass (Green), and then will adjust the code to be efficient (Re-factor).

Although Test Driven Development is better done at other places in the code, this is a great way to introduce the "Mindset" into your team.

Someone will eventually say "This is getting to be a hassle. Can we automate it somehow?", which as an Agile person is exactly the words you eventually want to hear.

Maybe now, you can start to introduce it at the Unit Test, or Functional Test or whatever level is appropriate to your organization. There are some more formal ways of doing TDD such as Extreme Programming (XP).

The important thing is that your company will have shifted to a Test Driven Mindset.

The quality of your product will increase and stay that way and the need to go back and fix old bugs in a never ending cycle can soon be a thing of the past.

OpenAgile

Scrum

Extreme Programming (XP)

Where should I sit?

2011-08-21T11:25:00.000-04:00

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!

References:

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

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

2011-08-01T15:55:00.001-04:00

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.

Summary

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 - www.openagile.com

Remember that Agile is about Quality and Business Value

2011-07-10T15:25:00.000-04:00

Recently, I had an interesting discussion with a companion about Agile Processes and the need for corporations, communities or groups to change their approach to planning and doing work. We were discussing using OpenAgile as a Framework.

The person I was talking to told me that their group (Artists) were already used to and embraced the idea of shared responsibility, self-organization, mutual respect and open discussion to get things done. OpenAgile (as well as Scrum) require open communication and truthfulness to be effective tools for self-organization.

My friend then told me how it made sense in the Art Community but it would be hard for Financially minded people to believe in what Agile was about and that it would be even harder for financially oriented educators (ie: Universities and Colleges) to change their minds about teaching Agile processes as a primary part of the education system.

Then it struck me.

For many people, they hear FIRST about the need to share work, how the organization changes, how people are treated better and all the usual comments.

I realized I need to change my approach with these types of people to first discuss how agile processes work to benefit Business Value and Quality. My 15 second elevator speech should start with these ideas and not the other way around.

I don't know of any business leader, financial manager, non-profit CEO or educator that would think it to be a bad idea if I said to them "Listen, I would like to show you a way to do the most valuable things first, with exceptional quality while at the same time consistently getting better at it. Oh, and as a by-product, you will also have more engaged, long-term staff. What do you say ?".

We must admit that OpenAgile (or any other Agile process) is not a silver bullet to be used everywhere for all groups. I have however found that after teaching about iterative work and the IDEA of Business Value and Return on Investment, even a "non-agile" team can still benefit from some of the procedures or "routines" of a fixed cycle of learning and it's heartbeat.

All of the new ways of doing things including culture shift, team based work, etc. would be unfortunate for a business without first remembering that the purpose is to provide Quality and at the same time provide the items that have the most VALUE to the organization.

Quality is an inherited part of the process of going Agile. As more discussion happens and all people in the team have input into the process, inevitably, you should end up with a better result. The customer has more direct input into the final product as it is being created, therefore helping to achieve a result that everyone is happy with.

The real goal to business is this Quality, and the way to get there is all these things that Agile asks us to do, through a continual process of learning.

Business Value. This means different things to many people. Where you are using OpenAgile, Scrum, XP, Pomodoro, remember, the goal of all of these is to work on the tasks that will provide the company or organization to most Business Benefit First.

When coupled with the idea of Return on Investment, the reasons are just far too compelling to an organization to ignore. After all, no organization of any type can afford to exert effort with no return at all in the form of artifacts of some sort. Every organization is there to create some kind of result (value) in its' chosen field.

Most organizations have many different opinions and reasons for considering one item more valuable than another. You will likely find that most people think ALL of their backlogged items are of equal value to a project or company.

The idea of doing work based on Return on Investment takes some of the emotion out of this process to allow work that is clearly more beneficial to the group to take precedence.

When a task is determined to be of lower value (not because of just value, but work for value) doesn't make it into this cycle, it MAY well be classified as a higher Value for the next cycle, and therefore, it's Return of Value / Work may be higher and bring it up the work scale through this process.

There are several ways to accomplish this. One of the easiest is by breaking the item to be done into smaller pieces. It's Value will remain the same, but the work (effort) required to complete that smaller piece will be less. Therefore, the new smaller task will have a higher Return on Investment and be done sooner.

The idea is that true business value is what is provided first with many competing priorities. Most of us don't have the ability to just add two or three more teams when more work comes along, so there needs to be some logical process to deal with this.

For my friend in the Arts who is wondering about the Financial Elite having a hard time doing a mental shift towards Agile processes instead of Waterfall processes, consider the conversation about Return on Investment and Quality of the Final product as your starting point. THEN let them know, "Oh ya. you'll also end up with less turnover and happier employees". :->

Mike Caspar

References :

OpenAgile - http://www.openagile.com
Scrum - http://www.scrumalliance.org
Pomodoro - http://www.pomodorotechnique.com
XP - http://www.extremeprogramming.org

WHY? .... Such a valuable question

2011-06-19T10:15:00.006-04:00

Recently I was watching a situation with a development team where a very important question seemed to be forgotten... WHY ? This got me thinking about the countless times I have seen work done for no apparent reason than it's "On The Wishlist", "We have a card for it", or "Because Customer Service Says So".

Many times I have seen features get created where at the end of the release, the final user of the feature says, "Oh, we haven't needed it to do that for about 3 months now". This part of the requirements is long gone.

This brings me back to Waterfall Methodology and something I would expect to see. With it's linear approach to the Software Development Cycle, it is almost to be expected that there will be some waste of this nature. This is not to say that Waterfall is never appropriate. It is just an expected part of the process if you have a long development cycle.

However, using an Agile Methodology such as Scrum or OpenAgile, this should simply not happen. Agile methodologies are based on Communication. This communication is paramount during the Sprint or Cycle but is absolutely mandatory during the planning meeting. A team cannot simply be given a list of instructions to follow. The team needs to understand what their Goal is.

In Scrum, the Product Owner is responsible for guiding the team as to which features should be queued up next based on Return on Investment (which generally means actually needed).

In OpenAgile, the team has a similar approach of consultation with the "end user' and the planning of work based on Return of Value, and plan appropriately.

Although in Scrum and OpenAgile, there is discussion about Return on Investment, Value, bug free code, Test Driven Development, etc. there often appears to be little discussion about the idea of why we are doing something.

User Stories, if done correctly can significantly improve this problem because the "story" needs to have a goal as to who benefits. We are doing this Feature for this "x" to get this benefit.

It is however, the responsibility of a Team to ask "Why would someone want to do this ?", or "Why are we updating this information in the first place". Often, the insights are very revealing.

Let's take a simple example.

I the late 80's, I was working as a developer with a company where the company's approach was to provide the developers a "requirement" , choose a developer and send them off to do the work (pre-Scrum days).

The developer was to modify a Stored Procedure to go through a table and update every 3rd record in the table to be 50% higher. It was a fairly complex procedure and a developer at this company spent almost a week re-writing the procedure and getting it implemented. The development team sat down with the engineers and customer and developed a method of testing and verification, backups of the database were made and the implementation work began.

No one asked Why.

Several weeks later a similar request was made in a different part of the system. I spent some time with the developers and encouraged them to ask Why the first modification was made. The answer was "That is what Sherry said to we should do. The customers are yelling and this is what we need to do to fix it".

Those of you using Scrum or OpenAgile are probably already cringing and thinking.. Gees... you could write a book just on this one paragraph alone. I'll leave that for another day :->

The actual problem was there was a different part of the system which updated the tables based on Quarterly Results. This was the actual reason every 3rd record in the table was wrong. That procedure was incorrect and shared by other parts of the system.

If someone had not stepped in, this cycle of fixing the by-product of the defect could have gone on for many more months.

I convinced the owner to change the procedures to allow the developers to ask questions as a team before work was queued up. I simply asked for this one simple right.

A few months later, the overall bug rate of the application went down, customer complaints went down and the development team started to feel engaged and part of the process. It was a different place after that. People enjoyed working there.

As part of the planning stage of your Sprint or Cycle, please consider asking questions such as

-Why are we changing the Field Size from 80 Characters to 250 Characters ?
-Why should the system need a procedure to update these types of records .. Doesn't the system do it properly ?
-Why would we want to force through Credit Card Transactions without the CVV Code (the security number) ?
- Why are we making a whole new authentication system ?
- How did this become a requirement ?

This type of question is not intended to be a confrontational thing! Often those requesting the features may feel that you are being confrontational. Remain calm, and make sure to let the requester know this is a standard part of your process and not a question of their power or knowledge. The goal is to get knowledge, and not to figure out who is right or wrong.

After discussing it with the person, you may find they do not have a true understanding of why they are requesting the feature or change. It is possible the idea of what or how to do it will change just from the communication alone (which is when you want it to happen.. not after it's done). The discussion may also allow the product to be better than they originally envisioned.

OpenAgile has a term called "Consultatative Decision Making". It is the idea that decisions are made based on consultation and discussion with all those involved that may have valuable input to making a decision.

Scrum also values discussion and communication as a fundamental part of Development.

The FIRST value of the Manifesto for Agile Software Development is "Individuals and Interactions over processes and tools"

In the case of the example above, we chose to fix the stored procedure which was creating the bad data and wrote a one-time script to adjust the corrupted records. We never had to revisit this problem again.

It sounds simple enough, but the basic premise of WHY is absolutely mandatory to this process or all decision making will be based on following instructions blindly with no sense of ownership by the team.

Just a thought.

Mike Caspar, CSM, OA2, ITIL v3, ATPL

References :

Scrum - http://www.scrumalliance.org
OpenAgile - http://www.openagile.com
Manifesto for Agile Software Development -http://www.agilemanifesto.org/

Why is hardware being forgotten by development companies?

2011-06-01T19:25:00.002-04:00

This week I met someone while on a personal trip who is in the software business. His company writes software for a very specialized vertical and from everything he said to me, they are an innovative company and do all the right things including empowering their teams to self-organize, regular training for the staff and generally a great working atmosphere.

The company has still been struggling with getting their product to be "deeper" (his word) for their client base.

I was again reminded of a post of mine from a while ago encouraging or providing cross-training or at least some knowledge to bridge the barriers between the software group and the hardware group (link at the bottom of this post). In my environment, I've been fortunate to have a network admin sitting with our team. It has prevented many potential problems.

Having been involved in the infrastructure part of IT as well as development, I knew of at least a few products almost immediately that could make his product more compelling to his customers. To my surprise, I found out his company was only looking at software improvements to their application. He told me how they are continually developing new features but are not considering running on any new platforms.

I mentioned a few technology (hardware) improvements he could consider and I know that by the time he gets home this weekend, he will have taken a look and passed the information on to his team. These improvements could immediately add significant customer retention and usability to his product.

From our discussion, it was also evident that his team would enjoy the challenge of some new platforms to keep encouraged about the future. I'm sure that by the time he reads this, he'll have some of these technologies in hand :->

As Agile practitioners, it seems, we are so focused on improving our software development cycle, our specific development tasks, our daily or hourly builds, our programming skills, and how we create story points, sometimes we seem to lose track of the big picture... What is the customer going to use it on? This should be fundamental to every developer's thought processes.

Think to yourself, "HEY, should we be seeing if our software could run on some of the new technologies out there such as Microsoft Surface, some of the new Wireless Devices, or even benefit somehow from new 3D technologies coming out"?

I like to think that developers who are empowered with information about hardware can think of all kinds of ways to use it.

If you're on an Agile Team or managing one, ask to learn something about the hardware in your environments. Consider some "slack" in your Sprint or some work breaks in your Cycle to allow team members to learn something about new Infrastructure or Hardware products.

Think for a moment if your company is writing software for the Web, the power of a deep understanding of how a load balancer actually works, or my personal favorite, the .NET Cache.

Let it be the teams' choice of which products though. That will give the best motivation and most likely will be the most enjoyment for everyone.

It will broaden your horizons and perhaps give your team ideas you never knew could even be possible.

If we always just wait for a Marketing Person or Product Owner to come up with interesting ideas, where's the fun in that ?

Mike Caspar

References :
My previous post - Infrastructure Knowledge for Developers
3D example - Sony 360Degree viewer prototype
Microsoft Surface - Microsoft Surface Web Site
Slack - A good article about slack in XP by James Shore
Sprint - Scrum Alliance
Cycle - Open Agile

A great example of agile style teamwork in a non-software environment

2011-05-22T10:04:00.000-04:00

I am regularly asked for examples of where Agile Practices could be used that are not related to software development.

I recently came across this video and just had to share the link to it.

The company encourages all team members to participate, keeps things time-boxed and makes appropriate use of subject matter experts.

It's awesome to see what can be done in 5 days.

http://www.youtube.com/watch?v=M66ZU2PCIcM

Teams are important when doing Agile .. Not just processes !

2011-05-13T13:13:00.016-04:00

(This is a motivational story about teams).

Scrum, OpenAgile, Whatever your flavour of Agile, there are rules, procedures and guidelines to follow.

Consider them as Frameworks to work with. Many ideas are different between them, and each Framework has different uses with an organization. There are however, a few things they have in common..Process guidelines, Cycles or Iterations, and an emphasis on Team Based work or Team self-organization.

Over the years I have discovered that whenever Process is involved, there is a huge temptation to talk about processes and cycles and forget about the people who need to follow them. The Team. Without them, none of these things can take place.

I am not talking about "calling" a team a team, but simply just "having" them.

It seems like such a small distinction, but really, the results are very different. Some interesting books on this topic include; "The Orange Revolution" by Adrian Gostick and Chester Elton. , and The Wisdom of Teams: Creating the High-Performance Organization" by J. R. Katzenbach, Douglas K. Smith

I started my company back in 1984 and never realized at first, just how important the contributions of more than one person could make to the outcome of a project. Over time I learned that teams are (to me at least), the only way to grow and keep customers happy.

Learning and getting used to the ideas were not easy at first and many mistakes were made, but in the end, I am so glad I stuck it out and kept working on it.

I was recently reminded of a team story I can share where my team truly performed beyond all expectations and wanted to pass it along as a sort of "just believe in it" kind of message to those that are interested.

Here's the story....

In 90's, I ran an Internet Service Provider Business. It came about because of a process I had realized would work for Ocean Transport Companies where EDI data could be transmitted along with normal email and be sent over the internet (the days of $ 800 / month invoices for 2400 Baud Connections to the Internet).

Through the process of meeting new clients, I met the director the Canadian division of a worldwide Shipping company and sold him on the idea. He has offices in Toronto, Montreal and Vancouver with partners in those cities and was part of a larger worldwide organization headquartered in Antwerp, Belgium.

Local partnerships were setup in countries where the company did business. At the time, they had approximately 115 offices around the world, in North America, South America, Africa, Asia and the Middle East. Canada was one of those "sub-companies".

The services were working very well in Canada and eventually I was invited to attend a partners meeting in Miami to review the process with managers, owners and stakeholders from North and South America as well as the CEO , who was based in Antwerp, Belgium.

I did a demonstration for the group members there and was presented a great opportunity. The CEO from Antwerp asked me "How long would it take you to get my 750+ employees in Antwerp so they can have internet email as a pilot project for the group ?". My answer to him was that I believed we could pull it off in a few days (which would result in it being completed before our 4 day meeting in Miami).

Now comes the great part... Late that afternoon, I made a phone call to the junior support person and asked "Roy, could you please do me a favour and see if you guys can find a way to get the customers' network in Antwerp onto our system as quickly as you can. "Sure" was the response I got. That was the extent of our conversation.

I could not have asked for a better team!

The next morning while we were arriving at the pool ready to start the day, the CEO from Antwerp came out with a big grin on his face and showed everyone an email he had received overnight to his new internet email account through our service.

It seems that not only did the installation get done overnight, but a large number of the Antwerp staff were already sending and receiving messages through the new service.

I could never have pulled this off on my own and could never have had this happen if the team was not empowered to make decisions.

I am a firm believer that if you give the employees the power to make positive contributions to the company, it's simple.... They will.

Within a few months, I was invited to a two week meeting in Cape Town, South Africa with the owners and managers of all the other International offices and did the same review.

Because of the success of the team and the implementation, we started on a large project to integrate more than 100 offices around the world.

Our team managed the installation, implementation and integration of all these offices together with teams from the client's IT department. The entire system was implemented well below the original budget estimates and in approximately half the original estimated time.

I eventually moved on to other things and am still great friends with the Canadian Director. The company was eventually sold to a larger organization.

As far as I know much of the initial "design" is still in place and being used including their own EDI standard.

Of course, as technology has changed, some of the mechanics of transmission have changed, but the project is still considered a success many years later and is the foundation for most of their current communication environment.

I could never have accomplished this without such a great team who really was concerned about doing the best possible job for the customer.

References :
-The Orange Revolution - Adrian Gostick and Chester Elton
-The Wisdom of Teams - J. R. Katzenbach, Douglas K. Smith
-Open Agile - http://www.openagile.com
-Scrum - http://www.scrumalliance.org

All you need is a bit of patience. Just be consistent in your message.

2011-04-30T13:46:00.002-04:00

As many who have tried know, an Agile Transformation in a company is not always an easy process. Although most people at first are keen to participate in the idea of "changing" the company culture and working environment to "something better", many do not realize how much work it can actually be.

For some of you, you will be fortunate enough to be in an "Agile" environment already.

Perhaps you are using OpenAgile, or Scrum. You may be using a unique variation such as the Pomodoro technique.

For those of you that are new to the idea of Agile Processes, no matter what your flavor of framework or tool, there is something you will not be able to avoid. Politics.

There is no getting around this. Agile transformations are about change in an organization and not just change in one small section of the company.

Although many Agile teams start as "pilot projects", even in such small situations, the effect on the departments or culture at the "edges" of even the smallest teams can start to cause ripple effects in an organization.

The first secret is to acknowledge and accept that this is going to happen. Life will be easier for you this way. The job of any one assisting with an Agile implementation is to provide honest information and advice to help those who will be directly or indirectly impacted.

Don't think you will be able to just hide in development and not be noticed. Be prepared with slides, web site links, and open to talking about your processes and ideas with anyone who wants to know. You must be transparent and open about what you are trying to accomplish.

OpenAgile for instance is defined as a "Learning System" because it deals with the realities that no one can work in a bubble and that more than just the "development team" needs to be involved in Agile practices for them to work. The entire organization will be learning with you.

Scrum has a well defined set of guidelines to follow in regards to the development process and is ideal for new software development projects.

Lean is a more gentle approach to changing an organization in small, progressive steps.

Don't kid yourself. No matter how small the changes will be, there will be resistance from someone, somewhere, from where you least expected it.

The important thing to remember is what your goals are. The goal of the framework is an open and honest discussion between all those involved in your organization and general culture shift to a blameless, team based shift in thinking.

However, what is the real goal here? Happy customers, happy employees, and therefore, a profitable, progressive organization. You must remember the purpose is not to make teams, but to make a good product for the customer. Sometimes, you may find it hard to remember.

I recently read The Wisdom of Teams: Creating the High-Performance Organization (Collins Business Essentials) by Jon R. Katzenbach and Douglas K. Smith. It clearly explains, with examples, how an organization with the courage to change their culture can really benefit from an overall culture shift towards Consultatative Decision-Making and team work based approaches.

Consistently, companies who simply "say" they have teams under-perform those that actually "just have teams". One type of company has them by edict or decree, and the other just has them because the culture is that way. The ones with the naturally team based cultures do much better financially. Hmm..interesting.

Change is usually started by some kind of need to change because things aren't working out "the old way".

Buggy software, unhappy customers, late releases...Whatever the pain, the results are always a "desire to change".

Those who have the courage to admit they need to change, should be applauded. If you are new to Agile and reading this, please pat yourselves on the back for having the courage to learn more.

Now, it should be "easy" to stay on the path if you keep at it. The act of Starting is the first big step. Congratulations!

One thing you will find as you proceed is a continual list of "it won't work because of this", "it won't work because of that". But, hey, you're not selling snake oil here. You're talking about people in an organization taking control of their work and working together for the best solution possible for the company and it's customers. Keep it simple.

Agile processes are just that ... Processes.. They are not there to replace common sense. Agile is not a silver bullet to cure a company's culture. That part of things is still a human thing and will take time. Please don't think of Agile as a cure for a bad culture. It is simply a way to help the culture to change.

To me at least, what is important is a consistent message. I believe this is the key to helping an organization to be an Agile one.

Let's take the Daily Scrum (for Scrum teams). I worked with a company where the Daily Scrum was considered a waste of time and a nuisance for those involved (at first).

The daily scrum is a quick recap of where everyone on the team is. For more information about the Daily Scrum, just do a quick search. There is an abundance of information about it. Try the Scrum Alliance for definitive information.

At this company, the owners and senior managers considered the scrum to be a nuisance. The senior developer of the team found it to be a hassle. Then, after a few weeks of doing daily scrums, any team member could be asked by someone passing in the hall what was going on and that person could easily tell them what the status of the project was. There are many other advantages to the scrum, but that's not what this article is about. Maybe another time.

When I first started at this company, there was a weekly "developer meeting" which at first was the only way to exchange information. It was generally 2 hours/week. The team was now doing daily scrums and having small "mini-chats" (for lack of a better word) occasionally when needed. Team members knew from the Scrums what was going on and who needed help with what and then self-organized to solve their problems and arranged "mini-chats" as needed to help each other out.

The "weekly 2 hour developer meeting" just became a thing of the past. The team just stopped having them.

Waiting until the end of the week was far too cumbersome for something they could get from a 10 minute scrum and occasional "mini-chats". The team had unknowingly switched into a mode where they practiced regular consultative decision-making and regular re-assessment of their situation.

Then a remarkable thing happened.

One day, I was in a meeting, and the senior developer who at first was reluctant, banged on the window of the board room I was sitting in for me to come to the 10:00 AM Scrum which was 2 minutes away. I excused myself from the meeting and returned approx. 13 minutes later. The owner of the company said "Why do you do those daily meetings. They are such a waste of time. You have that big Developer Meeting every Friday".

My response was "I'm sorry, but we don't need to waste our time with that big 2 hour meeting every Friday anymore... We haven't needed them for a few cycles now".

What a remarkable experience! In one quick step, and after considerable pain, not only was it evident that the senior developer embraced the Agile Scrum Meeting, but also the owner who was previously unsure suddenly came to realize that the team was far more effective than he knew and he hadn't even noticed the shift.

The developer culture had changed to a more team based one without his knowing. All team members knew what was happening and Expected to be kept in the loop from now on.

The key is, keep doing it ! Be consistent. If you've implemented a standard Agile practice, stick with it.

Be realistic though. There will be people who consider it to be "stupid" and there will be people who don't want to participate. As a new implementor, NEVER humiliate anyone in the process. Simply encourage open discussion and ask everyone to contribute. At first, people will be shy or nervous about this. Over time, it will be the norm to participate.

The point is that as time passes, people and things change. The new processes will become Common Place and not so foreign and people will start to appreciate the fact their opinions are important and they have an impact on the bottom line of the company and the customer. This is what drives people to be happy and succeed.

Then, with a bit of luck and perseverance, someone in a different department will say "Hey, I think that seems like a good idea. Tell me more". "Do you think this Agile stuff might work in sales?" might be the kind of question you suddenly receive. Do yourself a favor and be prepared for this with some links to a few Agile Methodologies at-hand!

This is your opportunity to introduce the new "culture" into a different part of the company.

With a bit of patience, others will come on board. It will be a great experience for you once you have others helping out.

The day will come when someone will try and remove an Agile process somewhere in the organization and team members will lobby for their cause. This is the day you will know... I have succeeded with step 1... Getting started !

From here forward, it's just a matter of consistently trying to improve things one cycle or iteration at a time, and watching things get better for the customers, employees, and of course, the stakeholders.

If I can give one last bit of advice. Please do a bit of research before implementing something. Ideally, you want the teams to come up with how to do their daily work, not yourself. Let any process be the team's process, not yours. Of course, if you have a new team to Agile, you will need to help them get started.

Consider your job as one of just guidance and coaching. That will work the best.

Review your environment carefully before deciding about methodology and do some reading or contact a coach about the differences. Should you be using Scrum, OpenAgile, XP, Lean, etc? Think about it carefully. They have different levels of organizational change and are for different applications. Use Wisely. :->

If you're courageous enough and have an experienced Agile team, why not ask the team which Agile Methodology will work best for them? I personally enjoy learning something new all the time. :->

Mike Caspar, CSM, OpenAgile Certificate Holder, ATPL

References :

OpenAgile - http://www.openagile.com
Scum - http://www.scrumalliance.org
Pomodoro Technique - http://www.pomodorotechnique.com/ (thanks Fred for telling me about this ;->)
The Wisdom of Teams

Stress-Free Priority Meetings using Planning Poker Cards

2011-04-17T14:33:00.022-04:00

For many of you, there will be instances where Scrum or Agile is something a company is trying but does not really buy into or understand yet. I would like to start by saying. There is hope!

The following story is about implementing Planning Poker in Priority Meetings at the senior management level using the OpenAgile's Open Learning System. Perhaps it could help you introduce Agile to different parts of your organization.

For those types of companies, Agile Development processes can be introduced and progress made with very little effort on your part. You won’t get the full benefit, but at least people will get to know Agile as a great way of making real progress in an organization.

Consider the following situation.... You work for a company that has "heard" of Agile and is allowing you to implement whatever you can in regards to Agile for the Development Team "as long as it doesn't affect other parts of the company too much".

If you're like me, you've likely heard this more than a few times.

I recently had an opportunity to find a new way to introduce Agile Processes to senior managers who are not really familiar with the processes and also are not willing to put the time in to learn them.

I'd like to pass on an idea about how you could possibly make some small headway in regards to Planning.

Imagine you are working at a company where there are several owners or stakeholders responsible for the future "work backlog" of features for your environment.

Generally, when planning sessions take place, it involves an aggressive battle over who will get what feature first, what is more important (systems, back-end, front end, graphics, this enhancement, that enhancement).. You all know the drill.

I had many such meetings with the stakeholders of a company where I had the opportunity to introduce Planning Poker Cards to these meetings with great success.

Here’s how....

About once every 1 or 2 months, a “priorities meeting" was scheduled for a Wednesday afternoon. After successfully implementing Agile process for the development team, it was time to help the rest of the company out.

I prepared by doing a few things;

- Prepared pictures of existing Scrum Rooms to show how developers and planning boards would eventually look (thanks to Mishkin Berteig of Berteig Consulting for providing additional examples).

Of course, I made sure of standard things such as making sure the PowerPoint will work on the equipment in the meeting room. When it came time for the presentation, I knew it would work. It's hard to show how productive your processes are if you can’t get yourself properly organized.

-I made sure I had a deck of Planning Poker Cards available.

-I explained to the Stakeholders that I would like to do something to "take the emotion out" of the planning process and make sure everyone's opinion is heard and valued. I explained how this process was intended to make the planning a very business-like process, and a way for us to quickly get through what was generally a long, several meeting process in one easy step.

-I asked them to trust me (which remarkably goes a long way), and said, "I would like to show you this to try and move the meeting along, take out the emotion and have us end up with the best ROI (Return on Investment) in future. I asked if they would agree to give it a try.

I made sure to warn them about the process of Forming, Storming, Norming, and Performing and mentioned that if they had interest they could look it up on Wikipedia.

At first, there was little interest in learning or seeing the processes because of course anything about "Agile Stuff...has nothing to do with Senior Management", so it was all a matter of "Let's get down to it" as to not waste time.

I took about 20 items from the queue and converted them to Index Cards and put them on the table.

I asked them to find the least valuable item to get done (there are literally hundreds of backlogged items). This alone seemed like it might take a considerable amount of time, so I decided to take a slightly different approach.

I waited for an index card that I knew I could get agreement on as being of fairly low value and had my starting point. There may have been lower items, but this could safely be agreed upon by everyone as a low priority or low value item. This process works well as it's usually easier for people to agree on what's not important or valuable. I’m not sure why... But hey, it works!

It took only a few cards and although the process was not in "strict adherence" to the no negotiation and no showing your cards rules, in this case it was VERY effective.

The owners of the company prioritized BY VALUE several hundred feature requests in just over 2 hours. I think it’s astounding that by just letting them make up their own system with what I introduced to them, they also were able to self-organize, agree on a different approach, and be successful with their own way of doing things. All I needed to do was introduce them to the tools.

A few times during the cycle, I needed to re-affirm the process was about VALUE only and not about how long these would take. This seemed to be a large stumbling block at first, but eventually it was accepted. I explained that the development team would be the estimated (Investment) part later. We would divide their value (return) / by the developers estimates (investment) and the system would work itself out by providing a general Return on Investment Calculation.

They asked me about what would happen with all the cards... And, now the opportunity to show pictures of Scrum Rooms or Agile Rooms presented itself.

The managers were very happy with idea that they could "adjust priorities" many releases in advance. This for them, was a big bonus. I explained that once we have big boards with all the User Stories on them, it would benefit everyone.

- Everyone in the company could go to the board and see what features were going to be coming soon. This turned out to be extremely motivating for the Sales People. The idea of knowing what at least was being Planned was exciting to them. Of course, I explained to them and the sales manager that there were no guarantees of what would get done if at all, but at least they would know if any of their specific requests were even in the pipeline at all.

- The senior management have always been wondering how the Development Team was doing. This was the ideal solution. A big giant board that everyone can understand at a glance easily solves this. Such a simple technique and yet so powerful!

- An idea how the current release is going. As Scrum or OpenAgile practitioners, we all know the value of this type of information is amazing. To know how far in the cycle you are based on simply looking at the Board is so simple.

- In the past, the development team generally knew what was coming up only 1 or 2 releases before it was time to do the work. Knowing what's coming down the pipe avoids potential code conflicts, systems conflicts, marketing conflicts, and generally keeps everyone motivated and excited about the future.

- An un-expected side effect which I was not expecting was that there was a developer who was worried about future work. Seeing hundreds of cards in the queue of work solved that problem. As we all know, lists of future work can usually be never ending :->

Teams can then start estimating the Work portion using the same system. What you end up with is ROI (value over investment) for your queued up work. The company may not live with it, but it gives a simple starting place for everyone to discuss openly.

Another real benefit is that the emotional roller coaster of settings priorities is much less a factor with this type of process. Everyone has agreed as a team to the Value and everyone has agreed as a team to the Estimates, so there’s really nothing other than pure politics to stop the plan from working now.

I was pleased that at the end of the first attempt at doing this, there was an overwhelmingly positive response.

There were a few surprises. For instance, one of the managers wanted to be in the Estimating meeting with the developers to Ensure we "get the right answers". However, I needed to stand firm. Again, I asked them to trust me and simply said "No, it won't work that way, sorry... I DO promise, though that if there is something we don't understand, we'll consult you."... The Stakeholder was happy with that.

In reality, all that manager was worried about was that we might consider one of their tasks less important or overestimate the intention and therefore overestimate the time it would take to complete, and therefore, lower the ROI on it. That owner wanted to ensure that a very specific high priority project got put into the queue.

It is after all their company. We all need to remember that owners need to have some rights as well <grin>.

In my case, I know that what might happen is that one or some of the items may end up overstepping the process due to factors outside the teams’ control.

This is a reality of working in a smaller development environment... actually... in reality, many environments.

However, I still consider this a major breakthrough for several reasons.

1 - Even if a few items bypassed the process at least the several hundred other features and tasks did not. Who can complain about that!

2 - The owners were now in the "frame of mind" that tasks can be easily be classified as to value.

At first it was difficult for them to specify value for large features because they believed they might be huge projects and they didn't want to send the team on a huge development task and risk losing other important features that were already in the queue.

I explained to them to not worry about this as the ROI formula will actually make these projects less of an ROI at THIS time. As they want to move the bigger cards closer to the upcoming release, we will break them into smaller pieces in the same fashion and eventually those parts of the system would be worked on as the smaller parts would have potentially higher ROI’s.

This of course, made sense to them. The key here is that huge tasks should be split into smaller tasks as they get moved on the Planning Board, Information Radiator or whatever you want to call it. As items move closer to the release cycle, their value should naturally be increasing as well. Then, upcoming features can be re-sequenced and prepared to get injected into the development process using another planning cycle.

All the time, it's about Value for Work performed..... This is of course what being in business is all about.

Some values are about taking care of long-term customers, some are purely political and some are just about making sure the system doesn't crash. Value is about the overall impact to the health of the organization.

Planning cards make this a non-emotional event.

I knew the system was working because a funny thing happened. Several days after the first planning cycle, I received notification of new Feature Requests from clients and our support department with some unusual coding on it.

"The ABC type of customers are looking for this feature in the product; It's something we really should consider doing soon... We've talked about it and think it should be at card level 8 or 13”.

This to me was a great thing to see!

For those of you who don't know; Scrum or OpenAgile Planning Poker cards are purposely set up to have a non-uniform number sequence to avoid mathematical calculations and exact figures. They are about relative value to other each other and not fixed numbers.

The key is to keep it simple and remind everyone using the cards that this is not intended to be a perfect estimation. This is a relative estimation of value or work.

The fact that the stakeholders had started using this terminology showed that they not only understand that process but truly see its’ value.

One complaint from the past had always been that everything has been either High Priority, Medium Priority or Low Priority. Planning Poker Cards have helped them to take the emotion out of the Priority process and ultimately give them Many Levels of Value Priority in a simple way.

Perhaps planning poker might help in your environment to help set priorities, not just for development but for any set of complicated project.

Many of us think of Planning Poker as a developer only thing, but as you can see from this story it can be used as an effective tool for any process. Give it a try and you might just be surprised at how stress-free of a process it can really be for your priority meetings.

The read about the specifics of Agile Planning Poker, try Wikipedia.

To find out more about OpenAgile and its’ flexibilities regarding release, or cycle planning, go to http://www.openagile.com.

Mike Caspar, CSM, Open Agile Certificate Holder

http://mike-caspar.blogspot.com

Just ask the team for comments

2011-03-26T09:49:00.000-04:00

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. http://www.openagile.com

Agile and it's interaction "around the edges"

2011-03-16T07:59:00.001-04:00

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 doing Agile, 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

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

2011-03-06T13:34:00.001-05:00

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

Considerations for bringing on new team members into an existing Agile team

2011-02-26T18:18:00.000-05:00

As in life, things change.

One of the inevitabilities is that some day you may have a team member leave and you will find a replacement team member to fill that spot.

I would like to share something that could sneak up on a manager without being totally prepared for it. For me, when this happened, it was a big surprise. I decided to share this insight to avoid the same thing happening to you.

I had been spending so much time working on teaching the team how to work together, I had not really understood just how far they had come.

This soon changed after bringing on a new developer. A few iterations after having them start, we realized there was something wrong. They were not working out well.

After careful review and some discussions with some of the team members, we soon realized there was some open dialog needed to make all the team members aware of how hard it could be for new members to integrate themselves and "form" with the existing group. I had not realized just how far the team had progressed up to this point.

As a team, we modified some procedures slightly. We talked openly about how to make new participants feel welcome and removed obstacles for future team participants.

If you're reading this, hopefully you can see a situation like this coming and just be aware that it is something to consider and be prepared for if you manage or are responsible for an Agile Team.

Don't under-estimate just how far your team has come, especially when it comes to trying to integrate a new team member.

Mike Caspar

Why ITIL and Agile work well together

2011-02-14T08:08:00.000-05:00

ITIL v3 is a Framework for Change Management. The basic principal (at least my short version) is to make sure that any changes to a Production System Do No Wrong. ITIL has Processes to manage most aspects of an application environment.

Agile is a Framework to allow the quick creation of Applications or any type of work that gives almost immediate benefits to a company in short intervals called "Sprints".

Consider the following scenario;

Your company is ready to create a new enhancement to Product A and everyone is excited about its' release.

You follow all the standard conventions regarding Agile Development of release planning, having the team agree on the work they can get done for the next release, developer peer review, user testing, and all enhancements work as expected.

Everything goes as planned and now the release day has come!

Inevitably, there will be changes to the Database Structure. There may be new fields, new tables or even changes to the relationship of tables to each other. There may be a new web service to be installed.

The development team properly follows their script to make the changes necessary and everything seems to go fine. Another great release!

But is it true?

In this example, you accidentally caused an application in a remote city to not function as it is rarely used and no one thought about it. You do not find out for another 3 Sprints.

This is where ITIL change management comes into play.

ITIL keeps track of different aspects of the system and their relationships. The information about systems or applications are stored in a Configuration Management Database. Each component is called a CI.

The Configuration Management Database stores information about each component or CI and it's relationship to other components.

When you have implemented ITIL in its' entirety you would know that for instance the X Table is depended upon by Application X. Application Y may be running in a different city and only communicate once in a while; and therefore should not be forgotten.

What went wrong? That's easy; A lack of change control and this is where ITIL comes into play. No matter how we try, people cannot remember everything about all aspects of a large system. Factor in employee turnover and the results can be disastrous.

A properly documented Configuration Management Database would have at a minimum had someone ask "Hey, has someone thought about Application Y running out in that other city?".

This is where ITIL and Agile nicely complement each other.

During the Agile release cycle or Sprint, the ITIL management team should be given due consideration to ensure or plan for integration issues with other parts of the system. If you have the company process in place, this would likely have been done before it came to development.

Using ITIL before development starts can save the company huge expense by ensuring a project won't negatively affect other systems, well in advance. It provides a better overall general design before starting.

This in no way implies using a waterfall development approach!

It simply is about adding a few specs before starting stating something like "If the X table will be changed, don't forget about Application Y".

Another example might be "Application Y is multi-lingual. Make sure the new application supports more than one language".

This fits well with an Agile Project Directive without requiring complete specifications to be completed before development starts.

Thinking this way may seem to cause more overhead. However, compared to the cost and embarrassment of having to do a panic change and possible outages, the costs are minimal.

In reality, the software design and development phase of a system is a smaller part of the overall growth plans and service plans of a company.

Ideally, Agile development would be part of an ITIL process. For many smaller companies though, this is not likely a reality.

Being a strong supported of Agile and ITIL myself, I can also see how the ITIL process (or parts of it) could benefit an Agile Team that is not currently in an ITIL environment.

During an early Sprint where some planning takes place, or at a later Sprint when things are almost ready for production would be great places to introduce some of ITIL's framework.

The bottom line is sharing of information.

Certainly, if you have made a big change, you will want your ITIL team to follow their processes of Service Transition. Why re-invent the wheel?

Consider the impact to customer churn rate and the stress to the support department when deciding if ITIL would be useful to your company.

Agile and ITIL can work together nicely if due consideration is given to both.

Nothing in life is perfect and every company has it's reasons why some things will work, and some won't.

Take what you can from each and truly benefit your company by putting out good code (Agile) and not destroying any production processes as you do it (ITIL).

I know there will be purists in both camps who read this and want to comment about how their way is the only way. Please read my blog disclaimer.

I believe that most companies can benefit from at least a small selection of both methodologies.

Using some of each methodology is better than using nothing at all. As a minimum, employees will have a common language to communicate and know how to get things done safely and efficiently.

Why not use what you can and get benefit from it for your company.

Mike Caspar

Infrastructure Knowledge for Developers

2011-01-30T09:30:00.000-05:00

As technology is constantly evolving and with the recent market progress in cloud computing the line between hardware are software is getting more obscure every year.

This changes some basic questions. Are you a developer? Are you in Infrastructure? Today, I believe it is unreasonable to expect to be just in one or the other.

Take Microsoft's Azure platform. Is it hardware? Is it software? Well, sort of a little of both.

If you only know .NET development for instance, how would you accomplish Federated Authentication or even something like OpenID without at least an understanding of Internet Based Authentication?

Authentication has typically been the role of Infrastructure. Here lies the rub. A developer is not accustomed to having to decide, "Will I setup to be a "cross country" domain, "worldwide" domain. These are typically infrastructure questions but need to be answered immediately upon creation of these types of services.

An example might be a content a Content Delivery Network (CDN). A CDN can have some fairly complex business rules. Use of a CDN affects marketing, management, system reliability, performance and customer satisfaction. A CDN can also greatly cut down the number of hits to your web site. There can also be significant costs.

Here is where it gets complicated. When a development team writes an application and is asked to start moving files to the "Cloud", there is no reason for them to ask about the benefits (or financial implications) of a CDN. Why would they? This is historically someone else's consideration.

If a team does all the work without knowing that some day you will be delivering the data over the CDN portion of the storage provider, you may find it almost impossible to do.

The best choice would have been to have development in on the "Infrastructure" part of the discussion.

You may find your team unable to re-write the code to handle the new details in the application. For instance, some files may be delivered through the CDN and some not.

Most developers are comfortable with the ideas of private and public files, but many will not be familiar with the idea of some public files going through CDN and some not.

Do yourself a favor. Teach them now about the technology. Just knowing a tiny bit about it could save you huge expense in the future.

I can think of many such instances where cross-training should be considered and as far as I'm concerned absolutely necessary for the future growth of an internet based company.

The hardware folks need to start sitting in on some developer meetings and developers need to learn about some infrastructure. This will ultimately help everyone work together and definitely help the teams understand each other's needs.

Sound crazy to you?

Consider a few examples from past experience.

- .NET developers who are tasked with creating a system of web sites that can intercommunicate, but none of the developers understanding the mechanisms of Public Key Infrastructure, Certificate Authorities, OpenID or any of these authentication technologies typically reserved for Infrastructure People to deal with.

Clearly this is a large development job and the hardware infrastructure has to support what the development team can do and there is no point of the development team for instance making something requiring VPN's where there is no actual hardware in place (just cloud based servers).

- An SQL server DBA trying to figure out a way to fix a server with so many connections open that it can't even function. The solution is in a Web Server that is not configured properly in the IIS Connection Pooling settings.

The SQL DBA doesn't know about the IIS connection pooling because developers handle that and developers don't know about it either because "the hardware people" handle the web servers.

- Developers using the Cache control of a Web Server with no expiry of Cached objects and basically forcing the server to run itself so low on memory that it starts purging memory out of desperation to stay running.

This is clearly a situation where a developer who sat in a Cache discussion about how .NET (in this example) manages the Cache and the fact that a Windows Server does not have unlimited memory resources like a mainframe (just kidding for you mainframe folks out there...I know from past experience that your problems can be worse).

- Consider developers who do not truly understand the impact of making DNS queries and their impact on IP Infrastructure when they make queries to 10,000 servers for DNS records from a large volume email application without any consideration for Caching of DNS requests.

Any developer who actually saw what happened at the CISCO switches and the upstream DNS servers would cringe at the traffic they created. Of course, if they only knew.

- The same argument works the other way around. I have seen a DBA change the password on a SQL server automatically on a rotating schedule without realizing the impact to a Windows Web Service sitting in another building.

It seemed that every week the off-site Web Service crashed and no one could figure out why. It took weeks to determine the cause. This is a perfect example of the benefits of ITIL. ITIL is a change management methodology specifically designed to handle this type of situation. I might talk about ITIL some other time.

I have discovered that having developers sit in with the Infrastructure folks occasionally and vice-versa provides tremendous benefits in co-operation between the IT staff.

It's amazing to see a development team wonder if there is a hardware solution to their problem before committing to a month of work. It's just as amazing to see a hardware person ask if they could just get a developer to make a small tweak to fix a problem and get a positive response just because of a bit of cross-training.

If you're trying to improve productivity, allow the different teams to sit in with each other once in a while.

I have started to bring our developers up to speed with some training on Caching, PKI (Public Key Infrastructure), Certificate Authorities, CDN's (Content Delivery Networks), different types of Source Code Repositories and basically anything they are interested in reviewing.

Anything the team can learn about together can only benefit everyone.

A Source Code Repository discussion can be equally beneficial for developers (who have to use them) as well as Infrastructure folks who have to plan to make sure they work. Why not let the teams learn this type of technology at the same time in the same location?

Code Repositories are typically a developer item but your Infrastructure folks will greatly appreciate and even help the development team out if they really know why it's so important to development, and maybe even find better ways to store the data for the team.

After all, even the best written software still needs proper infrastructure to run it.

I like to schedule the first 1/2 hour of our regular development meeting for members from other teams to join in. They can see what the team does and how things work.

They are more than welcome to sit in the technical stuff, including table interactions, UI issues, etc. later on. It gives other departments an appreciation for how complicated of a job it can be and definitely helps boost morale.

The point here: Give it a try. Do a bit of cross-training during your Developer and / or Infrastructure Meetings. You will be amazed with the results!

Mike Caspar

Team Work Common Sense

2011-01-14T16:25:00.014-05:00

Let’s talk about working in Teams. There are many options for how to work in teams and a variety of implementations. However, let’s just talk about some business reasons for doing things in teams and why they are an essential part of software development.

Actually, I can think of a variety of other parts of business that could benefit from this approach, but let’s just stick with software development for now.

When working in teams, I try to spread the work amongst the developers. This shares system knowledge and experience. As each week passes, each team member becomes knowledgeable about a different part of the system.

At first this approach to the outside observer seems slow and cumbersome. As time goes by, and the team gets used to each other and the application, development gets faster as any team member can effectively work on any part of the system.

This is the tricky part. An executive who has not seen Agile work before will think that things are slowing down. Yikes. Of course this is not the case.

Try to focus on the difference in the bug rate, increased value to the customer and to the company with things such as lower churn (loss of customers) rates, a regular and predictable release cycle, customer satisfaction, and the happiness of the support desk staff as the number of support calls goes down. Consider also, what marketing can do with the information about the upcoming release, or even the excitement of the customers experiencing a new, zero bug release every iteration.

Granted, these items seem less tangible to a financial person, but the turnover of unhappy support employees, unhappy developers and churn of unhappy customers can easily be quantified, to name just a few. In your environment, there are likely many more.

Depending on the size of your application and team, you will soon be confident that any team member can work on any part of the system and make the development team extremely productive and respected. As a minimum, there will be product knowledge by all developers. This is key when you are planning on adding new functionality. It may surprise you what a new novice developer has just learned in a course that you or your team members may not know about!

Don’t get me wrong, each ‘mini project’ or feature in the program still needs a developer who really knows that piece. I can’t really see getting around this without having a very shallow application.

I’ll talk about the whole developer managing a mini project thing and its’ advantages another time. For now, though, I’ll just stay on topic.

Once Agile is in full swing (no matter what your discipline or disciplines you use), you will find that you will soon be in a position to be wondering what work you can do next. This is where Agile truly shines. The work you are doing has a definable schedule and because of the regular estimates and re-estimates you have a realistic idea of how you are doing. After a few iterations you will even have an idea of how much productive work gets done by the team in a week, and you know how much work you can already schedule ahead for.

Others will not see it coming and will likely be surprised you are asking.

Don’t be shy! This is the time to let others know how well Agile is working for your company.

Each time a small feature or part of the system is being worked on, I purposely give the piece of code to the same ‘base” developer to do but assign a different “second” developer to work on that piece. This forces information exchange and empowers the team to know all parts of the system. It is also a great way to pass on development experience to new developers and sometimes from new developers to existing ones. The exchange of information is a dramatic thing to witness once a team is used to it.

There is nothing more enjoyable than to publish a new release and to have nothing dramatic happen from the development perspective.

Where I currently am, I remember after about the 4^th iteration (we are on weekly cycles), having a developer meeting 2 days after and the whole team joking about the fact that not only did the support department receive no extra calls, but the call volume actually went down because of some of the previous defects we fixed.

What a feeling of accomplishment and teamwork!

As well as the obvious benefits of removing risk from the company, it provides the added benefits of true teamwork spirit, mutual respect and fellowship. The developers soon know each others’ strengths and weaknesses and will automatically help each other out.

Techniques are passed on and knowledge that otherwise would have stayed only with one developer is shared. The transformation from individuals to a team is remarkable and very enjoyable to see and for me at least, the true inspiration for managing as part of an Agile Team.

Agile helps the developers to be happy and fosters an environment where everybody feels like part of the finished product.

For those of you out there that are regularly trying to figure out how to keep developers motivated and feeling like part of the company, consider the positive effects of true teamwork and each person feeling like they are part of the finished product (which of course they easily could be).

Agile and the Importance of Estimating and RE-ESTIMATING

2010-12-27T13:16:00.020-05:00

I've been developing software since 1984.

The development tools and syntax of applications have changed over the years, but one thing that has not changed is the need to try and figure out how long a project will take to complete, price it, and how you're doing once you get rolling.

Agile gives us unique benefits by breaking down a large project into small, manageable pieces. More importantly, it allows us to start on a project with a target on providing business value soon after starting out of the gate.

Let's talk specifically about the ESTIMATING part of Agile Development.

First, a few key words;

Iteration. An iteration is a small cycle of work. Meetings take place, software is developed, developer work is coded, testing is done each step of the way, peer code review happens ,"user review" is completed and at the end of a small cycle (from 1 week to several months depending on the environment), you have a releasable unit of work.

Velocity. Velocity is a calculation of how much "work" is actually DONE on a project.
The reality is that for development work to be productive, it requires teams to WORK TOGETHER, not only amongst themselves and their respective "user representative", but also often with other departments.

Knowing that meetings, problems, reviews, testing, etc. are part of the natural process of Agile, your team will eventually have a Velocity at which you know they can work.

At the start of a project or with new Agile developers, the velocity may be a bit slower while they get used to the new way of doing things. With an experienced team, the velocity can increase significantly. There are other considerations as well such as holidays, work-life balance, company culture, etc. but you will find a "velocity per developer" for your organization in just a few iterations.

An example would be a Velocity per developer of 6 hours / day. This would mean that if you had 6 developers you could produce 6 X 6 hours of work in a day, or 36 hours per day.

Original Estimate. When your team first puts together the "estimates" of what the release will take to complete, you will add them up.The result is a good number to start with.

This is where the waters seem to get murky. Some Agile purists say that you should not estimate many releases in advance.

Being in business since 1984,I have RARELY seen a project get off the ground without SOME idea of what kind of costs and time frame a project will take to complete. Some kind of estimate will take place (whether it be formal or not). If a 4 employee company knew the new development project would take 10 years and 10 million dollars to complete, no matter how efficient it is, it won't happen. Be real. Everything has it's place.

Revised Estimate. This to me is where the REAL POWER of Agile Development comes into play for a manager of a software development team or for the owner of a company.

As each developer does a small piece of work (story to some), they record the time they work on it in whatever increments work for you and the tools you have.

Remember.. Developers are people, not robots!

The recording of the time has and always will be a a necessary evil for bookkeeping and accounting types, but not the real power of developing in Agile comes from the REMAINING ESTIMATE.

Here's the math and the beauty of it.

Let's say you have a project X, with an original estimate of 1000 hours to complete over 6 months. Someone in their wisdom has decided this is the number (however obtained). It could be an experienced Agile Team or a manager who made the decision based on marketing info or something a BA came up with, or just the wishful thinking of a business owner. Either way, it's a start.

You have a team of 6 Developers and a User Representative or Subject Matter Expert(SME). The User Representative is not optional in Agile or things can go very bad.

For the purpose of this exercise, let's assume you will break down the Project into 6 releases (or iterations). Each iteration will be 1 month long.

I am currently in an environment where we have WEEKLY releases for a public facing website with several hundred thousand users.

Your cycle will change based on your company's needs and environment and the nature of the work you do.

Careful! I can warn you that weekly releases are difficult. Where I currently am, we are on weekly releases for some very specific business reasons. I'm personally looking forward to a more relaxed schedule of a new Iteration or Release every two week to a month. The shocking thing is that under the Waterfall method of Development, we would have planned for a release possibly every 6 months to a year. Amazing !

At the end of two weeks, the developers have been doing work and re-estimating constantly. If a Story (piece of work) was estimated at 5 hours, and the developer did 4 hours,they record 4 hours work. The key here is that they RE-ESTIMATE Immediately. If the developer thinks it will take another 3 hours to finish this task, they put a NEW Estimate of what is left to do. This should be as realistic as possible including peer review, users testing and preproduction testing.

Some tasks may have less remaining work than expected when being worked on. The key here is to be as realistic as possible.

Here is the beauty. At the end of two weeks, you will see two things. The first is what your VELOCITY is per Developer (how much productive "work" is done during a day). My PREFERENCE is to do this in teams. The whole idea of Agile Development is TEAM WORK. Making 1 developer accountable for something has MANY business flaws which I can get into later (another post). For now, let's just stick with keeping things in Teams. At the end of a few weeks, you will know that for instance your teams' Current Velocity is X hours/day. This lets you know as a rule how your team is doing and also let's you do the next and most important part.

As the iteration continues, you will see the REMAINING number of hours for the Iteration in comparison to the Original Estimate. Based on the historical Velocity so far and the 'new' remaining estimate of hours left, a chart can easily be created(called a Burn Down Char) to show what the Original Estimated completion date was in comparison to the "revised" estimated completion date and can give you a new target date based on current information.

This is the cool part. You now have several choices!

Option 1 - Extend your final completion date
Option 2 - Add Developer Resources (usually you can see this as add X hours of Velocity /day on a chart)
Option 3 - Remove some planned work from the upcoming Release.

The most amazing thing is that you know how you are doing based on your plans, EARLY on in the development life cycle.

You are not waiting until a month before the 6 month project is over to realize you have no chance of making it in time or on budget.

There are some challenges for sure, but well worth it when you see that you produce nearly bug free code on-time and on budget. Amazing stuff.

Virtualization Security

2010-12-25T07:03:00.003-05:00

I went to the VMWare virtualization conference in June 2010. What a great experience!!

After talking to several of the vendors, it has become clear to me that something overlooked seems to be the issue of security WITHIN the Cloud Providers for your data.

Terms such as "trust us.. we will keep your data safe", or "No one has ever asked that question" do not seem like valid responses to me.

For instance, who does backups, where are they kept, what kind of legal rights do you have to the data, what if data is leaked, who has the responsibility for the leak and what remedies do you have ?

Therefore, I'm going to try and keep some posts coming related to this topic and give some possible solutions or at least direction of thought.

Disclaimer

2010-12-25T07:02:00.000-05:00

Let me just start by saying that any posts or comments in this blog are simply MY PERSONAL OPINION and not to be considered as any recommendations or facts provided by any manufacturer, employer, client or associate.