Agile Agile Agile….  The loudest buzzword of many I get to hear lately.  Even though we hear it does it actually sink in to our everyday practices.  So many seem to know the Agile Manifesto to heart, and also the 12 principles.  What is interesting to me in working in some of the teams is that even though we call our team an agile team, it still acts like the old waterfall project work.

I could spell out many reasons why I see conflicts that inject a lot of churn within the team.  However the biggest and I believe root cause is the word TEAM itself.   For instance within your own group have you ever said or heard something like, “we all should be responsible for the outcome”?  Then when someone is asked to do something a little outside their comfort zone they get mad or offensive and say “That is not my job”, or “I do not feel qualified to do that.”

This is what I like to call the I-Team.  Or Individual Team.  In General these people can come from an array of places, but their primary focus is on either their specialized role, or they just do not want to expand their horizon of knowledge any.

The opposite of this would be what I call the We-Team.  This is the complete reversal in which a person can still be specialized in a particular area, like developer or qa, yet if the need arises they could without asking jump in a fill the role.  They may also not be fully trained at the role, but they would know how and where to get the necessary information to help complete the needs of the team.

Where do you sit within your team, and how does that coincide with agility. Back to Agile big 4.

1. Individuals and interactions over processes and tools
2. Working software over comprehensive documentation
3. Customer collaboration over contract negotiation
4. Responding to change over following a plan

Individuals and interactions over processes and tools.  Imagine you are part of a team that has many members in the I-Team environment.  You may have certain timelines and processes so that each role can work on a particular assignment.  For example.  Developer may need 2 days to work on a story, but then because you are an I-Team QA will also need a day to do their work.  Sounds great right?  As it states individuals.  But what we are missing is the interactions.  That same model but it is a We-Team.  Developer and QA can pick up a card together and work through it.  Though it still might be the same amount of time to work on the card, they can do so in parallel, and also have a quicker feedback loop.  You may be asking what do you mean about feedback loop.

In the first example of I-Team this was really a happy path.  Meaning the developer is super awesome and can code every time without creating bugs.  I really want to work here by the way….  But that is not the case we live in the real world.  So lets say qa finds a bug.  Well now it has to go back to the Developer and within the sprint dev and qa will keep passing the buck back and forth until it is satisfactory.

Now you may be thinking whooopppeeee.  You would still have to pass it back and forth working on the card at the same time.  Guess what you are right.  But here is one of the benefits of the We-Team.  Both individuals are focused on the same thing.  If you are working on a story synchronously then you can reduce the feedback time, and also keep you mind on the goal.  When you are the I-Team once you pass the buck you are now moving on to the next thing in your queue.  This can lead to a very distracted validation of your new development.

Working software over comprehensive documentation.  Come on man there is no mention of people here.  Well… Your right about no mention however remember the first principle.  Process and tools.  Having the I-Team in place means you will need more rules, process and documentation of contracts so that everyone has a level playing field and expectations drawn out so everyone has nice neat lines.  To be honest the more documentation I have to keep up with the more I get annoyed.  Even more so than that how many people want to take the time to remember 500 rules of how to get something done.  Many people have trouble remembering these 4 main principles of Agile.

Customer collaboration over contract negotiation.  To me a customer is whomever you will be delivering something too.  It can be an employee or someone who is actually paying for the item.  In a team though a customer is also your other teammates. Remember from the manifesto that we value the things on the left over those on the right.  In the I-Team mentality we now have to keep up with this large set of rules and responsibilities that each role will complete.  The more rules and contracts you have the more you have to spend time maintaining those rules versus working on actual value add.  On the We-Team, we know that our responsibilities are working together and collaborating not only among out trade but with actual paying consumers as well.

Responding to change over following a plan.  The last and final section of my rant.   Responding to change.  This is such a big topic that even a small paragraph doesn’t do justice.   There are long books and tons of topics on change alone.  If you work in a project with lots of different types of customers, you will see lots of change.  Change can be very good, and one of the benefits to making an agile team is allowing the team to morph and re-mold to a new shape if needed to complete the goal.  Think again about someone on the I-Team.  On an I-Team certain members may get the communication and do their part.  Awesome job done.  However just because 1 part of the team is complete doesn’t mean that everything needed for the story is done.  Maybe there is some integration or testing dependencies?  Its really hard to tell when it is on the I-Team because you can never really be sure who is in the loop of what is going on.  We-Team imagine that idea of people working together and maybe even pairing on developing a story.  It would be much easier to keep everyone in the loop.  Now it also says over following a plan.  Some people and especially those who like the I-Team really love completely worked out plans.  However when then they go bad or need to be completely changed, they get offensive.  When they become offensive all of a sudden there are meetings.  Then more meetings to talk about meetings and trying to cool everyone down.  Have you been there done that?  What just happened?  Oh we got off topic and talked about how everyone feels and not about solving the issue on the change that is happening and keeping our customer happy.

Thanks for taking the time to read my rant.  But I encourage you to think about it are you on the We-Team or I-Team.  Are you willing to step outside your little cube and see what other team members are doing and how you can help?  My boss has a great phrase of “What can you do to move the needle?”  So engage with your team and see what you can do to move the needle.