Posts Tagged ‘Teams’

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.

More Agile Practices for Social Innovation, Non-Profits, Charities and Volunteer Organizations

Friday, April 23rd, 2010

I have started composing a series of articles on my blog A Changemaker in the Making that are intended to briefly explain how to apply different agile practices to the work of social innovators, non-profits, charities and volunteer organizations.

The first article covers Self-Organizing Teams an important consideration for organizations that want to use their people resources more efficiently and to create a culture of empowerment.

The second article explores The Agile Workspace and ways to create an environment that is conducive to fruitful interaction.

Enjoy!

Comparison of OpenAgile with Scrum

Monday, February 1st, 2010

OpenAgile is similar to Scrum in many respects. Both are systems for delivering value to stakeholders. Both are agile methods. Both are frameworks that deliberately avoid giving all the answers. So why would we choose OpenAgile over Scrum?

The most important difference is in applicability: Scrum is designed to help organizations optimize new software product development, whereas OpenAgile is designed to help anyone learn to deliver value effectively.

OpenAgile is an improvement over Scrum in the following ways:

  1. More effective teamwork and team practices, in particular the Consultative Method of Decision Making, and
    applicability over a larger range of team sizes from a single individual on up.

  2. Recognition of the individual capacities required for effective learning, namely Truthfulness, Detachment,
    Search, Love and Courage. Scrum acknowledges a separate set of qualities, but does not show how they systematically connect with the requirements of a Scrum environment.

  3. Systematic handling of more types of work beyond just “new artifacts” and “obstacles”. In particular, OpenAgile includes calendar items, repetitive items and quality items and acknowledges their unique qualities in a work
    environment. OpenAgile also provides a framework to include additional types of work beyond these five.

  4. Improved role definitions based on extensive experience.

    1. There is only one role defined in OpenAgile (Team Member) vs. three defined in Scrum (Team Member, ScrumMaster, Product Owner).

    2. There are multiple paths of service that allow Team Members and Stakeholders to engage with an OpenAgile team or community in different ways. There are five paths of service: Process Facilitation, Growth Facilitation, Tutoring, Mentoring, and Catalyst.

    3. The Process Facilitator path of service is similar to the ScrumMaster role with the following major differences:

      • is not responsible for team development
      • is not necessarily a single person, nor is it a required role
    4. The Growth Facilitator path of service is similar to the Product Owner role with the following major differences:

      • is responsible for all aspects of growth including value (like the Product Owner), and individual and team capacity building.
      • is not necessarily a single person, nor is it a required role
  5. Integration of principles and practices from other methods. Two examples suffice:

    1. From Crystal: creating a safe work/learning environment.

    2. From Lean: build quality in, value stream mapping, root cause analysis, standard work.

  6. OpenAgile allows interruptions during the Cycle. Scrum has the concept of Sprint Safety. This makes Scrum
    unsuitable for operational work and general management.

  7. The distinction between Commitment Velocity and other uses of the term “velocity” used in Scrum. Commitment Velocity is the historical minimum slope of a team’s Cycle burndown charts and determines how much work a team plans in its Engagement Meeting.

  8. Flexibility in the length a Cycle. Scrum requires that Sprints (Cycles) be one month in duration or less.
    OpenAgile allows a Cycle to be longer than that and instead provides a guideline that there should be a minimum number of Cycles planned in the time expected to reach the overall goal.

  9. The Progress Meeting in OpenAgile does not require people to take turns or directly answer specific questions.

  10. Avoiding conflict-oriented models of staff and management (Chickens and Pigs in Scrum).

  11. Terminology changes to be more clear in meaning and applicable beyond software. A comparative glossary is
    included below.

Another major difference between OpenAgile and Scrum is how the community operates. OpenAgile is an open-source
method that has a specific structure for community involvement that allows for continuous improvement of the system. Scrum is closed. It is closely managed by it’s founders and this has led to challenges with the method becoming dogmatic. OpenAgile is meant to constantly evolve and grow.

Comparative Glossary between OpenAgile and Scrum

OpenAgile Scrum
Cycle Sprint
Cycle Planning Sprint Planning and Sprint Review
Team Member Team Member or “Pigs”
Process Facilitator ScrumMaster
Growth Facilitator Product Owner
Work Queue Product Backlog
Work Queue Item Product Backlog Item
Cycle Plan Sprint Backlog
Task Task
Work Period Day
Progress Meeting Daily Scrum
Learning Circle w/ steps Inspect and Adapt”
Delivered Value Potentially Shippable Software
Stakeholders Chickens”
Five Types of Work:

New, Repetitive, Obstacles, Calendar,
Quality

- no equivalents -

User Stories, N/A, Impediments, N/A, N/A

Consultative Decision Making - no equivalents -
Sector / Community - no equivalents -

References on OpenAgile:

http://www.openagile.com/

http://wiki.openagile.org/

References on Scrum:

http://www.scrumalliance.org/

http://www.scrum.org/

“Agile Software Development with Scrum” - Schwaber and Beedle

“Agile Project Management with Scrum” - Schwaber

“Scrum and the Enterprise” – Schwaber

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?

Scrum Gathering – Orlando Florida – Mike Cohn – Leading Self-Organizing Teams

Monday, March 16th, 2009

Something wrong with starting late at a Scrum Gathering!

Did this talk before at SD conference at Santa Clara

Think self-organizing teams are fundamental to all agile methods
- people claim: Unified Process is an agile process – but doesn’t rely on self-organizing teams
- Wicked problems: get the right people together, throw them at the problem

TOPICS:

Self Organization and subtle Control – not all forms of control are evil

Containers, Differences and Exchanges Model

Influencing how the team evolves

Premise: self-organization isn’t just locking a team in a room and saying “just do it” – we influence

What is a Self Organizing Team?
- does not mean:
- – the team gets to decide what goal they pursue
- – or even necessarily who is on the team
- – - some self-org teams are given this responsibility

Complex Adaptive Systems
- a dynamic network of many agents
- – acting in parallel
- – acting and reacting to what other agents are doing
- control is highly dispersed and decentralized
- overall system behavior is the result of a huge number of decisions made constantly by many agents
- e.g. QA group
- in a project:
- – sounds like a software project!

Some Examples
- ant colony
- flock of geese
- us right now – self-organized into room, some at front, some near power outlets
- a crowd batched up to get into a concert or sporting event
- – Jimmy Buffet concert – queueing, at the bar, at the beach etc.
- a family preparing, eating, and cleaning up after a meal
- cars and drivers on the heighway
- a software team

Control is not Evil
- was command and control leader before scrum!
- Simple rules or incentives are used to guide or direct behavior
- – “Drive this direction and on this side on the highway.”
- for bioteams, these are provided by nature
- for our teams rules and incentives can be added by managers or leaders… or in some cases by team members
- Generative rules – rules that generate behavior
- Some control is okay

Quote from Philip Anderson, The Biology of Business about Self-organization

Popular to criticize Taylorism – don’t specify exact steps, instead put in place things that guide behavior

(NOTE: slides on website)

Takeuchi & Nonaka “Although project teams are largely on their own, they are not uncontrolled… ”

What this is not
- we’re not talking about
- – being deceptive or sneaky
- – manipulating people
- – IS subtle rules and guidelines
- nothing I’m going to advocate needs to be secret
- – but there may be reasons why you don’t broadcast your reasons
- – e.g. if you have to fire someone

Containers Differences and Exchanges

Glenda Eoyang: Conditions for Self-Organizing in Human Systems
- Container
- – a boundary within which self-organization occurs e.g. project, team, role, nationality
- Differences
- – there must be differences among the agents acting in our system
- – e.g. technical knowledge, domain knowledge, education, experience, power, gender
- – e.g. individual sub-goals
- Transforming Exchanges
- – agents in the system interact and exchange resources
- – information, money, energy (vision)
- how can we use these to influence the way the team behaves?
- – amplify or dampen the differences
- – re-frame the problem
- – change the communication environment

Comment from audience about “Wisdom of Crowds”
- groupthink!

Using the CDE model
- Adjusting the Containers:
- – formal teams, informal teams, clarify (or not) expectations
- – e.g. the AI programmers thought they could not talk with each other, only the people on their teams
- – introduced a Community of Practices
- Differences:
- – dampen or amplify them within or between containers
- – e.g. if people are having a hard time making decisions because they are all too different, maybe adding people to increase similarity
- Exchanges:
- – insert new exchanges, new people, new techniques or tools
- – e.g. team that needed to get outside help re: architecture
- – cross-training

Containers
- enlarge or shrink team

Differences
- don’t require consensus
- – creativity comes from tension
- – quiet disagreement is not as good as fierce debate that leads to behavior change
- _do_ require consensus
- – e.g. if one person is dominating the discussion
- ask hard questions
- – then expect teams to find solutions

Transforming Exchanges:
- remove a document
- create a document!
- encourage communication between teams and groups
- – who isn’t talking
- add or remove people
- – change reporting relationships
- encourage learning

Exercise:

You are the ScrumMaster or PM:
- situations
- ID one thing to change
- use CDE model

Good Group Discussion around Scenarios

Mike Cohn is really good at creating discussion exercises.  I’ve always been impressed.  The discussion excercise asked us to apply the CDE model to the various scenarios.  In our group we only looked at two out of the five scenarios.  Each time the discussion was great – lots of good ideas from people about how to solve the problem in the scenario.  What wasn’t so good at first was using the CDE model.  It’s easy to just look at the scenario and come up with solutions.  What isn’t so easy is to use the model to generate solutions or to map solutions into the model.  At a personal level, I also found that folks in my group were emphasizing imposing solutions rather than using the Scrum model to have solutions emerge from the team’s own efforts.  For example, the retrospective is a Scrum practice that really should be the first line of defense.

Aother Philip Anderson quote:

“Self-organization proceeds from the premise that effective organization is evolved, not designed.  It aims to create an environment in which successful divisions of labour…”

Variation, selection and retention
- evolution is result of these three elements
- consider a giraffe:
- – variation: longer neck
- – selection: helps it reach food
- – retention: more food means more progeny

Seven levers for influencing team evolution:
1.  Select the external environment
- more than the physical environment
- business, industry
- approach to innovation
- approach to mistakes
- types of projects
- expectations about multi-tasking and focus
2. Define performance
- selection – traits that help us survive
- short vs. long-term performance
- providing training
- support sustainable pace
- explore wild ideas
- not exchanging deadlines for unmaintainable code
- e.g “Up or Out” culture – burn out or be promoted!
3. Manage meaning
- stories from leaders
- keeping messages out
- “we will become profitable this quarter”
- rituals
- Story about Mike’s background (1994)
- – valley of death
- – product did not have a long life
- – no new features
- – decided to create new product
- – “valley” in decline of revenue from old product, vs. increase in revenue for new product
- – as part of this, replaced two-ply with one-ply toilet paper to remind everyone of the need to save costs!
- Another story
- – “our GM counts the cars in the lot every day at 5pm” – not a good culture for Scrum!

4) Choose People
- who is on the team
- adjust:
- – team size, decision making style, location, gender, background, motivation

5) Self-selecting members?
- should a delivery team be allowed full control over who is on the team?
- under all circumstances or only some?  which?
- what are the advantages and disadvantages?
- – people often will choose to work with similar people
- doing this is giving up some control
- “you can self-organize unless I disagree” is not a good message!
6) Evolve vicarious selection systems
- variation-selection-retention
- – selection was determining which variations will be retained – can take a long time
- so we often use vicarious selection systems
- – this is an animal that can smell that a food is poisonous, rather than eating it
- using only the marketplace as our selection mechanism takes too long
- Organizations can have vicarious selection systems:
- – retrospectives, Google’s 20% policy which attracts people to projects, compensation
7) Energize the system
- unless energy is pumped into the system, entropy will set in
- make sure the group has a “clear, elevating goal” or an “igniting purpose”
- motivation
- opportunity
- information
- Teamwork by Larson and LaFasco or Hot Spots by Lynda Gratton
- example: Bill Gates and “Internet Tidal Wave” memo

New book by Mike Cohn:

“Succeeding With Agile”

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.

Crystal Clear – A Book on Small Teams

Friday, July 4th, 2008

I have just started reading Crystal Clear: A Human-Powered Methodology for Small Teams by Alistair Cockburn. I was not too sure what this book would provide for me in the way of relevant learning.

I am intrigued that this work came out of years of experience by Alistair. This quote from the book “Crystal Clear does not aspire to be a “best” methodology; it aspires to be “sufficient,” in order that your team will shape it to itself and then actually use it.” gave me hope. I work on a small team and I wonder about which practices will best suit our situation. I also wonder how our team can use tools and processes then reflect on their usefulness to decide if we will continue their implementation.

I am interested in reading the whole book, but a little concerned that there will be too much techno-words used throughout. I have a background in business, marketing, and the web but not to the degree of the some of the other books that I have read.

What learning have you gained from working on small teams? Have any of you read this book? If so, did you gain any insights that would help my team to develop?

Agile Benefits: Satisfied Stakeholders

Monday, September 17th, 2007

So far, we’ve discussed learning and value as benefits of agile. Now we turn to a more human side: satisfied stakeholders. Agile methods provide multiple roads to satisfaction for customers, users, business people, bureaucrats (okay, maybe not _all_ bureaucrats), team members, managers, shareholders, and interested passer-by. There are three primary mechanisms by which this occurs: engagement, trust-building and feedback-control. [UPDATED: added link to explanation of Commitment Velocity]

(more…)

Four Methods for Dealing with Interruptions

Sunday, April 15th, 2007

Recently I’ve talked with a number of people who have a simple question: what do we do with teams that are constantly interrupted by urgent support requests for their time?

(more…)

Continuity of Teams on Agile Projects

Tuesday, January 9th, 2007

Dave Nicolette posted a really interesting and insightful comment about the recent discussions on team commitment, flexibility and rigidity in agile methods. The focus of Dave’s article is on the idea of having an established and continuously available team that grows in its abilities. The more you interrupt the team with individual or one-off tasks, the longer it takes to move through the stages of team development. Thanks Dave for the good post.

8 Team Room Tips

Wednesday, December 13th, 2006

Here are eight tips for making a great team room.

(more…)

How to Avoid Context Switching

Friday, November 24th, 2006

Given the huge interest in the article by Dmitri Zimine about context switching, and despite a couple of good articles about how to determine iteration length, there has been no empirical method described, only reasoning processes. This article describes a simple method to quickly determine iteration length by experimental means.

(more…)

The Case for Context Switching

Wednesday, November 15th, 2006

Recently, Dimitri Zimine wrote an excellent little story about context switching. Joel Spolsky writes in “From the ‘You Call this Agile’ Department“:

Dmitri is only looking at one side of the cost/benefit equation. He’s laid out a very convincing argument why Sarah should not interrupt her carefully planned two week iteration, but he hasn’t even mentioned arguments for the other side: the important sale that will be lost.

Okay… I’ll bite.

(more…)

Process Facilitator “Smells”

Tuesday, November 14th, 2006

I have now trained over one hundred people in my Agile Project Managmenet / ScrumMaster Certification course. I’m starting to see and hear some of the results of this training. There are a couple specific “smells” that I have become aware of.

(more…)

Offshore/Distributed Agile: Challenges, Productivity and Tools

Monday, September 18th, 2006

On the agile-usability Yahoo! group, someone asked about tools to mitigate the consequences of having an off-shore team doing some of the work. I have strong feelings about this.

(more…)