Archive for the ‘How-To Apply Agile’ 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

The Road from Project Manager to Agile Coach

Wednesday, May 12th, 2010

This is an excellent series of videos by Lyssa Adkins:

Part One of Two: http://www.youtube.com/watch?v=TvYqhYEaqMs

Part Two of Two: http://www.youtube.com/watch?v=L9tSjpqeBa4

I highly recommend taking the twenty minutes to watch these two videos.  Anyone who is a ScrumMaster, a Project Manager or an Agile Coach should take the time!

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

New Certified Scrum Product Owner training in Toronto added to calendar

Wednesday, November 4th, 2009

Due to popular demand, we have added another Certified Scrum Product Owner (CSPO) training to our listing of courses.  There is an overwhelming need for well trained Product Owners, and we’re happy to take up the challenge. The next CSPO will happen on January 14 & 15 at our office in Newmarket, just north of Toronto.

During this seminar, our Certified Scrum Trainer will teach participants 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 the agile environment

With a maximum class size of five people, this seminar is designed to allow participants to dig deep into the role of the Certified Scrum Product Owner. After completing this course, attendees of this seminar will be able to create and manage a Product Backlog, work with a Scrum Team to create high-quality software, and use the Scrum framework to build and deliver the right software.  Please refer to our website for a course description and to reserve space for yourself or others on your team. http://www.berteigconsulting.com/CSPOCourseDescription

We look forward to adding value to your team!

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

Seven Essential Teamwork Skills

Monday, October 12th, 2009

I’ve been researching teamwork lately.  I just finished reading “The Discipline of Teams” by Katzenbach and Smith which is an HBR summary of their much more substantial book “The Wisdom of Teams”.  I decided that it would be good to be able to describe the essential skills an individual needs to acquire in order to work effectively in a team.  First stop, Google and a search of “list of teamwork skills”.

Strangely, not much turned up on the first page.  The best result is found at “7 Essential Skills for Teamwork” which is a page on a public elementary school web site.  So, here’s my adaptation of their list:

Active Listening

Active listening is a skill that allows a person to completely focus on the communication of another person including both verbal and non-verbal aspects.  Active listening requires the ability to not think of your own responses until after a person has finished speaking.  One simple way of doing this is to echo what a person is saying in your silent internal voice.  When someone says “I think we should build a new gimbal on the widget”, you are saying exactly the same thing in your own mind.  Active listening also requires that you request clarification, often by rephrasing what a person has said and asking if you have understood correctly.

Questioning

Being able to frame and express questions effectively helps us understand and integrate knowledge into our own mental model of the world, or even to modify our mental model.  Asking questions is easy.  Asking good questions is much harder.  We need to use an appropriate set of words and tone of voice so that we do not alienate or offend the recipient of the question.  For example, asking “why did you do that?” will often put people on the defensive since they will assume that you mean you disagree with their actions.  Instead, saying “I do not understand the reason you did that.  Could you please explain it to me?” can be a much more gentle way of getting to the same information.

Logical Argument

When presenting an idea or position, being able to logically support it is important to exploring the truth of it.  This includes being able to share your assumptions or axioms, the data you are basing your argument upon, and the logical sequence of reasoning to reach your conclusion.  Being able to avoid fallacious logical methods is also important.

Respecting

Showing respect includes acknowledging the fundamental human value of the existence of your teammates, and being able to step back from your own understanding of the world to acknowledge the legitimate nature of the perspective that other people have.  This does not mean that you have to let teammates get away with inappropriate behavior.  In fact, respect for your teammates will allow you to support them in behaving in ways that are in alignment with their fundamental nobility as human beings.

Helping

Offering help and actually following through with real assistance are aspects of helping.  When you suspect that a team member is struggling with something, you offer to help both verbally and with your actions.  This can take the form of offering information, offering emotional support, offering to assist with problem-solving, or actually taking action to do an activity together.  When we help someone, we share their burden.

Sharing

Sharing our knowledge, time, skills or physical resources are all aspects of sharing.  Sharing among team members is focused on those things which will help a team reach its goals.  This is similar to helping except that it tends to be more of a transaction than an ongoing activity.  The transaction is that you give a gift and then the other person uses that gift to meet their needs.  Sharing does not require reciprocity.  If you share something with another person, you should not expect that that person will return the gift at any time in the future.

Participating

It’s probably obvious, but in order to effectively be on a team, you need to participate!  Participation itself is mostly obvious: do work with the other team members.  However, there are also some less obvious aspects of it.  You are not participating when the team is having a discussion, you find it boring, so you check your email.  You are not participating when the team makes a decision and you abstain from helping to execute the decision because you disagree.  You are not participating in a work team when you are mentally checked out because of a crisis at home.

All of these skills are critical teamwork skills… but there may be others.  Do you think there are other skills missing from this list that are critical for effective teamwork?

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

Scrum Study Guide updated with tools for new ScrumMasters

Wednesday, June 10th, 2009

We’ve updated the Scrum Study Guide and lowered the price!  The Scrum Study Guide is an editable tool for helping ScrumMasters do their jobs.  It is like a personal assistant that helps you:

  • Keep track of the rules of Scrum
  • Find tons of concise how-to guides for common steps and activities in doing Scrum
  • Keep structured notes or a journal on your job as the ScrumMaster
  • Maintain a list of online reference material
  • Assess the progress of your team
  • Organize the obstacles you are working on
  • Modify and update the Scrum reference material based on how you are actually doing Scrum
  • Look up answers to the problems you’re having with your organization
  • Plus, every time we update content, pictures, tools, and best practices, you get the updates for free for the rest of your life!

    www.scrumstudyguide.com

    Are you one of the many satisfied Scrum Study Guide customers?  Tell us how it is working for you.

    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

    Using Agile to Run a Small Business – Five Types of Work

    Thursday, May 14th, 2009

    At Berteig Consulting, we used Scrum to run our business for quite a while – about one year.  Over that time we struggled with a few different concepts and practices.  As a Certified Scrum Trainer, I am very aware that Scrum requires us to use the framework itself to expose obstacles, rather than modifying Scrum to accommodate obstacles.  However, over the course of that year, it became more and more obvious that there is something fundamentally different between writing software products (where Scrum is fantastic) and running a business.  Scrum, the framework, just wasn’t good enough.

    The main problem we had was with the types of work we encounter in running a business.  We noticed patterns in the types of tasks we had every Cycle (Sprint).  In this article I will look carefully at two of those types of work and then briefly describe the other three types of work.

    We discovered that calendar items such as meetings, scheduled public events, and even personal appointments didn’t fit anywhere in Scrum’s Product Backlog or Sprint Backlog.  At first, we tried to think of this as an obstacle and force-fit these into the Product Backlog.  That didn’t work because that meant we couldn’t always prioritize by value.  Even if the Product Backlog had something more valuable in it than the scheduled meeting, we sometimes couldn’t change the dates of the meeting to accomodate the more valuable work.  So Calendar Items became a new category of work in addition to the new “features” that were in the Product Backlog.  (I say “features” in quotes because we were running a business not writing software.)

    We also noticed that we were struggling with applying the concept of the Definition of Done.  This led us to explore the concept of Repetitive Work.  For example, we need to clean our office on a regular basis – vacuum, water plants, take out trash, etc.  If we left that until it became more valuable than anything else on our Product Backlog we would have ended up with a disgusting work environment.  So we thought that this should be part of our Definition of Done.  The problem then became a more conceptual one: what were we doing that needed cleaning so that it would be considered done?  Well of course, it’s simply part of business operations.  Cleaning is not independently valuable.  We did decide that it was most cost-effective to outsource it, but it didn’t match the concept of Definition of Done as applied to the work in the Product Backlog.  That led to an insight: actually, we were looking at a new category of work: Repetitive Items.  These are those activities that we need to do to sustain our business and which should become habits, or which should be automated or outsourced.

    After identifying Calendar Items and Repetitive Items as types of work, we decided that we needed to look at the Product Backlog more carefully.  We decided that we needed to separate features, or as we called it “New Work”, from defects or Quality Items.  We also formalized the concept of a queue of Obstacles, which is mentioned in Scrum, but about which is given very little guidance.

    So after over a three years of trying to use agile methods to run our business, we have finally come up with a stable and seemingly sufficient set of types of work:

    • Calendar Items
    • Repetitive Items
    • Quality Items
    • Obstacles
    • New Work

    We have written more about our experiences and their results in our e-book: The OpenAgile Primer.  If you are trying to use agile methods to run a business or any other kind of organization, please check it out and let us know about your experiences.  We hope that OpenAgile will become an Open-Source method that we can contribute back to the world of work and life.

    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

    Agile Successes and “Failures”

    Wednesday, February 18th, 2009

    Here are the results from a bit of web research that I just did for a client:

    Successes:

    Capital One:

    Agile 2007 Conference Presentation – “The Growth of an Agile Coach Community at a Fortune 200 Company”

    *Mishkin Berteig (http://www.berteigconsulting.com/MishkinBerteig) worked with co-author Kara Silva on a large-scale Agile implementation

    2005 Information Week article

    Salesforce.com:

    Agile 2007 Conference Presentation

    “Failures“:

    It’s generally really hard to get people to talk openly about failure.  I assert that Agile itself never fails, rather organizations fail to implement Agile.  But that’s for another article. Here are some anonymous stories:

    http://www.agileadvice.com/2007/08/09/agile-case-studies/a-cautionary-tale-delaying-agile-adoption/

    http://www.cio.com/article/442264/Cargo_Cult_Methodology_How_Agile_Can_Go_Terribly_Terribly_Wrong

    This one includes successes and failures in China:

    http://www.infoq.com/articles/Agile-adoption-study-china

    Another interesting article about the concept of failure:

    http://blogs.zdnet.com/projectfailures/?p=494

    So cheeky, so true:

    “How to Fail with Agile” by Clinton Keith & Mike Cohn

    Interviews on adopting Agile:

    http://www.infoq.com/bycategory/contentbycategory.action?idx=2&ct=2&alias=adopting-agile

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

    Agile Guidance Engineering – Applying Agile to Writing Projects

    Sunday, February 8th, 2009

    Thanks to Christian Gruber of Geek in a Suite for pointing me to this fascinating use of agile on writing projects: Agile Guidance Engineering.

    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

    Lateral Violence and Workplace Safety – Awareness for Agile Teams and Coaches

    Monday, January 26th, 2009

    Two very interesting videos.  The first, a presentation by Rod Jeffries, goes through a treatment of “Lateral Violence”.  The second is three role-play scenarios to demonstrate the concepts.  Both of these videos are in the context of nursing in hospitals… however, it takes little imagination to see how they apply in other environments.  I would actually assert that the problems described in these videos are endemic to most organizations.

    Alistair Cockburn has also written about safety in a team context.

    Scrum and other agile methods all have some mechanisms for dealing with this sort of challenge, but they can start failing quickly if the sponsors of the agile effort do not overcome the habitual and cultural challengs.

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