Servant Leadership in Action

Tags

, , , ,

Earlier this week I attended a retrospective with team I am coaching and watched as a growing scrum master stood up and started the retrospective saying, “Ok guys, I’m going to step completely out of my comfort zone again today.   You didn’t like the activity that we started the retrospective with last time so I’m not going to make you do that again.  Instead, I came up with something else that I hope you will like a little bit better…”

What he did was really cool and very simple.  He asked his team to take a post it note and write down 1-3 words that described how this sprint was different than the previous sprint.  He collected the notes and put them up on the white board in the form of a circle.  The team briefly discussed the items and this allowed both the team and the scrum master to get a feel for their overall perception of the success of the sprint and if the team was moving in a positive or negative direction as far as overall improvement.  This opening “set the stage” activity broke the ice perfectly and gave him a wonderful springboard into his “gather data” activity – which he did with genius style!

Kyle Duke, who has incredible raw talent to be a great scrum master, proceeded to use the 4L activity (Liked, Learned, Lacked, and Longed For) to draw information and conversation from his team.  I sat on the sidelines astonished as I watched him introduce this in a way that I had never seen before and almost died laughing.  He was amazing.  When he transitioned into this activity, Kyle said, “Ok, team help me out … what are our quadrants?”  He drew four quadrants on the board and proceeded to get the team to “help” him label them.  Since they had only used this method once before no one knew the labels.  It was hilarious to watch Kyle guide them letter by letter into each square until they guessed the labels.

I saw Kyle do other really amazing things like ask for permission from his team to combine post it notes together when he thought that they meant the same thing – instead of just assuming that he could make the decision for the team.  When he wanted to make a clarification on what someone wrote on a post it, he asked, “Do you mind if I write that on here?”  These actions provided a place of safety for his team and also create an environment where the team knows that the scrum master is not a manager of the team, but a member of the team.

I was really proud.  Kyle did a great job.  His team felt safe.  They opened up and talked about the stuff that really mattered and they had a great time.  I love seeing scrum masters coming into their own and really having the courage to do things that are outside of their comfort zone in order to help their teams succeed.  This is true servant leadership in action.  This is scrum.  This is why I love being an agile coach!

This Shouldn’t Be a Status Meeting … Improving the Daily Scrum

Tags

, , , , , , , , , ,

How can I keep the daily scrum from becoming a daily status meeting? But if we are all answering three questions then who is supposed to be asking the questions?  If we are gathering to give our updates on these three questions every day on what we are doing then that sounds like a status meeting to me – what am I doing wrong?

These are all questions that I have heard new scrum masters ask.  The daily scrum seems like it should be the simplest thing we do, right?  The team self organizes daily for a time box of no more than 15 minutes and talks about three things:  What I did yesterday, what I am going to do today, and what is standing in my way.

So, why is it so hard?  In my experience … mindset.  Often, scrum masters learn a process to implement but they don’t recognize the mindset that must change in order for the process to have any value.  Being self organizing and collaborative, like being agile, is a mindset.  It’s not just something you do – it’s something you are.  It’s something you become.  It’s about individuals and interactions over process and tools. What I’m finding is that when teams are struggling with the daily scrum it’s about them putting the process and tools over the individuals and interactions.

When I encounter the struggling scrum masters I find that they have been given a process that they are trying to implement:  Meet for 15 minutes, everyone on the team answer three questions about what they are doing, don’t talk about anything else, break ~ scrum master you are responsible for making sure that the process is followed and that the team understands how scrum works so go make it happen.

But the thing they seem to miss in the equation is that the daily scrum is about the team coming together daily to collaborate and plan how they will work together to deliver the highest priority user stories today or as soon as possible.

Are you struggling in this very thing?

What would happen on your team today if instead of everyone taking a turn answering three questions about what they did on some random user story yesterday and will do today towards the sprint goal, you would all look at the scrum board together and focus on only the top priority one or two stories?  Then, collaborate and discuss what you can do as a team to get those stories completed today or tomorrow?

Tomorrow you can do the same only start by adding to the conversation any progress you made since the last time you met or what stopped you from making the progress you each thought you would make.  Then figure out together what you will do as a team to remove those roadblocks and how you will get the remaining work on the story completed before the next daily scrum.

If one or more of the stories gets finished by tomorrow’s daily scrum celebrate that success and add the next priority story to the conversation.

The advice and method I’ve just described is really nothing new, it’s just putting the individuals and interactions over the process and tools.  It’s all about what we focus on.  When we focus on the questions and the time box and governing the scope of the conversation to make sure we don’t deviate from the questions we lose the collaboration and the true heart of what the daily scrum should be.

Appreciation in the Workplace – The Language of Value

Tags

, , , , , , , , , ,

In my last post, The Language of Appreciation in the Workplace, I introduced the appreciation languages.  Understanding these has been very valuable to me as a consultant, a leader, and a coach because they give me insight into not only what motivates people but it helps me to understand how they tell others that they are committed and giving their all to the team.

Let me explain.  The appreciation languages aren’t just about saying thank you to people for things they have done.  The language of appreciation is actually the language of value.  It is how we communicate our value to others, it is how we know others view us as valuable, and it is how we know that others desire the value that we have to contribute.

In this post, I’ll try to give some real life experience examples of how I have seen the language of appreciation communicated and perceived in the workplace and how it motivates people through the proper utilization so you can get a feel for recognizing and implementing it in your own organizations.

I’ll start with me.  My primary appreciation language is quality time.  As a consultant, a trainer, and a coach this works in my favor and motivates me because my work revolves around helping people who want what I have to give.  When I work with clients, classrooms, or teams they ask questions.  They are interested in the answers I give.  They trust my expertise.  They believe in me. When they follow my advice and they benefit from that advice I know that they are truly listening when we work through problems together.

This is an example of the language of quality time in action motivating me because I get to share my life with people and invest a portion of myself in them.  They speak the language of quality time to me because see value in me and express appreciation for that value by drawing it out of me and utilizing what I have to give.  I speak the language of quality time to them in return by actually investing time in them to give them whatever they need to learn and grow.  If they need a teacher, I’m a teacher.  If they need a coach, I’m a coach.  If they need a consultant, I’m a consultant.  If they need a friend, I’m a friend.

As an enterprise coach working with 40 teams, it is almost impossible to spend quality time with each one of them consistently.  So, I have had to rely heavily on the use of words of affirmation to motivate and encourage people.  Thankfully, this is the easiest language of appreciation to communicate and also the one that many people respond to well.  One example of how I have used words of affirmation verbally is by simply walking around and talking to people.  When I ask them about how their teams are doing I listen and praise their specific efforts.  They don’t have to have great accomplishments.  Effort counts!  I get excited when they get excited.  I get excited for them even when they don’t.  I point out things that they should be encouraged about so they will know WHEN to get excited.  I tell them things like, “Do you realize how big of an accomplishment that small step is?  This one little thing is pointing you in the direction of …”  I help them see the future by giving them words of affirmation either one on one or in front of their team members or supervisors.

Another way I use words of affirmation is in writing.  Every month I send out a newsletter called “Celebrate the Win!”  In the newsletter I include an encouraging narrative about the state of the organization and where we are headed because of what we are accomplishing daily.  Then, I include as many pictures as I can gather with captions celebrating “wins” both large and small that teams have accomplished throughout the month.  Everyone has something to celebrate.  We just have to look for it through the eyes of appreciation to see value in everyday things.  This is a way of showing appreciation for the value of people more publicly.

Both of these methods have proven to create excitement and energy in the organization.  The teams are like sponges who soak up the praise.  All they need is someone to believe in them.  They do all the work.  I just tell them they can.  I only point out to them every success I see regardless of how large or small it is.  This creates a momentum that appears to be unstoppable from the teams and that momentum is now rolling up into management.

The appreciation language of receiving gifts has been a very fun one to implement in organizations.  The size of the gift really isn’t the issue.  In fact, the cornier the gift, in my experience – the better!  It’s about the fun and the energy and the point of contact that says, “I am valued and I have this token to prove it!”  In the organization where I’m currently working as an enterprise agile coach I use the language of receiving gifts in our quarterly “Agile Celebrations” where we bring everyone together to celebrate the people and what they are doing on their path towards agility.

Some of the “gifts” we give at these celebrations are paper certificates for teams that reach a certain maturity level (This organization uses the ShuHaRi maturity model.), certificates for coming to training classes, plastic medals for people who are mentoring others, plastic trophies for people who are using metrics properly, “flip flop” keychains for people who are showing progress and doing cool things towards maturity, and the coveted “flip flop trophy” for a team that is voted by management as doing the most towards agility even though they aren’t quite there.  (The flip flop is a word play on Shu and the flip flip trophy is real a “custom made” trophy with a rubber flip flop proudly displayed on top.)

These gifts are super corny and really cheap (Oriental Trading Company is a great resource.) but the teams love them.  There isn’t a day that goes by that I can’t walk past a desk and see a plastic “thumbs up” trophy sitting proudly displayed. I know people love them because if they miss the celebration they come to me looking for their trophy – or their teams ask if they can bring extra trophies to people who missed the celebration.  They actually mail the certificates to the offshore teams to make sure they get color copies and are included in the recognition.

We make sure to take lots of pictures of the celebration and send them to everyone – including the CIO so everyone gets that public recognition they deserve. One month I invited a scrum master from another organization to attend the celebration because I wanted to give her a medal for mentoring one of our scrum masters.  She emailed me after and said, “That was genius!  If our organization did this we would be rockstars!”

I speak the language of acts of service to my teams by serving them in practical ways that encourage.  The word encourage means to inspire courage so it is my job to motivate people in ways that will give them the courage to do things that they were not sure they could do before our encounter.  Many of them are just starting out so facilitating planning sessions and retrospectives for the first time is scary and they are unsure of themselves.  One way I can serve them is to step in and facilitate the first session so they can experience being in a session before having to jump into the deep end.  Then, for the next session I step aside and let someone else facilitate and help when needed so the team can learn to be independent.  Having me serve them in this practical way lets them know that they are valuable to me and they feel appreciated and have the courage to move forward on their own.

When using the appreciation language of physical touch in the workplace it is important to always consider the culture and professional appropriateness of the physical touch.  Physical touch, when used properly can be a powerful motivator.  Earlier this week in a sprint planning session with a team whenever a breakthrough was made in figuring out the solution to a problem we did a “high five”.  This was enough to keep the team motivated and moving along.  Every high five was like a milestone that told them they were going to make it to the top of the mountain.  It wasn’t much, but it fit in perfectly with the culture of the team and it worked for their more competitive nature.

As you can see, there are as many was to speak the languages of appreciation as there are people to appreciate.  The key is understanding individuals and the language that speaks to them in order to be a better leader or team member because everyone needs and deserves to be valued and appreciated.

For more information about the languages of appreciation see Gary Chapman’s book The 5 Languages of Appreciation in the Workplace.

The Language of Appreciation in the Workplace

Tags

, , , , , , , , ,

I’m a consultant.  Working with one of my current clients as an enterprise agile coach I’ve been thinking a lot about the impact that appreciation has on an organization’s success.  As an enterprise coach I am responsible for, on average, 40 teams.  (Read my last post on “Scaling the Agile Coach” to find out how I’ve been able to successfully scale this role to be able to coach this many teams.)

If you read Gary Chapman’s work on the Language of Appreciation (The Love Languages, as he calls it in several of his books), you will find that he identifies that all humans both speak and perceive appreciation in one or more specific languages of appreciation.  The primary (and sometimes secondary) language a person expects to have appreciation conveyed to them will determine what makes them feel valued and motivated.  Appreciation spoken to them in the wrong language may go unperceived and leave individuals feeling undervalued or unappreciated which will lead to low job satisfaction and low morale.

People will use their primary and often secondary appreciation language to encourage and motivate others but will also speak this language to show commitment (or how they are adding value) to a team or organization.  Understanding the differences that motivate people can help us all to identify how to create an atmosphere of creative appreciation that allows us to live the agile principle of building projects around motivated people, giving them the support they need, and trusting them to get the job done.

The five languages of appreciation as identified by Chapman are:

  1. Words of Affirmation – Words of affirmation include specific words of encouragement or praise for accomplishment and for effort.  It includes saying thank you.  Words of affirmation can be given one on one, in front of someone the person views as important (such as a supervisor or the team), or publicly.  This appreciation language focuses on the words being said to the person receiving the words of affirmation and it is about them and their contributions or character traits that are valuable and appreciated.
  2. Quality Time – Quality time includes focused attention and quality conversation.  A person who speaks this language feels valued when someone shows a genuine interest in them.  This language focuses on hearing the person receiving the quality time and about participating in the conversation with them.  Quality time also includes a sharing of life together so working side by side or going to lunch together also qualifies.  In an agile environment things like pair programming and working together collaboratively in team room are great examples of quality time.
  3. Acts of Service – Acts of service is characterized by helping with tasks that need to be completed.  Some might call this teamwork.  Some key things to remember with acts of service are: 1) Get your own work finished before offering to help someone with theirs, 2) Ask before helping, 3) Make sure to do it their way if you are going to help, 4) Finish what you commit to do and make it clear what you can commit to finish.
  4. Receiving Gifts – Receiving gifts is the vehicle for some individuals that sends the message that says, “You are valuable to me and I thought about you when you weren’t with me because I appreciate you.”  The dollar value of the gift is not what is significant but the emotional thought about the person that drove the gift to be given.  For people who speak this language, the gift becomes tangible evidence that they are valued.  It is a constant reminder that they are appreciated.
  5. Physical Touch – Physical touch in the workplace is a touchy subject. (pardon the pun) But, the truth is that for some people this is the language that speaks the loudest to them that they are truly valued and appreciated.  The key is to understand what is appropriate and acceptable and to adhere to those guidelines.  Depending on the culture of the organization there will be different guidelines but for most handshakes, knuckle bumps, high-fives, or even a pat on the shoulder are acceptable.

Read my next post, “Appreciation in the Workplace – The Language of Value” for a story of the appreciation languages in action.

Scaling the Agile Coach

Tags

, , , ,

I hear companies who have adopted scrum and realized how powerful the framework is soon have conversations around, “How do we scale scrum so that we can use it across the enterprise?”  These questions are fair and valid and each company must determine the right answers that will bring success — probably through a series of learning experiments where they will finally settle …. somewhere.

For me, the question has arisen… “How to you scale the agile coach?”

Investing in coaches is a decision that seems to be very hard for many companies because it is a question of budget.  Explaining the return on investment that a professional agile coach brings to an organization is sometimes hard to do because the benefits seem to be unquantifiable.  So, organizations who come to the realization that they need coaches will usually either post a position for a “scrum master / coach” (which is a valid position because the scrum master is actually the coach for their team) or they will hire an actual coach for their organization and assign them to be the coach to multiple teams.

How many teams a coach is expected to work with will impact the strategy used as will the actual job expectations.   I will address this blog from the viewpoint of my most recent engagement – an enterprise coach responsible for the education and growth of roughly 50 teams and their management staff.  That’s right – 50 teams.  Now, many of the people on these teams overlap into multiple teams so there are only about 270 total including roughly 50 people working offshore in multiple countries across multiple time zones.

So, how does one coach work individually across this many teams?  They don’t.  One person simply cannot coach 50 teams – it isn’t possible to give individualized attention to this many groups of people.

So, how was I able to successfully help this organization grow in only 9 months?  Very strategically.  Just like you eat an elephant — one bite at a time.

Admittedly, this organization had started doing scrum roughly two years before I came on the scene and there was a training program in place with the company where coaches trained people throughout the enterprise in agile practices and the scrum framework.  (My organization was only one of many in this very huge IT wing of the company.)  However, because this organization was so large and one good coach can only give individualized attention to 5-6 teams the coaches who had been assigned to the organization before me did what any sensible and good coach would do — focus on 5-6 teams and pray for the reinforcements to arrive soon!

As a result, the organization had 5-6 pretty solid teams, several teams that had taken some training and were trying things on their own and were at various stages of adoption and growth, and a bunch of teams that had not adopted scrum at all.

How does an enterprise coach look at an organization differently than a team coach?  An enterprise coach sees the entire organization as a whole and thinks – what core things does this organization need to mature in its adoption of scrum in order to deliver valuable software products to customers faster?  And how can I make this scale to touch as many individuals as possible to deliver the most impact quickly?

The answer came in the form of strategic blanketing the organization in phases of training, assessments, coaching, and raising up Peer Mentor Coaches from within the organization in order to create a self sustaining environment that would not be dependent upon me for future growth and maturity.  I recognized that one person is not able to coach 50 teams so instead of pretending that I was superwoman – I embraced that constraint and leveraged it to ensure that people became responsible for their own growth and maturity and that they did not wait for the coach to help them.  I used my passion for agile and motivated teams to become excited about what agility could do for them.  I told them that I believed in them and would be there to support them and help them become anything they wanted to become and that I knew they could do it if they just stepped out and tried it on their own.  Once they were excited and motivated — momentum kicked in and we were on our way!

Strategy Phase 1 — Get People Trained!

I knew that the only way people would be able to try this on their own without me there to coach individual teams daily was to get as many people as possible trained.  So, working with the management team we got buy in for training for everyone on staff – managers and teams.  For six months I spent the bulk of my time in training classes (along with coaches from other organizations who were also training their teams) teaching the fundamentals of scrum, how to write user stories, how to groom a backlog, the role of a scrum master, the role of a product owner, and of course the tool the company was using to manage the work.  I threw a big blanket over the organization and touched as many of my people as I could by teaching the classes they were taking and getting to know them in these classes.  Then, I would send them out to implement what they were learning with their teams.  I would follow up by walking the halls and talking to scrum masters and teams to check in and see how they were doing with the implementation and answering questions as needed.

During this training time, most of my work with teams was also using a blanket approach.  I would gather groups of people and do targeted coaching sessions.  Lunch and learns with all the scrum masters to talk about scrum master skills and problems.  Lunch and learns with all the product owners to talk about product owner skills and problems.  And lunch and learns with multiple closely related teams to learn about topics they were struggling with and learn from one another.  Lunch and learns with managers and scrum masters to teach managers how to communicate with scrum masters and give them what they needed to lead their teams to success.

This six months of teaching set the foundation for success but I didn’t really get to coach teams hands on very much.  I only did this when teams reached out with specific problems that they needed to solve.  If I saw a team who was really in trouble, I would set up one hour coaching sessions with them over a 4 week period and spend some one on one time with them.  But I never got to go to any of their scrum events and just hang out and observe like a team coach would — that’s not the life of an enterprise coach.  An enterprise coach has to think at a higher level.  I had to coach the entire organization — If I got lost in the weeds coaching a few individual teams they would be successful but the organization overall would fail.  I couldn’t let this organization go yet another year in that same position.  I had to keep the greater good in mind and force myself to allow these teams to grow with less hands on from me.

Strategy Phase 2 — Assess Team Progress!!

After the training goals were met in the first two quarters, the next quarter’s strategy was to 1) assess teams to see where they are in their growth and maturity, 2) help each team develop a self improvement plan so that they would be responsible for the next step in their growth and maturity, 3) identify and launch teams that had still not adopted scrum, 4) identify and develop Peer Mentors within the organization (or other organizations if necessary) to help give individual coaching attention and training to teams who needed extra attention, 5) start focusing individual coaching on new and struggling teams to help them mature and grow, 6) develop sustainable training for offshore team members.

This particular company chose the ShuHaRi maturity model as a means of assessing the maturity of agile teams.  I sat with each team and spent a few hours talking with them about their practices, struggles, how they have adapted to overcome problems and grow, and based on those conversations helped the team to determine where they fell in the company’s maturity model.  I admit that this is probably not the best practice and I would have preferred to spend time watching teams interact and work together in order to assess their maturity; however, this provided me the opportunity to meet teams with their product owners and have real conversations — often for the very first time.

The conversational assessments helped me to get a feel for what teams understood and didn’t understand about scrum.  It helped me to understand their mindset and how they viewed themselves.  It also helped me to build a relationship of trust with them where they were able to understand that I wasn’t some outsider coming in to tell them if they were doing a good job — I was there to help them figure out where they were on their journey and would help them to get wherever THEY decided they wanted to go next.  What I found through these conversations was that my teams were hungry for a coach and they were happy that the six months of training were over for me and that I had come home to be with them.

The output from the assessments was that each team left, either equipped with a self-improvement plan that they built and owned, or with a plan to actually launch their team into the scrum framework leveraging me to help them.  Those new scrum teams were paired with Peer Mentors – scrum masters in the organization (or from other organizations) who were doing well and who were willing to take someone under their wing and teach them the ropes.  Someone who could be their coach so that they didn’t have to rely only on me.

This Peer Mentoring part of the strategy was very important to me personally, not because I had so many teams, but because I am a consultant.  As a consultant and as a coach I never want to build a dependency upon me in any organization.  I am there to equip people to perform the work long after I’m gone.  If teams can’t grow and mature unless I am personally coaching them — I have failed.  My job is to teach them how to coach themselves, to coach each other, and to create an environment of growth and continuous improvement that sustains itself long after my contract with the company has expired.

Strategy Phase 3 — Start Coaching and Tackle Offshore!!

In the third quarter, I began to focus on working directly with the few teams who were struggling.  I targeted these teams by scheduling 2-3 hour blocks of time with them 1-2 days a week (sometimes during their scrum events and sometimes during the workday) and helped them in the areas they were having the most struggle.  In short — I finally got to play team coach with these guys!

For the rest of the organization, I knew all of the teams well and most of my day to day coaching with the teams who were growing on their own was done through “walk-arounds”.  Daily, I walked through the organization and stopped in briefly to talk to teams and scrum masters.  I asked them powerful questions, encouraged them, gave them some motivation, answered any questions they had, helped them problem solve, etc.

During the third quarter my focus also started to turn to the offshore members of the teams who up until this point had been left on their own.  They were working on scrum teams but were being incorporated in different ways and had different levels of understanding and were crying out for attention and training.  I determined that the best way to handle getting these guys trained was by holding short one hour training sessions via video conference and recording the sessions in order to leverage them to reach more people quickly.  So, early morning sessions were held with offshore team members and short topical training was conducted.  The videos from those training sessions were placed in a SharePoint location where all teams could leverage the training and get it to their teams or share it with new team members as they were brought on.  Any team could request that their group attend the original training sessions and questions were always answered and recorded during the session to ensure that the proper value was delivered.

Where are we today?  As of this writing we are mid third quarter.  People are excited about scrum and say that this new way of thinking is changing their lives.  They are learning and growing and motivated.  Each month we celebrate our success stories through a news letter filled with pictures of teams doing fabulous things towards agility and this adds to the momentum.  Once a quarter we have a huge meeting where everyone gathers and we celebrate teams that have taken the next step in the maturity model, give out fun prizes and a trophy for teams that are heading in the right direction even if they aren’t quite there yet, and we give the managers the opportunity to see how many people have embraced training and pour out praise for their accomplishments.  We also celebrate our Peer Mentors for giving back to the scrum community at this company.

Do we have a long way to go?  Absolutely!  I don’t know that anyone ever arrives.  But I do know that with the rate of growth I see this organization experiencing and the ownership that they are taking in their own agility, I will feel comfortable leaving them in the hands of their very own home grown Peer Mentor Coaches soon.  Another thing that I am certain about it that I’m extremely proud to be their coach.

Can Scrum Change a Community? I say, “YES!”

Tags

, , , , ,

Vision:  Provide low cost career training that will raise the median income level of the community while leveraging scrum to serve the needs of the people in the city of Ferris, TX in ways are most valuable to them.

Goals:

  1. Provide low cost or free scrum training
  2. Mentor interns in the implementation of scrum by placing them onto community scrum teams where they undertake projects that serve the community in an area of need using the scrum framework to plan and execute
  3. Coach future scrum masters and product owners to develop the skills they will need to be successful in a viable career as a paid scrum master or product owner
  4. Tutor interns until they are prepared to take the Professional Scrum Master or Professional Scrum Product Owner Certification Exams and help them obtain certification
  5. Assist graduates of the program in job placement
  6. Graduates commit to work on at least 2 scrum team projects in the year after finishing the program

Roadmap:

Q1/Q2 – 2014 – Internship #1 – Training, Projects, Exams and Job Placements round 1

Q3/Q4 – 2014 – Internship #2 – Training, Projects, Exams and Job Placements round 2

How will we measure success?

  • At Least 3 people leave the program as Professional Scrum Masters at the end of each six month semester
  • At Least 3 people enter into a new career path with increased income
  • At least six projects are undertaken and completed that serve and bring value directly to the community of Ferris, Texas.

Team Values Statement

As an agile coach, one of the first things I do when launching new teams is help them to create a Team Values Statement.

Traditional working agreements are a declarative agreement by a team regarding how they will work together to bring cohesion and enable collaboration.  They set the ground rules, so to speak, so that everyone knows what field they are playing on.  Working agreements create a safe place for teams to determine the atmosphere in which they want to work.  They also provide a way for the team to address behaviors that negatively impact that atmosphere in a non-confrontational way.  The agreement gets to be the bad guy.  If behavior doesn’t line up with the agreement, the team can either choose to change the working agreement or modify behavior to conform to the agreed standard.  Either way – the team owns the agreement.

Team Values Statements have a different purpose.  Instead of being an atmospheric  thermometer for behaviors, the Team Values Statement sets the foundational mindset from which the team will make decisions and base its actions.  The values statement is derived from the collective values of the team who discusses what they personally value in a team.  Once the team discusses and understands what their team members value, they determine which values seem to resonate across the team consistently.  They decide which  values are most important and adopt those values in the form of written values statements.  Knowing the collective values of the team helps individual team members make like decision from a common mindset.

For example if a team values producing a quality product that causes them to feel pride and accomplishment when it is delivered to customers, it will impact the choices they make when there are hard decisions to be made about sacrificing quality or missing a deadline.

Outside of traditional agile teams I have used working agreements with management teams to help build cohesion and to develop a united mindset when managing their company.  Values Statements can be useful to any type of team whether they are managers, ministers, software developers, band members, teachers, or family members – a common mindset helps create a safe and collaborative environment where people can unite to succeed.

Agile Manifesto — What it means to me

Tags

, , , , ,

The Agile Manifesto talks about uncovering better ways of developing software by doing it and helping others do it.  It goes on to state that through this work and helping others, four consist values have developed.  To me, these values go far beyond software development and set a platform for making decisions and forming thought processes.  For me, these values form the mindset of agility which spills over into every area of life.  Because my mindset is one of agility, I can’t help but take agile out into the world beyond software development.  Everyday, I work with people and see agile changing mindsets and impacting lives for the better.

We value:  Individuals and interactions over processes and tools

This value represents that understanding that an agile life is filled with humans!  Humans are interesting, complex, intelligent, diverse, ever changing, and FUN!  Processes are important and so are the tools that we use to get work done.  But, when processes and tools become more valuable to us than the people who use those processes and tools they have over-stepped their boundary.  Processes and tools are created by people to solve problems, work more efficiently and to bring consistency.  They should not be jails of solitary confinement where we get locked in and become slaves to the thing we created to help us!  We cannot replace people with process and tools.  When individuals interact with one another, creative ideas form, problems are solved, momentum can is gained, new perspectives are shared, and growth occurs.  People learn from interacting with each other.  We become more aware of the world around us and more aware of ourselves when we interact with individuals of various types.  When we take people out of the equation and rely on the processes and tools, our work suffers.  Processes and tools are meant to assist people and should be used in this manner.  They should never become a replacement for interacting with people — Text messaging is a prime example … Texting is a tool that can be used for quick communication when direct conversations are impossible but if we allow this to take away our ability to speak to and directly interact with individuals we become a slave to the tool and it has more (negative) power than originally intended.

We Value:  Working software over comprehensive documentation

To me, this value says:  Let’s don’t just talk about it.  Let’s do something about it!  Let’s build it!  I can spend a lot of time writing a document that tells you every detail of what I can do and what I want, or I can write just enough to make sure you get an understanding of the direction we are heading and provide you with something you can touch and feel to see if it makes you happy.  I don’t want to waste your time or money and I don’t want to waste mine either so lets build this thing together.

We Value:  Customer collaboration over contract negotiation

I’ve got two choices when serving customers.  I can make them outline every detail of everything they will ever want from me and hold them to it rigidly – charging them for every slight shift.  OR, we can agree to create something great together and set some boundaries in a contract that protects us both and start collaborating to ensure that we get to the finish line together!

We Value:  Responding to change over following a plan

 Plans are good.  They are needed.  They are necessary.  But, change is reality.  Why do we pretend that we don’t know that change will occur?  People change.  Circumstances change.  Budgets change.  Markets change.  The world around us changes every single day.  Instead of being ruled by a rigid plan that we know becomes obsolete and unrealistic just moments after it is created, lets plan to change.  Plan in shorter periods of time that we are more likely to be able to predict for success instead of multiple months or even years down the road.  Get feedback and don’t be mad when the customer realizes that they didn’t know what they wanted until they saw what you provided.  Be flattered that what you showed them generated enough interest and excitement that they could see it become something great that met their needs and provided great value.  Isn’t that the end goal?  If executing upon and controlling a plan is the primary goal, producing a valuable product that satisfies the customer must take a back seat to this objective.  But, if customer satisfaction is the target – our plans must be flexible …. agile even!

The Agile Manifesto Original Signers:

 Kent Beck Mike Beedle Arie van Bennekum Alistair Cockburn Ward Cunningham Martin Fowler James Grenning Jim Highsmith Andrew Hunt Ron Jeffries Jon Kern Brian Marick Robert C. Martin Steve Mellor Ken Schwaber Jeff Sutherland Dave Thomas
Follow

Get every new post delivered to your Inbox.