Archive for the ‘Agile Management’ Category

Quick Reference: Kotter’s 8-Step Change Model

Thursday, August 5th, 2010

This model is good for people to consider when doing an Agile-Lean Transformation.  I use a process based on this model when working with clients, although the reality of work on the ground often means not following this model perfectly.  Without further ado, here is the model:

Step One: Create Urgency

What is the critical reason for change?  What is the “burning platform”?  What reason can people get behind emotionally for the pain of change?  Why are you considering agile and lean, and how is it urgent to use these methods?

Step Two: Form a Powerful Coalition

I call this as the Agile-Lean Transformation Team.  These people are usually managers and executives who can make change happen by virtue of budgets and positional authority.  They help with training, coaching, team formation, ongoing assessment, planning etc.

Step Three: Create a Vision for Change

The coalition creates a strongly worded statement that helps everyone see how they fit into the change process and results.  Tie the use of Agile-Lean to the end result.

Step Four: Communicate the Vision

Constantly!  Every opportunity, repeat the statement, discuss its application and implication.  Use both formal and informal methods.  Share links to information about Agile and Lean, create an elevator pitch and use it constantly.

Step Five: Remove Obstacles

The coalition supports staff who are struggling with how to make the change real in practical terms.  For example, an agile team might want a proper team room.  The lack of such a room is an obstacle to be removed by the coalition.

Step Six: Create Short-Term Wins

Choose places to focus effort that will be successful pilot projects.  Make sure that successes are broadly communicated.

Step Seven: Build on the Change

Make sure to have a backlog of projects to do using Agile-Lean, and make sure that as you go you are improving your use of Agile-Lean.  It takes time to break down old habits.

Step Eight: Anchor the Changes in Corporate Culture

Ensure that new staff are immediately and effectively educated on the use of Agile-Lean, and ensure that Agile-Lean continues to pervade the thinking and behavior of people throughout the organization (not just IT!!!).

(NOTE: this is based on the book “Leading Change” by Kotter, and a web page about this model.)

Share and Enjoy:
  • TwitThis
  • LinkedIn
  • Digg
  • Technorati
  • del.icio.us
  • Propeller
  • StumbleUpon
  • Reddit
  • Fark
  • Slashdot
  • Blogsvine
  • Google Bookmarks
  • Furl
  • Facebook
  • BlinkList
  • YahooMyWeb

Case Study: Agile Process and a Twist on “20 Percent Time” for a Self-Organizing Volunteer Team

Sunday, May 9th, 2010

Cross-posted from the personal blog of David D. Parker: A Changemaker in the Making

I am engaged in a learning process with a charity that has undertaken to implement a new model of volunteer coordination based on OpenAgile, an open source agile method.  We recently held an orientation with our new volunteers.  In the hopes that this information will be useful to others who are trying to innovate on their  model of volunteer coordination, here are the instructions I shared with the volunteers.  In summary, they cover our process for sharing tasks, the tools we use to communicate with each other, and our use of what we are calling “60/40 time” a twist on Google’s “20 percent time“.

ORIENTATION INSTRUCTIONS:

I. Agile Volunteer Team Process

We are all here to support the charity. We are inspired by its mission and goals, and we want to help in a way that draws on all of our abilities, knowledge, skills, and creativity.
Our team uses a specific system for producing valuable results. We work in Cycles of 5 weeks. The charity’s staff talk with the stakeholders and decide what steps are necessary for accomplishing the organization’s goals. Each one of these steps, called Value Drivers, add up to providing value for the stakeholders once they’re delivered. The staff also decide the priority order for completing the Value Drivers.
In week 1 of the Cycle, there is a planning meeting with all the volunteers who are committed to doing work during the 5 week Cycle. All volunteers are urged to attend and participate.
  1. The meeting begins with reflecting on the results of the previous Cycle. These observations and lessons are an important part of the planning process.
  2. Next, the team of volunteers works together to create a Cycle Plan by taking the highest priority Value Driver and breaking it down into tasks. Tasks are represented by sticky notes on the wall.
  3. Third, the volunteer team counts the number of tasks needed to complete the highest priority Value Driver. If the past Cycle showed that the team can complete more tasks, then the team takes the next Value Driver in the list and breaks it down into tasks. This process continues until the team makes a unified decision that it has taken on the amount of work it can actually accomplish.
  4. The last part of the meeting is commitment. Everyone shares the responsibility for completing the Value Driver (represented by multiple tasks) by the end of the Cycle of work. Therefore each volunteer must truthfully commit to completing the work. If a volunteer is not comfortable committing to all the work on the task wall, then some tasks must be removed until everyone is able to commit.
In week 2, 3, 4, and 5 of the Cycle, the team of volunteers complete the tasks in the Cycle Plan (aka “doing work”).
  1. Volunteers are free to take whatever task is of interest to them. If they need more information about the task, they ask the other volunteers or the staff for details.
  2. When a volunteer begins a task, they sign their name on the bottom of the sticky and move the task into the “in progress” column.
  3. When a volunteer completes a task, they move the task into the “done” column.
  4. There are weekly conference calls where all the volunteers check in. They answer 4 simple questions
    1. What did I do last week?
    2. What will I do this week?
    3. What did I learn/observe?
    4. What obstacles, if any, are affecting my ability to do work?
  5. New tasks can be added to the wall based on any of the volunteers’ observations, obstacles, clarifications, questions, urgent new tasks, etc. If you add a new task to the wall, add your name to the bottom of the task, so that other volunteers can know who to go to for questions. Note that these new tasks must also be completed by the end of the 5 week Cycle.
At the end of the 5 week Cycle, the team presents the valuable results it has produced to the charity staff/stakeholders. Any insights, observations, corrections, etc. are factored into the next Cycle Plan.

II. Communication Tools

Over the time we have worked together, the volunteer team has decided to use a few tools to help us communicate. The main tool is the task wall and sticky notes. The secondary tool is a shared Gmail account.
NOTE: This list of instructions is a working, evolving document; it is not set in stone. Volunteers are encouraged to work together and adapt the way we do things to create a system that works well for all of us.
ACCOUNT INSTRUCTIONS:
  1. Login and read new messages
  2. Emails in the Inbox means there is work to be done (if the task is complete, archive the email to remove from the Inbox aka the To Do List)
  3. Apply Labels – Gmail doesn’t use folders; it uses labels instead. Apply labels to emails to assist other volunteers with how to treat the content of that message.
  4. Write up volunteer tasks for the task wall (Note: Label as “Task Written & Posted”)
  5. Get work done:
  6. Move the task on the wall to in progress
  7. If the task came from an email, label the task with your name
  8. When the task is complete, label as “Task Complete” and archive the email so it doesn’t appear in the Inbox
CURRENT LABELS:
  • ??? – this means more information or context is required to understand the request –> ASK QUESTIONS, or get help, to complete the task
  • By Volunteer Name –> This means the task/email is in progress; A volunteer labels the email with their name when they accept responsibility for a particular task
  • FYI (For Your Information) – these are emails that contain information that is relevant to volunteers, but does not necessarily require action be taken. If action is required, write up a task and post it on the wall)
  • Task Complete – Use this to label When a task is complete; archive the email so it doesn’t appear in the Inbox
  • Task Written & Posted – apply this label after you write up the task and post it on the wall
  • Social Media – these are emails that apply specifically to social media like Twitter, Facebook, etc.
  • Website – these emails are relevant to website updates

III. What is 60/40 Time?

There are many reasons why people volunteer.  Here is a short list that comes from Molly Schar’s article Making the Most of Nonprofit Volunteers:
  • Belief in the mission of the charity
  • Desire to “give back”
  • Meet new people
  • Make new business contacts
  • Invited or inspired by another volunteer or staff member
  • Improve resume
  • Learn new skills
  • Benefits such as free events
We want all of our volunteers to get the most out of their experience here. Rather than insisting that every moment of a volunteer’s time be spent on completing tasks on the wall, we ask you to split your time 60/40. We want to give our volunteers freedom to spend a large portion of time doing things that satisfy their motivations while still providing value to the organization. For example, if someone has an interest in building skills in using social media, but there aren’t currently any tasks on the wall related to social media, the volunteer would be encouraged to use 40% of their time using social media to benefit the charity. The remaining 60% of the time is essential for delivering other important results to the organization. We aspire to having a trusting environment, so it is up to you to monitor how you’re spending your time. During progress updates, all volunteers are encouraged to share what they’ve accomplished during their 40% time. This will help other volunteers to learn what motivates their teammates and will give the team information that can be integrated into future Cycle Plans.
Share and Enjoy:
  • TwitThis
  • LinkedIn
  • Digg
  • Technorati
  • del.icio.us
  • Propeller
  • StumbleUpon
  • Reddit
  • Fark
  • Slashdot
  • Blogsvine
  • Google Bookmarks
  • Furl
  • Facebook
  • BlinkList
  • YahooMyWeb

Case Study: OpenAgile for Charity Volunteer Management

Friday, March 12th, 2010

Cross-posted from my personal blog: A Changemaker in the Making

For the past several weeks, I have been helping a small charity solve a dilemma. Because the charity is well-recognized for their good work, they regularly attract volunteers who want to help. Unfortunately, the two overworked staff members are too busy to recruit, train, and manage them. My approach has been to use OpenAgile, an open source system for delivering value to stakeholders, to implement a few simple techniques to help them.

There are several aspects of OpenAgile that fit very well for managing volunteers:

1. Self-Organizing Behavior

This means people “volunteer” for tasks instead of doing them based on a tightly defined role or having someone tell them what to do. This frees the staff from having to assign work. Instead, they identify priorities and rely on the volunteer’s creativity and personal motivation to do the task in their own way.

2. Shared Responsibility for the Workload

When there is more than one volunteer, they work in a team and share the responsibility for the workload. The team of volunteers discuss the priorities of the organization, and decide among themselves what tasks need to be completed. Then, they create and commit to a 1-2 week short-term plan that will deliver those results. Finally, they come back after the 1-2 week period and reflect on what they accomplished.  This pattern of action, reflection, learning, and planning is one of the Foundations of OpenAgile.

3. Visible Tasks

This means that all people doing the work should be able to see what tasks needs to get done, what is in progress, and what tasks are done. One technique that co-located teams often use is simply posting tasks on a wall using sticky notes. (Check out my OpenAgile Task Wall Prezi) Another cool idea is Card Meeting which works on the same principle, but it can be useful for distributed teams.

4. Learning Manifesto

The emphasis on learning is perhaps the most important aspect of OpenAgile that aligns with the needs of volunteer management.  The Learning Manifesto states that “Learning is the key that unlocks human capacity.”  Volunteers are drawn to an organization because of its vision but can get pushed away when they feel they’re underutilized or not able to contribute in a meaningful way.  By making it explicit that the volunteer is primarily accountable for learning, the organization creates a safe space for experimentation and innovation.

Share and Enjoy:
  • TwitThis
  • LinkedIn
  • Digg
  • Technorati
  • del.icio.us
  • Propeller
  • StumbleUpon
  • Reddit
  • Fark
  • Slashdot
  • Blogsvine
  • Google Bookmarks
  • Furl
  • Facebook
  • BlinkList
  • YahooMyWeb

Agile method for the Financial Services industry

Tuesday, June 30th, 2009

There are two things every leader needs to know to be successful: first, a leader must clearly articulate what they expect, and second, they need to inspect what they expect on a daily basis. The big challenge though is how do you stay on top of changing priorities? And how do you avoid micro management and driving your team crazy?  This is why OpenAgile, in my opinion, will be very quickly embraced by management teams around the world. It has all the necessary tools to ensure success.
 
For the past 6 months, I have been working with a financial services team in Slovakia to introduce them to Agile methods. I started with Scrum, a methodology and framework that has been used in the Information Technology sector for the past 5-10 years.
 
The Slovak team started using Scrum with one team of 6 managers. They grew to have 4 teams actively managing their activities and projects using Agile Scrum, and another 2 teams are planning to launch soon. The feedback from the team members has been positive and the team leader is very impressed with the methodology, the activity levels, and the results. This organization/structure is doing very well in the very competitive marketplace that is Slovakia. I interact with the teams on a regular basis and often travel to Slovakia from Canada on business, so I have the opportunity to work closely with the structure, leader, and the teams.
 
The only challenge with Scrum is that it is somewhat restrictive regarding the types of work that is recorded and reported upon. Scrum does not accommodate repetitive or calendared activities. Fortunately, Berteig Consulting has developed OpenAgile as a new Agile method that allows for the tracking and reporting of all the Scrum work activities plus these new categories. I find OpenAgile more inclusive and representative of the Financial Services work environment.  
 
I’m now in the process of transitioning the Slovak teams from Scrum to OpenAgile. I believe OpenAgile will be a much better methodology for this team, and for all non-IT organizations, as it creates an environment for teams to achieve even greater success.
 
The OpenAgile method teaches the team members to self-manage. And rather than replacing the role of the team leader, that person is empowered to truly lead because they are free to focus on creating an environment where the team can thrive. OpenAgile helps the team to clearly identify the key strategic and tactical goals, and it allows the team to systematically inspects what everyone expects to be done.

There is actually a third thing every leader needs to know. It’s called OpenAgile.  And you can learn more about OpenAgile at http://www.openagile.com/ or by contacting Berteig Consulting http://www.berteigconsulting.com/Contact

Share and Enjoy:
  • TwitThis
  • LinkedIn
  • Digg
  • Technorati
  • del.icio.us
  • Propeller
  • StumbleUpon
  • Reddit
  • Fark
  • Slashdot
  • Blogsvine
  • Google Bookmarks
  • Furl
  • Facebook
  • BlinkList
  • YahooMyWeb

Why try to be good?

Monday, June 29th, 2009

What motivates human beings to do the right thing?  To do good deeds, to be truthful, to be kind, to be helpful, to try to make the world a better place?  First of all, we have to realize that everything we say and do has an actual, real effect on our environment for better or for worse.  Every time we help someone, or tell the truth, it actually makes the world better in some small way, just as when we lie, cheat, steal or speak unkindly to someone, no matter how small the affront, we actually make the world worse.  In fact, our thoughts, words and actions can really have only one of two basic effects on the world – they can make it better or make it worse.  Period.

There are some powerful cultural forces in our society, most obviously the constant stream of materialistic propaganda through various forms of hypnotic media, that influence the way we perceive our ability to contribute to the betterment or worsening of our environment.  The basic message is that individuals can’t affect any real fundamental change in society (i.e., their environment) and that the best any of us can do is to change our position, rank or class within the permanent structures of our society.  Therefore, “only the strong survive”, “get what you can while you can” and the “pursuit of happiness” have become not only slogans that we live by, but conceptions of human nature that have constructed our social reality.

For example, the concept behind “the pursuit of happiness” is that happiness is something external and fixed that a person has to find somewhere “out there”.  Embedded in this “right” is the implicit message that “average” individuals and groups do not have the potential to exert influence on, and contribute in any meaningful and lasting way to the shaping of the prevailing social order.  Thus, there is always a better neighborhood to live in, a better employer to work for, a better school for your kids to go to, etc.  It disempowers us all from thinking that we can get together and do something right now about our immediate reality.  ”Don’t even bother”, it says, “you won’t be able to change anything anyways – you’re wasting time, effort, and worst of all – money!  Better to lie just a little, cheat just a little, step on your neighbor just a little in order to protect your own little piece of turf.”

Understanding the truth about our reality – our potential to contribute to the betterment of the world – is what will actually begin to motivate us to be good – that is, the fact that our good thoughts, good words, and good actions can and do make the world better.  ”Better” becomes not merely an external pursuit that we fight to get our little piece of; rather, it is an organic, sembiotic process of growth.  For one thing, it requires vision: What would the world be like, for example, if everyone always tried to tell the truth?  Would it really be so bad?  Would human affairs come to stand still?  Would the economy crumble?  Or would it, rather, begin create something new… something better?

Share and Enjoy:
  • TwitThis
  • LinkedIn
  • Digg
  • Technorati
  • del.icio.us
  • Propeller
  • StumbleUpon
  • Reddit
  • Fark
  • Slashdot
  • Blogsvine
  • Google Bookmarks
  • Furl
  • Facebook
  • BlinkList
  • YahooMyWeb

Professionalism and Agility

Sunday, June 7th, 2009

Recently, I have been reading Outliers by Malcolm Gladwell. Fascinating reading. In this book, Mr. Gladwell chronicles some of the backgrounds of top professionals in artistic, sport and business endeavors. He tried to determine why these individuals/groups have accomplished so much in their lives and why they are in the top of their profession. Tiger Woods, Bill Gates and the Beatles are a few of the many professionals he examines. There should be no doubt in your mind that Tiger Woods is the top golfer, Bill Gates is a very successful entrepreneur, and the Beatles are a prolific band.

Please forgive me Mr. Galdwell if I summarize and distill your findings into a few short sentences. The answer is 10,000 hours. Each of these individuals or groups put 10,000 hours into their chosen profession before they arrived at the top. They viewed their professions differently, were passionate about what they did and behaved differently when learning their profession. I am not suggesting you need to work for 10,000 hours before you are successful. I am suggesting if you adopt the same methods they do, you will increase your chance of success.

As I observed these top professionals, I began to see similarities in a number of areas. They seem to share a comfort in their ability to grow and develop. I am not sure they set out to be the top but they certainly thought they would overcome what life threw at them and they trusted their own capacity to excel. I have found that giving yourself a steady message of what is possible helps you deal better with life and to overcome all the negatives around us. As an example, I seldom read the newspaper or watch the news, for this barrage of negative messages affects my outlook of what is possible. It seems to me that these top professionals insulate themselves from negative messages as well.

Next, they have incredible self discipline skills. They practice their profession with passion. They don’t believe in luck as much as they believe in hard work. This is where the 10,000 hours come into their development. They are constantly practicing to improve and master their profession. The top professionals did not achieve their position through luck, they attained the position through hard work.

To summarize, their methods are to be positive about your ability to cope with the future, give yourself positive messages, be disciplined about mastering your profession and be prepared to work hard to achieve the position of the professional.

There is a quote I like that was told to me by a businessperson from Jamaica. When asked his view of life, he said “I refuse to be held hostage by circumstances!” The top professionals choose their future and are agile as they cope with what life offers.

It seems to me another reason why these individuals are so successful is that they were very agile in their approach to life. They created their future rather than follow others. Through their own personal agility they made the right decisions to gain a top position in their chosen profession.

So the question I have been wrestling with is this: If they can be the top, then why not me? What is holding me back? Well, if you have ever spent time with me, or read any of my books, you would know the answer. The only thing holding me back is me. Can I get better? Yes, I can. Can I work harder? Yes, I can. Can I be more successful? Yes, I can. Can I be more agile in my approach to life and its challenges? Absolutely yes!

So how about you? In these troubled economic times, we have an opportunity to re-invent ourselves. The best way to survive and thrive from our current situation is to build the future we desire. Rather than expending a lot of energy worrying about your current situation, you should be taking that energy and using it to take charge of your future and build a new reality. Approach whatever life throws at you with agility. I believe success is a choice. Make good choices and everything is possible.

Share and Enjoy:
  • TwitThis
  • LinkedIn
  • Digg
  • Technorati
  • del.icio.us
  • Propeller
  • StumbleUpon
  • Reddit
  • Fark
  • Slashdot
  • Blogsvine
  • Google Bookmarks
  • Furl
  • Facebook
  • BlinkList
  • YahooMyWeb

Growth Facilitator role on an OpenAgile team

Friday, June 5th, 2009

This is my first post on the Agile Advice blog.  In fact, it’s my first blog post ever.  Before joining the Berteig Consulting team, I had never even heard the words Agile, Scrum, Lean, or OpenAgile.  After all, my background is marketing, community relations, and sustainability!  Needless to say, I’ve gone through some intense learning about the role of the Growth Facilitator.

The responsibility of the Growth Facilitator is about more than simply prioritizing New Work goals and tasks. I see the role as contributing to the organizational culture, and helping to build the business in a sustainable way. “Sustainability” is an important concept at BCI. It means that we are committed to conducting business in a way that is respectful of the environment, society, and the economy. At the same time, it means that the BCI team operates at a sustainable pace, finding ways to balance our work and life so that we don’t burn out.

As Growth Facilitator, I am also responsible for guiding the team toward delivering greater value for our stakeholders. At Berteig Consulting, our stakeholders don’t just include the company’s owners. Our stakeholders include a wide range of groups, including customers, suppliers, employees, and our families, all without whose support nothing we do would be possible. Delivering value to our stakeholders requires that we keep them in mind when we commit to our tasks each week.

One of the important lessons I learned was to give the team S.M.A.R.T. – Simple, Measureable, Achievable, Relevant, and Timebound – goals and give them space to come up with the tasks to meet the goal. When I first started, I made goals that were broad, saying for example “to take care of our clients” or “to work at a sustainable pace.” Rather than stating goals, I realized that I was making statements of the team’s shared values. And while the team integrated these thoughts into our behavior, it was nonetheless challenging to spin off specific tasks that we could work on. Now, I try to ensure the goals I create conform to a user story format and meet S.M.A.R.T. criteria. For example “Berteig Consulting can update the Certified ScrumMaster course content so that all CSM course participants receive the best value in the market.” As soon as I made the direction clear, the team self-organized and generated tasks required to achieve each goal.

Another key lesson of developing the direction for the team was allowing the Team Members time to review the next Cycle’s goals in advance of the Cycle Planning Meeting so that they could provide feedback and seek clarification. This became particularly important when one team member jumped on a business opportunity that created a significant amount of New Work. We simply could not overlook this great opportunity, and we moved it to the top of the New Work priority list and put it in the next Cycle Plan.

Last, I learned that the Growth Facilitator and Process Facilitator have a complimentary relationship that requires frequent consultation. As the Process Facilitator goes about helping the team overcome obstacles, it can become clear that the team needs to address a systemic challenge during one of the upcoming Cycles. The Growth Facilitator then states the need as a Cycle goal in a S.M.A.R.T. format, allows the team time to give feedback, and prioritizes the goal in the New Work list. When the goal is brought to a future Cycle Planning Meeting, the team breaks the goal into tasks and solves the systemic obstacle that the Process Facilitator identified.

These lessons have helped me understand how the Growth Facilitator role extends beyond prioritizing New Work and guiding the team’s value delivery. The role also fosters the culture in which the work gets done – working at a sustainable pace, taking care of our customers, and maintaining unity of vision.

I would love to hear your thoughts about anything I’ve expressed here. Berteig Consulting is a deep-learning environment, and your feedback is invaluable.

David D. Parker
VP Marketing and Sustainability
Growth Facilitator

Share and Enjoy:
  • TwitThis
  • LinkedIn
  • Digg
  • Technorati
  • del.icio.us
  • Propeller
  • StumbleUpon
  • Reddit
  • Fark
  • Slashdot
  • Blogsvine
  • Google Bookmarks
  • Furl
  • Facebook
  • BlinkList
  • YahooMyWeb

What are Ways to Measure Productivity?

Tuesday, April 14th, 2009

One of the most difficult aspects of doing Agile, is to find reasonable, do-able, agreeable ways to measure productivity.  Many organizations don’t measure productivity or only use very indirect indicators.

What do you do to measure productivity and how is it working for you?  If you don’t measure productivity, why not?

Share and Enjoy:
  • TwitThis
  • LinkedIn
  • Digg
  • Technorati
  • del.icio.us
  • Propeller
  • StumbleUpon
  • Reddit
  • Fark
  • Slashdot
  • Blogsvine
  • Google Bookmarks
  • Furl
  • Facebook
  • BlinkList
  • YahooMyWeb

Agile Beyond Software Yahoo Group Created – Please Join!

Tuesday, March 17th, 2009

I’ve just created a Yahoo! group called “Agile Beyond Software“.  From the group description:

This is a group for people who are interested in sharing stories, experiences, practices, and questions about applying agile beyond software. This could be in management, marketing, engineering, small business, personal life, community groups, or any other areas where you think it might be worth trying!!!

We welcome people trying to adapt any of the specific agile methods. It could be Scrum, XP, Lean, DSDM, FDD, AgileUP, etc…

Please join this group if you are interested in exploring this topic.  As well, if you know people who are doing this, please consider inviting them to join as well!

Thanks!

Share and Enjoy:
  • TwitThis
  • LinkedIn
  • Digg
  • Technorati
  • del.icio.us
  • Propeller
  • StumbleUpon
  • Reddit
  • Fark
  • Slashdot
  • Blogsvine
  • Google Bookmarks
  • Furl
  • Facebook
  • BlinkList
  • YahooMyWeb

Scrum Gathering – Orlando Florida – Day 1 Summary

Monday, March 16th, 2009

The first day of the Scrum Gathering in Orlando is finished.  I had a great day all-in-all.  I went to 3 and a half sessions, took a nice sun break in the afternoon, and then mingled at the evening reception.

Some observations:

More People Using Agile and Scrum for Non-Software

This was interesting.  When I actually spent time talking with people I heard several times that people were using agile approaches in non-software environments.  One person is working with an oil company to apply agile methods to all project work.  Another two people are extending agile / Scrum into marketing departments.  And one other person was applying agile into the whole organization.

Of course, with OpenAgile, I’m very interested in all this.  I’m hoping that I can organize some sort of group / institute / organization for people using agile methods outside of software development.  If you’re interested, please contact me on LinkedIn or Facebook or any other method you wish.  People seemed to be in general agreement that this is still new stuff, and that they are having to make adaptations to make agile work in these other environments.  After all, not all work is purely creative or problem-solving!

Economic and Recession Fears

Gregory Balestrero gave a talk about the relationship between the PMI and the Scrum Alliance.  I felt that his talk was much more 30000 foot level and that it probably wasn’t quite right for the audience.  The questions people asked at the end seemed much more appropriate for someone who was an author of the PMBoK rather than the CEO of the PMI.  There was a mis-match between presenter and audience.  At any rate, Gregory spoke quite a bit about the economy and the fears people have about it.  He emphasized that this time actually represents a real opportunity for organizations to get better at doing projects by focusing on value.  I couldn’t agree more!

As well, in my discussions with several other individuals who are coaches or run agile coaching businesses, I heard quite frequently that the past few months have been hard on business here in the United States.  One company has actually laid off some coaches.  This is in line with our experience at Berteig Consulting… up to a point.  December and January were slow, and in fact slower than “normal”, but we still did very well in the Dec. to Feb. quarter.  Clearly the Canadian market is still moving well, and there is a recognition that agile and Scrum are a means to help organizations get through these tough times.

One a related note, the resort we are staying in and in which the conference is being held is the Gaylord Palms.  Apparently, bookings are way down at the hotel to the point where they have temporarily closed some of the restaurants in the resort.  Likewise, when my family went to a water park during the day today, some of the rides were closed because there were so few people.  Please remember: this is Spring Break!!!  Clearly tourism is _way_ down.

Reconnecting with Friends and Collegues

I’ve met up with (in no particular order): Tobias Mayer, Alistair Cockburn, Catherine Louis (from Nortel), Sanjiv Augustine, Mike Vizdos, Carole Marks, Mitch Lacey, Jim Cundiff, Gabby Benefield, and probably others that I can’t remember.

I also met for the first time several people.  I hope I can keep in touch with everyone!

Highlight of the Day

Mike Cohn gave a presentation on Leading Self-Organizing Teams.  It was fantastic.  My favorite part of it was his introducing the CDE (Containers, Differences and transforming Exchanges) model.  In this model, self-organization is positively influenced by appropriate constraints on the containers, differences and transforming exchanges among the people who are asked to self-organize.  To explain: containers define in-ness vs. out-ness for participation, scope of work, environment of the group that is self-organizing.  Differences are the variations in the skills, qualities, attitudes, knowledge etc. of group members.  And transforming exchanges are the interactions between group members both amongst each other and with outside groups, where such interactions cause a transformation of some sort: creation of value, sharing of knowledge, new activities, etc.

By using the CDE model, we can diagnose challenges facing an agile team.  Mike Cohn included a number of scenarios for us to use to practice the application of this model.

Looking Forward to Day 2

Hopefully Day 2, which is primarily and Open Space event, will be even more interesting that Day 1.  I will continue to post frequent articles about the events of the day!  Please feel free to ask for more details in the comments… or to suggest that I connect with someone, or to bring up a topic for the Open Space portion.

Share and Enjoy:
  • TwitThis
  • LinkedIn
  • Digg
  • Technorati
  • del.icio.us
  • Propeller
  • StumbleUpon
  • Reddit
  • Fark
  • Slashdot
  • Blogsvine
  • Google Bookmarks
  • Furl
  • Facebook
  • BlinkList
  • YahooMyWeb

Certified Scrum Product Owner training – New Seminar

Monday, February 2nd, 2009

We are pleased to announce a new seminar: CSPO – Certified Scrum Product Owner.  We have found in our coaching assignments with our various customers that they were struggling to find qualified and well trained Product Owners.  Therefore we are offering this new seminar.  During this seminar we will train the participant how to do the fundamental tasks of the Product Owner in the Scrum environment.  The attendees will learn how to develop a comprehensive Product Backlog, competently add value to the Scrum team during the Sprint, fully understand how Scrum works and their role within it.  With a maximum class size of five people, this seminar is designed to allow participants to dig deep into the role of the Product Owner.  The first day will be an introduction to Scrum slanted towards the role of the Product Owner.  The second day will be an in-depth look at this role.  Our first CSPO seminar will take place soon.  Please refer to our website http://www.berteigconsulting.com/CSPOCourseDescription to reserve space for yourself or others on your team.

We look forward to adding value to your team!

Upcoming Certified Scrum Product Owner training seminars:
April 23 – 24, 2009 in Newmarket (Berteig Consulting Office)
June 25 – 26, 2009 in Newmarket (Berteig Consulting Office)
July 23 – 24, 2009 in Newmarket (Berteig Consulting Office)
August 20 – 21, 2009 in Newmarket (Berteig Consulting Office)
September 17 – 18, 2009 in Newmarket (Berteig Consulting Office)

If you would like more information contact us at sales@berteigconsulting.com

Share and Enjoy:
  • TwitThis
  • LinkedIn
  • Digg
  • Technorati
  • del.icio.us
  • Propeller
  • StumbleUpon
  • Reddit
  • Fark
  • Slashdot
  • Blogsvine
  • Google Bookmarks
  • Furl
  • Facebook
  • BlinkList
  • YahooMyWeb

Agile Productivity Measures

Monday, February 2nd, 2009

Scott Ambler has written a couple good articles about measuring productivity with velocity.  Acceleration: An Agile Productivity Measure. and Examining Acceleration.

From what I understand, this is a measure of the effect of agile on the relative improvement over time of a team.  I would beg to differ that it is a measure of productivity.  Productivity is value delivered over time.  If team A is delivering $5/week and team B is delivering $5000/week, then knowing that team A is accelerating faster than team B isn’t terribly important, particularly if the market can’t bear to absorb $6/week of whatever team A is producing.

Measuring productivity is hard.  I would love to hear from people who have tried various means to measure productivity.  I measure productivity in our business, but I can do that because we are small and everything we do has a direct effect on the bottom line.  Does your business run with that transparency?  If not, why not?

Share and Enjoy:
  • TwitThis
  • LinkedIn
  • Digg
  • Technorati
  • del.icio.us
  • Propeller
  • StumbleUpon
  • Reddit
  • Fark
  • Slashdot
  • Blogsvine
  • Google Bookmarks
  • Furl
  • Facebook
  • BlinkList
  • YahooMyWeb

Changing Patterns of Thought for Defining and Expanding Done

Monday, January 26th, 2009

“Without changing our patterns of thought, we will not be able to solve the problems that we created with our current patterns of thought.”  -Albert Einstein

“We are what we repeatedly do. Excellence, then, is not an act, but habit.”  -Aristotle

Among leading Agile thinkers, coaches, trainers and practitioners there is a rich, ongoing discourse around a subtly deceptive concept  – the concept of the Definition of Done.  Within this discourse, a singular constant challenge is emerging:  old patterns of thought.

For example, there is an old pattern of thought that tells managers of software companies that at least some part of the Definition of Done must be imposed on teams in order to protect a universal standard.  Rationalizing this antiquated thought pattern seems to have become a rigorous intellectual discipline in and of itself.  One of the most prevalent excuses to which many managers have invested a great amount of mental and emotional energy seems to be around the challenging concept of multiple Agile teams working together on the same project (or product).  Surely, in such cases there needs to be some kind of imposed standard that all teams need to comply with in order to avoid chaos in the main build, yes?  In fact, this is the exact wrong approach to take.

We also seem to become confused at times by our own limited understanding of the words that we use when attempting to talk about things we are or are not trying and learning to do.  The more we learn about doing something, the more we are able to talk about it in practical terms.  Since theoretical discussions around semantics rarely result in appreciably improved behavior/results, we will endeavor here to address this subject with both brevity and caution.

Our old patterns of thought make understanding many words, including the word definition and the word done, problematic.  We tend to think of these words as implying static, rigid, absolute conditions; for example, the way we tend to think of the word definition in terms of the definitions of words.  We like to think that those definitions are relatively stable.  Indeed, there are some real benefits to this.  We can have conversations with people and assume that for the most part their understanding of the definitions of the words we are using are similar to our own.  But even with words, there can be more than one definition, which already makes the definitions of words less static than they often seem.  At some level, one might even ask – who actually decides on the definitions of words?  Is there an actual authority out there (not merely the self-proclaimed “official” authorities) that decides on definitions and hands them down to us?  Some may say “yes, indeed, namely the authoritative texts of the world’s religions,” for example.  On the other hand one could also say that the definitions of words have evolved through the ages (just as languages have) as humanity has received progressively more complex guidance from religious texts according to its evolving capacity (compare, say, the Bhagavad Gita to the Quran).  But that is another conversation.  What is important to acknowledge here is that the meanings of words expand and evolve over time given the capacity of the individuals who use them to develop new patterns of thought and that the energy required to do so is tremendous, even epochal.

An old pattern of thought construct around the word done is equally problematic.  A conversation limited by a rigid understanding of the concept of what done means, is and looks like can quickly take us spinning off into the stratosphere of “nothing is ever done.”  When there is a lack of trust and respect among people, as is generally the case in our society, and since ownership and ego are often entangled with limited and rigid understand, we then find ourselves in situations in which the limited and rigid understanding of a few with arbitrary power and authority take precedence over the understanding of others.  In other words, people in authority are expected to solve every problem and people that do work are expected to be robots.  Both are set up by this arrangement to fail.

Indeed, there is a real problem in trying to talk about things that we do not do, or that we do not sincerely try to do.  True learning, on the other hand, consists in people striving to be truthful and sincere working together  engagement in a continuous cycle of action, reflection and consultation.  Learning also requires us to be truthful – if we think we have all the answers, learning becomes extremely difficult, if not impossible.  If we are not at least trying to learn to define what “done” is to us, we will never be able to actually talk about it in a knowledgeable and meaningful way.  Furthermore, it will likewise be impossible for us to help anyone else learn to understand their own Definition of Done if we haven’t learned through real experience about how to understand our own.

As we engage in a real learning process, through action, reflection and consultation, new patterns of thought begin to emerge and perhaps even crystallize.  These emerging new patterns help us to bring concepts out of the stratosphere of semantics, rhetoric and theory back down to earth where we can actually act and reflect on them in order to implement creative new solutions to the problems of our world.

In her Agile 2007 presentation The Role of Leadership in Software Development (http://www.infoq.com/presentations/poppendieck-agile-leadership), Mary Poppendieck offers powerful insights into the history of patterns of thought around leadership and the emergence of Agile thinking out of the wisdom of Lean Manufacturing.

As with all Agile methods, Scrum is a framework for learning in which new patterns of thought that began to crystallize in Lean Manufacturing practices have been adapted and applied to software development practices.  It then follows that the Definition of Done in Scrum is consistent with a specific Lean Manufacturing practice, namely Standard Work.

In his book Workplace Management, Taiichi Ohno, the father of Lean Manufacturing, defines Standard Work as such:

“There is something called standard work, but standards should be changed constantly.  Instead, if you think of the standard as the best you can do, it’s all over.  The standard work is only a baseline for doing further kaizen [change for the better].  It is kai-aku [change for the worse] if things get worse than now, and it is kaizen if things get better than now.  Standards are set arbitrarily by humans, so how can they not change?

“You should not create these away from the job.  See what is happening on the gemba [shop floor] and write it down.”

Based on the assertions of the previous two paragraphs, we must conclude that just as standards should be changed constantly in Standard Work, so too should definitions change constantly in the Definition of Done.

How, then, does our work benefit from a Definition of Done that is always changing?  This is a deceptively simple question, as it is an example of a problem posed by old patterns of thought that can only be solved by new patterns of thought.  In order for the old patterns of thought thinker to be helped to form new patterns of thought, he must be accompanied by the new patterns of thought thinker to develop the capability to adopt new patterns of thought.  In other words, in order to really learn, people need to be accompanied by those who have more experience.  Such an exercise is far beyond the scope of any article and requires a completely different venue – namely the coaching relationship.  More about capacity-building and accompaniment later.

For now, suffice it to say that the point of having a Definition of Done that is always changing is to allow for kaizen – the Definition of Done, therefore, like Standard Work, is only a baseline from which we constantly change for the better.  In other words, the Definition of Done is the record of what we are actually doing now. It allows us to be absolutely confident that we know as much as possilbe about what we are actual doing now so that we can make real, concrete, and confident decisions about actual improvements to our work.

Actually doing the Definition of Done, as Ohno tells us is simple:  “See what is happening on the gemba [shop floor] and write it down.”  For many of us though, this simplicity is deceptive in that it is actually often very difficult – both the seeing and the writing.

The ability to see what is actually going on is clearly vital to the capability of defining done.  It is valuable, therefore, to examine more closely the sense of sight:

We have physical eyes that see.  What do our eyes see?  Light.  Is this what Ohno is talking about when he says “see what’s going on” – literally seeing light – or is he talking about a different kind of sight?  Clearly, what he is talking about is what we might call true sight, or the ability to see the truth.  We can think of truth, therefore as being like light.

Is it our physical sight that sees the light of truth?  This, of course, is impossible since our physical eyes only see physical light.  So what is the sense in us that allows us to see the light of truth – in other words, what is true sight?   Some may say that it is our sense of justice.  One must have a strong, developed sense of justice in order perceive truth, especially in environments like software development in which the truth can be easily hidden.

Writing down the Definition of Done with accuracy and clarity requires us to be both truthful and precise.  This is very difficult to do well in our present environments of opacity, defined roles, command and control management, fear of failure and general distrust.

Clearly, we can see now that the Definition of Done, challenging to understand in its subtlety as a concept, is far more difficult to apply effectively in reality and therefore fully realize its value in practice.

The concept that allows for the value of the Definition of Done to be realized is the concept of expanding the Definition of Done.  Expanding the Definition of Done in Scrum and Agile is the equivalent of kaizen in Lean Manufacturing.  In order to expand the Definition of Done, the actual Definition of Done needs to be well understood.  In other words,  “Where there is no Standard there can be no Kaizen.”

Ohno says:

“When creating Standard Work, it will be difficult to establish a standard if you are trying to achieve ‘the best way.’  This is a big mistake.  Document exactly what you are doing now.  If you make it better than it is now, it is kaizen.  If not, and you establish the best possible way, the motivation for kaizen will be gone.”

This brings us back to the initial problem created by our old patterns of thought around our understanding of the Definition of Done – namely the misconception that at least some of the Definition of Done must be dictated by management in order to have consistency across teams working on the same large project.  The solution to this problem is challenging yet simple:  It’s irrelevant.  An organization is a living, breathing entity.  When management makes room for kaizen by not dictating standards, kaizen has more power to pollinate the entire organization and transform the way people think and work than imposed standards could ever begin to hope for.  Dictating standards, in other words, is limiting while kaizen harnesses the creativity of all.

Again, Ohno says:

“We need to use the words ‘you [the worker] made [the standard]’ as in ‘follow the decisions you made,’  When we say ‘they were made’ [for you] people feel like it was forced upon them.  When a decision is made, we need to ask who made the decision.  Since you also have the authority to decide, if you decide, you must at least follow your decision, and then this will not be forced upon you at all.

“But in the beginning, you must perform the Standard Work, and as you do, you should find things you don’t like, and you will think of one kaizen idea after another.  Then you should implement these ideas right away, and make this the new standard.”

Changing our patterns of thought requires creativity, but who’s creativity?

Ohno:

“Years ago, I made them hang the standard work documents on the shop floor.  After a year I said to a team leader, ‘The color of the paper has changed, which means you have been doing it the same way, so you have been a salary thief for the last year.’  I said ‘What do you come to work to do each day?  If you are observing every day you ought to be finding things you don’t like, and rewriting the standard immediately.  Even if the document hanging there is from last month, this is wrong.’

“At Toyota in the beginning we had the team leaders write down the dates on the standard work sheets when they hung them.  This gave me a good reason to scold the team leaders, saying ‘Have you been goofing off all month?’

“If it takes one or two months to create these documents, this is nonsense.”

People on the shop floor or the Scrum teams need to be given the freedom and authority to figure out how to do their work better and change the standards of their work as they learn.  Ohno was really first and foremost a master coach who knew how to accompany people to develop their capabilities to perceive truth and generate and apply their own knowledge and creative solutions to challenging problems.

Gary Hamel, in his article “Management Innovation” in the February 2006 edition of the Harvard Business Review, wrote:

“Only after American carmakers had exhausted every other explanation for Toyota’s success- an undervalued yen, a docile workforce, Japanese culture, superior automation- were they finally able to admit that Toyota’s real advantage was its ability to harness the intellect of ‘ordinary’ employees.”

In Scrum, the Team itself defines Done by what it actually gets done.  The ScrumMaster removes obstacles so that the Team can expand its Definition of Done (kaizen).  Scrum assumes that all Team members are dedicated to expanding the Team’s Definition of Done from Sprint to Sprint and that the Team will achieve this as long as organizational obstacles (such as managerial control fetish) are not impeding it from doing so.  When a Team is empowered in this way to expand its own Definition of Done (as well as empowered in other ways, according to the rules of Scrum), it will have the space it needs in order to grow into a hyper-productive Team.  That is to say that no one outside of the Team (i.e. management) dictates any part of the Team’s Definition of Done (a common management practice that results in kai-aku).  The Definition of Done is one ingredient in the remedy for curing our culture’s leadership disease – the failure to learn.

“…your failure is an internal disease…You firmly believe that sound management means executives on the one side and workers on the other, on the one side men who think and on the other side men who only work.”  -Konusuke Matsushita

(Shameless Plug: we offer excellent Certified ScrumMaster Training and in it we discuss the Definition of “Done” in the context of people’s actual problems.)

Share and Enjoy:
  • TwitThis
  • LinkedIn
  • Digg
  • Technorati
  • del.icio.us
  • Propeller
  • StumbleUpon
  • Reddit
  • Fark
  • Slashdot
  • Blogsvine
  • Google Bookmarks
  • Furl
  • Facebook
  • BlinkList
  • YahooMyWeb

Report average velocity and fail 50% of the time

Friday, January 23rd, 2009

The question of “expected velocity” and long-term planning has come up at more than one client. A recent client conversation got me thinking, however, questioning how to interpret velocity when estimating and plotting a roadmap based on a current backlog of features. Assume, for a moment, a backlog of story-pointed features, and 10 good iterations (consistent team, no odd occurrences that would affect velocity). Mathematically average velocity (well, a mean really) is a 50/50 proposition for any subsequent iteration. Some organizations don’t find this level of confidence acceptable. What velocity should be reported as expected for iteration/sprint planning and roadmap forecasting, and how should it be used?

Context

Interpreting velocity, before anything else, requires some context. An agile organization that sees estimates as hypothetical might find this article is of less use. In fact, a good question is whether estimation is even a value-added activity. For this post assume an organization that sees strong value in estimation and planning.

Culture

The biggest piece of context is to know the organizational culture. This is important in two respects, and both of these cultural factors are important because they impact how Velocity is understood within the organization.

What is Failure?

First is the meaning of failure in the organization. Is failure to deliver what was committed to by the planned date considered a failure of the team, or is it simply a fact to be understood and accounted for in future planning? Even in Agile organizations, the former is often true and a hard habit to break. If not delivering to expectations is considered failure and has negative consequences, then that means that estimation is being treated not as estimation, but as prediction and contract. Velocity is therefore a commitment, and should therefore be used conservatively.

Consistency or Speed?

The second item to know is whether consistency and predictability of delivery is of a higher strategic value than the actual rate of delivery. This is often un-stated. Usually people want fast and consistent delivery. The truth is that you can get consistent, or fast software development, or a balance between the two. Lack of trust is usually a strong motivation to encourage consistency over speed, or a history of quality problems, etc. In this case, as well, Velocity is more of a boundary than an indicator.

Emotional Loading in Estimation (or why not Low-ball?)

If estimation is seen as binding, contractual, or limiting, then additional emotions get overloaded. Trust, promise, and betrayal are words used in such organizational cultures. Distrust is usually a strong factor, especially between silos (business vs. technology, company vs. project management vs. customer, etc.). So when people are asked to give estimates, even using agile-friendly mechanisms such as story points, there is usually a process of cementing that estimate into a part of an accountability model, so estimates start to get conservative. People are then accused of low-balling, others are accused of irrational expectations… we’ve all seen this. The language clearly becomes one of contention and blame. Even the term low-balling is often an outright pejorative term for estimating too conservatively.

This doesn’t happen only in agile environments, and project managers in traditional PMBOK frameworks have long factored risk into “contingency budgets”. Interestingly, however, if a Project Manager were to factor risk into the task estimates, they’d be “low-balling capacity,” yet if they were to factor it out and layer it on top of the project work, it’s “contingency budgeting” (At least in a few experiences I’ve had). Either way, someone’s adding a factor for uncertainty, based on the need to predict conservatively or liberally or somewhere in between.

That’s the point of the article: how can Agile projects use velocity to estimate as conservatively (or liberally) as is appropriate?

An average is a 50% chance to succeed (or fail)

Velocity is not a constant. It’s a set of instantaneous values on a curve, with instances being iterations. That means that it varies, and is therefore only meaningful statistically. So how do you reasonably use velocity statistically, and improve confidence? One way is to stop delivering against “average” velocity.

A lot of coaches use average velocity over the previous N iterations. This is not helpful for all sorts of reasons, if estimation is a commitment. By definition, average (well, actually a mean, but they’re close) is a 50/50 proposition. If you report the average team velocity (assuming it’s accurate), then about half the time the team will be under and about half the time the team will be over, statistically. So basically an average is a crap shoot, when taken in any given instance. It’s can only be good in the long run. For this to work, the long-haul has to include permission to fail and a lot of trust. Teams need to be able to go miss dates but will sometimes exceed dates and it should all wash out in the end. In organizations such as I’m describing, that trust isn’t there, so. Additionally, if the language of commitment is around meeting instantaneous iteration commitments (as opposed to delivering high-quality customer value as quickly as is sustain-ably possible) then you aren’t playing the long-game, you’re playing a very short-game.

Simulate Velocity, not work

In a PMI training course I took when I was at Sun Microsystems, we were nicely informed that two point estimates of tasks are a perfect way to fail half the time, per the above logic. One point estimates are just idiotic. Three point estimates were better. We simulated with a monte-carlo algorithm and found a curve and a distribution, and then determined a confidence level yadda yadda. Well, we’re trying to avoid wasting a lot of time estimating up-front, but one way to start representing velocity properly is to do the same kind of statistical modelling done in traditional product management, only simulate velocity, not work items.

In this approach, you take the last N iterations (say 10). Determine the maximum velocity (optimistic) and the minimum velocity (pessimistic), and then the mode (the velocity value that seems to occur most frequently). Then you do monte-carlo simulation so you get a statistical pattern. Now, you actually can determine an answer based on confidence. If you want to be right with an 80% confidence, you pick a velocity where 80% of the simulated runs were successful. (Note – there are a paucity of excel templates to do this math automatically, and often they are for sale. It would be nice to have a few functions with arbitrary distributions based on min-max-mode to help this along.)

It’s not perfect, and it’s a potentially huge amount of administrative overhead. Elsewhere I’ve referenced blogs that entirely oppose any estimation at all, but if you are gong to, then working statistically with simulation is the only way to take small sample numbers meaningful.

Commitment Velocity: Low-Ball as a policy.

Another approach, one perhaps controversial, but taught by some Scrum trainers is to pick the lowest historical delivered velocity. This is a commitment-based approach, on the assumption that building trust around consistent delivery is critical to building sound relationships where product owners and teams can safely state their needs and get things done with a minimum of contractual behaviour. By taking the minimum, you force a low-ball capacity, which means you can have high-confidence of success after a few iterations. You have, likely, after a while, some spare time on your hands. Teams can then choose to pull more work in (without adjusting their commitment velocity), work on “technical debt”, improve their skills, etc. A team could raise their commitment velocity in certain inflection points in the project. A new team member is added that provides a necessary skill not previously available, and after a few iterations the team is consistently hitting a higher number, but this is a careful process to ensure that they are committing, and if they don’t make their new number, it goes down to what they got accomplished.

Indemnify teams’ learning

An arguably healthier option, if you have built enough trust, is to simply indemnify a team from failing to meet the estimate. Since you’re doing mathematics on actuals to generate an expected future number, everyone can acknowledge that past behaviour is no guarantee of future behaviour, and simply use it for capacity planning. In this case, estimation is actually estimation, not commitment or contract. The team is expected to be ahead sometimes, and behind sometimes. The upside of this is that a lot of extra time isn’t spent playing with fictional numbers. Teams are spending their efforts on delivery as quickly-yet-sustain-ably as they can, and the organization treats them as trusted professionals in this. The temptation to assume you can predict the future is seen as folly, and the estimates are used to guide overall direction, not to make outward customer commitments.

Don’t be mindless

There may be other approaches, I’m sure. The agile community is certainly not short of people who love this topic and can talk for hours on “proper” estimation. The point of this post is merely to point out some options, and ask you to look at your organizational culture, team culture, customer culture, the meaning of terms like commitment, failure, success, consistency, speed, etc. As you understand the culture, balance consistency vs. speed, trust, and other factors to choose a method of estimation that meets your goals. Don’t do estimation based on your own, internal cultural assumptions, as you may have developed or been taught techniques that are useful when and where they were taught, but may no longer be so. Or maybe they weren’t so useful then either. Regardless, this because estimation cuts at the heart of the dialogue between producer and consumer, and establishes parameters for that discussion, it’s critical that you think your choice through.

[Christian also blogs at http://www.geekinasuit.com/]

Share and Enjoy:
  • TwitThis
  • LinkedIn
  • Digg
  • Technorati
  • del.icio.us
  • Propeller
  • StumbleUpon
  • Reddit
  • Fark
  • Slashdot
  • Blogsvine
  • Google Bookmarks
  • Furl
  • Facebook
  • BlinkList
  • YahooMyWeb

The Importance of Questions

Tuesday, October 28th, 2008

I’m currently doing some coaching work with Regina, a new project manager working with a small team of web developers at a community development organization in Toronto.  We had our first session last week. Regina was having trouble getting started on a particular project and I shared with her some of the Agile methods of creating a prioritized Cycle Plan, breaking it down into small tasks, etc.

Regina seems to be finding Agile methods helpful in general, but there was a special kind of interaction that we had around removing an obstacle that was particularly interesting for me.  It had to do with an email she received from Peter, a developer working on one of the websites she’s managing. Regina shared a concern that she didn’t know some of the technical terms Peter was using.  So I had her read through the email and form questions around the points she wasn’t clear about – i.e., “what are buttons?” and I wrote them down as she was speaking.

I then suggested that she compose a reply email containing the same set of questions.  Regina’s eyes opened wide and she exclaimed, “Oh yeah – that’s so obvious!”  I went on to mention that another option would be to go and do some research on her own but that there were some valuable advantages in asking Peter directly, particularly in terms of team-building, that may not be as immediately apparent as asking the questions solely for the purpose of having them answered.  Here are a few:

First, it’s a way forRegina to remind Peter that she does not have a technical background and that he should not assume that she is familiar with web-lingo.  Second, it also reminds him that she is a different person from the last manager he was working with and subtly reinforces that it’s important that they get to know each other as two individual human beings and learn to work together effectively.  Third, and perhaps most importantly, it gives Peter an opportunity to help someone else on the team learn something new, and by doing so, contribute to the culture of learning on the team.  Fourth, and perhaps most obviously, it promotes open lines of clear communication on the team.

(Of course, if the team was colocated, which it is not, lack of communication would be much less of an obstacle!)

Asking questions in the interest of learning makes it visible to others that you don’t know everything.  For some people, this presents a dilemma.  What makes it a dilemma is that asking meaningful questions is something that many people aren’t able to do well.  The ability to ask meaningful questions is a learnable skill requiring the capabilities of truthfulness, humility and courage.  Such capabilities – let’s call them moral capabilities – can themselves be developed through conscious, focused effort.

Someone in the position of a newly hired manager, or a veteran manager with a new team, who lacks these capabilities may feel that it is important to present to a team a persona of all-knowingness.  But, of course, this is false and the truth of one’s degree of knowledge and capability, or lack thereof, soon becomes apparent anyway.  Clearly, this person needs to do some honest hard work to develop some humility, but truthfulness and courage are still often major factors.

Or maybe you’re the kind of person (like Regina) who just doesn’t want to bother anyone.  In this case, humility is not necessarily lacking, but truthfulness – and perhaps most of all courage – may need some attention.  Concepts around moral capabilities deserve much more elaboration, but for the sake of brevity, I’ll leave it at that.

To sum it up, if you are open and clear in the way you ask questions, people will tend to appreciate it and will trust you more in the end.  Moreover, it can have a transformative effect on the environment of the team.  When your team members realize that you are not afraid to ask questions and be truthful about your lack of knowledge in a certain area, it will encourage them to be more truthful about their own capabilities.  Not to mention that most people feel good when they are able to help others.  When your team members feel safe to ask for help and free to help each other, it is empowering for everyone.

Asking meaningful questions, therefore, is an essential aspect of learning together, and nothing is a more powerful contributor to the success of an organization than a team that learns as a team.

Share and Enjoy:
  • TwitThis
  • LinkedIn
  • Digg
  • Technorati
  • del.icio.us
  • Propeller
  • StumbleUpon
  • Reddit
  • Fark
  • Slashdot
  • Blogsvine
  • Google Bookmarks
  • Furl
  • Facebook
  • BlinkList
  • YahooMyWeb