Archive for the ‘Agile Case Studies’ Category

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

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 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

Two Cool Case Studies

Wednesday, December 24th, 2008

http://www.fastcompany.com/magazine/28/ge.html – GE Jet Engine Factory with self-organizing teams.

http://www.fastcompany.com/magazine/06/writestuff.html – super rigorous software development… the complete opposite of agile!

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

Scrum Case Studies

Thursday, November 6th, 2008

Great link from Mark Levison on agile / scrum case studies!!!

Here’s another one from this blog:

A Cautionary Tale.

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

Extremely Short Iterations – Agile 2008 Experience Report

Monday, October 6th, 2008

Infoq published the video recording of my talk at Agile 2008 titled “Extremely Short Iterations as a Catalyst for Effective Prioritization of Work“.

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

OpenAgile and Small Business Management

Wednesday, May 7th, 2008

For the past three months I have been working with Paul Heidema (our VP of Marketing) to use OpenAgile to run our business.  I thought it might be interesting for folks to see a screen capture of how we have arranged things in CardMeeting to do our planning and tracking. The yellow cards are labels for our Cycles, the white cards are Work Queue items, and the blue cards are Tasks related to the item.  The orange cards represent special information (eg. obstacles or ongoing work) and the green cards represent reflections and learning for each Cycle.

BCI OpenAgile CardMeeting

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

First Try with Agile in my Home

Monday, April 28th, 2008

I have been practicing Agile for the last few months for my job. With Mishkin we have been following many of the Agile rules as a small team. It has been very successful, and the learning is tremendous.

So, like Mishkin, I wondered if I could use the same practices at home. A few days ago I asked my wife, Laila, if we could try using cards, a work queue, and cycles. She thought it would be great idea to put all our tasks on post-its and not have to remember them.

Yesterday we made the work queue, did some estimation, and decided what we would commit to for our first cycle. We consulting and decided that one week cycles would make the most sense for our schedules.

Cycle 1

Right away I noticed a relaxation that came over Laila. I guess that it is very tough to maintain a work queue in your head day-in and day-out. I will continue to post my thoughts on our progress.

Cycle 1(Work Queue)

Has anybody else used agile practices outside of your work? How did it work? What did you learn? Maybe my wife and I can learn from you and avoid those challenges.

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

Agile Classroom Management

Friday, October 12th, 2007

I’m fascinated by the idea of applying agile methods outside of software… be it to business management, family and household, or, as I and my father have been exploring over the last two and a half years… agile classroom management. Here’s how I do it in my Agile Project Management / ScrumMaster Certification courses:

(more…)

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

Stuck? Try Extreme Obstacle Removal!

Wednesday, August 22nd, 2007

What happens when you are iterating away, your team is totally groking agile, delivering great results every couple of weeks, and then unexpectedly, suddenly and firmly everyone is stuck!? An obstacle has come along that forces a full stop. A barrier has been placed in the path. What do you do?

(more…)

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

A Cautionary Tale – Delaying Agile Adoption

Thursday, August 9th, 2007

What happens when you delay adopting agile? Well, one large client I have worked with has found out…

(more…)

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

Travel and Trust

Friday, March 2nd, 2007

I don’t usually talk too much about personal stories here – I try focus on agile methods pretty directly. However, the last two days have been interesting enough that I want to share them, and a lesson from the experience.

(more…)

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

Iteration 6 – Cleanup!

Monday, February 5th, 2007

Well. Last iteration was great! I didn’t document it, because it was trivial: I had one full day coaching engagement plus a two-day public course. And then the rest of the week I did nothing!!! What a joy! Anyway, now onto iteration 6 – cleaning up from the cancelled iteration and catching up from the vacation.

(more…)

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