Category Archives: Reference Information

The Rules of Scrum: Every Sprint includes Sprint Planning

Posted on by
Reply

The Sprint Planning meeting is the start of the Sprint and is the opportunity for the Scrum Team to discuss what they will build during the Sprint and how they will build it.  The focus of the meeting is on choosing Product Backlog Items (the goal for the Sprint) and then breaking those Backlog Items down into a detailed list of tasks (the Sprint Backlog).  In Sprint Planning, choosing who will do the work is strongly discouraged.  The value of Sprint Planning comes at three levels: first, setting a concrete goal helps with team cohesion and enables high-performance teamwork, second, the planning work helps set expectations with stakeholders and develop a team’s understanding of its own capacity, and third, the time set aside for planning gives the team a chance to think systematically about how to respond to feedback from the previous Sprint.

The Rules of Scrum: The Intention of Every Sprint is “Potentially Shippable” Software

Posted on by
Reply

The phrase “potentially shippable” has a very simple meaning: the features built in a Sprint and all the related activities are done to such a degree that ONLY business considerations are involved in the decision to ship or to not ship at the end of the Sprint.  Every Sprint should start with the intention of getting a small set of features to this ideal state.  Of course, teams make mistakes and have obstacles to doing their work to this level of doneness.  The intention to make potentially shippable software is designed to help teams see and expose obstacles to actually shipping.  These can be technical obstacles, dependencies, or bureaucratic obstacles.  Failing to have this intention removes this beneficial pressure from the team.  This lack of pressure can in turn lead to acceptance of “the way things are” and a team that never reaches a high-performance state.

The Rules of Scrum: There are no Breaks Between Sprints

Posted on by
Reply

Each Sprint that a Scrum Team does is an opportunity for learning through “inspect and adapt”.  If there is a break or a pause between Sprints, the Scrum Team may forget what it has learned or fail to apply that learning in a timely manner in the next Sprint.  Of course, many Scrum Teams end a Sprint before a weekend and start their next Sprint at the beginning of the next week.  This non-working break is normal and acceptable.  However, a break between Sprints during which some or all Scrum Team Members do other work is not acceptable.

The Rules of Scrum: Every Sprint is the Same Length

Posted on by
Reply

The Sprint is the fundamental unit of work when using Scrum.  Any product development effort using Scrum is, therefore, divided into Sprints.  Sprints are fixed in length so that the team has a predictable amount of time available to them to do work, which in turn assists in both short and long-term planning.  By making every Sprint the same length, the Scrum Team learns its own capacity for work.  If the Sprint length changes, the rhythm of Scrum is broken and a team will have to re-learn its capacity which usually takes at least a few Sprints.  If Sprints are rarely the same length, then the Scrum Team will struggle to do any reliable planning.

The Planning Game – An Estimation Method for Agile Teams

Posted on by
4

Purpose: estimate the effort for User Stories (Product Backlog Items, Value Drivers)

Prerequisites: all items have a value estimate, each item is written on a separate note card, full team membership is known and available for planning, each team member has a set of planning game cards

Process:

  1. The team goes through all the items and chooses the one which has the lowest effort. Write the number “2″ on this card (usually in the bottom right corner).
  2. The team looks at the item with the highest value.
  3. Each team member thinks about how much effort the team will expend to fully complete all the work for the item. Comparing this work to the work effort for the smallest item, each team member selects a card that represents this relative effort. For example, if you think that it requires ten times the effort, you would select the “20″ card. It is not permissible to select two cards.
  4. Each team member places their selected card, face down, on the table. Once all team members have done this, turn the cards over.
  5. If all team members show the same value, then write the value on the item and go back to step three for the next item. (Or if there are no more items, then the process is complete.)
  6. The person with the highest and the lowest value cards both briefly explain why they voted the way they did. If there is a Product Owner present, this person can add any clarifications about the item.
  7. For any given item, if a person is highest or lowest more than once, then each explanation must include new information or reasoning.
  8. Once explanations are complete, the team members collect their cards and go back to step three.

Notes:
- it is extremely important that the voting for an item continues until all team members unanimously vote the same way (this way team members and outside stakeholders cannot blame any individual for “wrong” estimates)
- in Scrum, it is normal for the Product Owner to be present during this process, but not to participate in the voting
- in OpenAgile, it is acceptable for people serving as Growth Facilitators for a team to participate in the voting
- voting should not include extensive discussion
- if more than one person has the lowest or highest vote, usually just one person shares their reason in order to help the process move quickly
- the first few items will often take 10 or 15 rounds of voting before the team arrives at a unanimous vote
- later on, items may take just one or two rounds of voting to arrive at a unanimous decision
- some teams, where trust levels are high, will discard with the use of physical cards and just briefly discuss votes

The planning game is used at the start of a project with the full list of user stories. In this case, it is reasonable to expect the team to average two minutes per user story, and an appropriate amount of time needs to be set aside to accommodate going through the whole list.

The Planning Game is also used any time that there is a change in the list of user stories: re-ordering, adding or removing user stories, or changes to a single user story. When such a change happens, the team can re-estimate any user story in the whole list. When starting a Cycle or Sprint or Iteration, all the user stories in the list should have up-to-date estimates so that estimation work is avoided in the Cycle planning meeting.

Finally, the team can decide to re-estimate any user stories at any time for any reason. However, it is important for team members to remember that estimation is non-value-added work and the time spent on it should be minimized.

The Skills Matrix and Performance Evaluation on Agile Teams

Posted on by
7

For a few years now I have been working with managers and executives to help them do Agile-compatible performance evaluations of their staff.  The method that has been most successful is based on a tool that comes from the book Toyota Talent called the “Skills Matrix”.  The basic approach follows these steps:

  1. Baseline the skills within a team for each team member.
  2. Set development goals and action items.
  3. Regularly review performance in relation to the development goals.

Of course, the details matter.  The OpenAgile Center for Learning has published a brief overview of how to use the Skills Matrix and a convenient A0-size pdf that can be used as a template for a team’s Skills Matrix.  I highly recommend using these to get started.  If you are a manager, ask your ScrumMaster or Process Facilitator to arrange and facilitate a team workshop to do the initial population of the Skills Matrix, rather than doing it yourself.  Once that is done you have a baseline and you should take regular digital photos of the team’s Skills Matrix for record-keeping and as a backup in case of disputes.  You should also let the team know that you will be basing performance reviews on how they improve their skills.

The development goals that team members set then should be made such that every team member understands that they have a responsibility to diversify their own skill set and assist other team members in doing this.  As a manager, you should review each team members’ goals for development and provide mentoring support when needed.  At the end of a fixed period of time (quarterly is a reasonable period), you will review each team member’s development relative to the baseline and the goals set.  Of course, normal guidance around performance (or lack thereof) can be given at these regular reviews.

I strongly recommend reading “Drive” by Daniel Pink as an important adjunct to understanding how to do performance reviews for individuals in an Agile environment.  In particular, individual performance reviews should not be tied to bonuses.  If bonuses are used at all, they should be measured and delivered purely at the team level or organization level without measuring individual contribution.

All of Scrum Diagram in One Page – a Cheat Sheet

Posted on by
1

I’ve been giving out a cheat sheet on Scrum in my training classes for the last 6 years.  It has evolved a great deal and I thought it would be timely to share it.

All of Scrum Diagram – PDF

All of Scrum Diagram – OpenDocument Graphics

I also have a guidelines/rules-of-thumb list:

Scrum Rules of Thumb – PDF

And some pitfalls listed out:

General Scrum Pitfalls – PDF

Scrum Product Owner Pitfalls – PDF

24 Common Scrum Pitfalls Summarized

Posted on by
14

Scrum is the most popular agile method… if you count all of the teams doing “Scrum Butt”.  Doing Scrum really well is much harder and much rarer.  Here is a list of 24 common pitfalls or bad behaviours of Scrum teams:

  1. Excessive Preparation/Planning: Regular big up-front planning is not necessary with Scrum.  Instead, a team can just get started and use constant feedback in the Sprint Review to adjust it’s plans.  Even the Product Backlog can be created after the first Sprint has started.
  2. Focus On Tools: Many organizations try to find an electronic tool to help them manage the Scrum Process… before they even know how to do Scrum well!  Use manual and paper-based tracking for early Scrum use since it is easiest to get started.  Finding a tool is usually just an obstacle to getting started.  (And besides, check out what the Agile Manifesto says about tools.)
  3. Problem-Solving in the Daily Scrum: The Daily Scrum should not be used to find solutions to problems (obstacles, impediments) raised.  Instead, keep the meeting very short and have those problem-solving conversations afterwards with only those who are interested.  The ScrumMaster facilitates this meeting to keep it on track.
  4. Assigning Tasks: Even though the concept of self-organizing teams has been around for a long time, still some people think that a project manager or team lead should assign tasks to team members.  It is better to wait for someone to step up than to “take over” and assign a task.
  5. Failed Sprint Restart: Although cancelling a Sprint is rare, it can be tempting to try and wait until everything is “perfect” or “ready” before re-starting.  Teams should immediately re-start after cancelling a Sprint.
  6. ScrumMaster As Contributor: The ScrumMaster is like a fire-fighter: it’s okay for them to be idle – just watching the team – waiting for an emergency obstacle.  Taking on tasks tends to distract the ScrumMaster from the job of helping the team follow the rules of Scrum, from the job of vigorously removing obstacles, and from the job of protecting the team from interruptions.
  7. Product Owner Doesn’t Show: The Product Owner is a full member of the team and should be present at all Scrum meetings (Planning, Review and Daily Scrums).  As well, the Product Owner should also be available during work time.  Of course, the PO also needs to work with stakeholders and might be away during that time, but these discussions should be scheduled outside of the team’s meeting times.
  8. Stretch Goals: The team decides on how much work it will do in a Sprint.  No one should bring pressure on the team to over-commit.  This simply builds resentment, distrust and encourages low-quality work.  That said, of course teams can be inspired by challenging overall project or product goals.
  9. Individual Heroics: Individuals on a Scrum team should not do excessive individual overtime, or in any other way try to be the “hero” of the team.  Scrum helps us build great teams of people, not teams of great people (quote from Barry Turner).
  10. Team Organizes Product Backlog: The team does not have proper insight into the needs of users and instead should be focused on solving technical problems.  The Product Owner needs to be accountable for ROI and therefore should resist any pressure from the team to do things in a particular order for “technical” reasons.
  11. Product Owner Specifies Solutions: The Product Owner must allow the team full freedom to come up with solutions to the problems presented in the Product Backlog.  PBIs should be free of technical specifications unless they can be tied directly to a customer or end-user request.
  12. Urgent Interruptions: Urgent interruptions should not be allowed in a Sprint… instead, if it is urgent enough, the team should cancel the Sprint.  Otherwise, the interruption should be put on the Product Backlog and deferred until the start of the next Sprint.
  13. Making Assumptions: Often team members will fail to ask the Product Owner about details of the work they are doing.  A team member solves problems, but it is critical to know about constraints.  The feedback between PO and Team Member should be ongoing throughout every day of the Sprint.
  14. Not Getting Done: This is hard to prevent from happening from time to time, but it can become a habit for a team to over-commit.  Make sure that a team that is doing this is using burndown charts effectively and is holding demos even when they have not completed all their work.
  15. Demo Not Ready: Sometimes a team forgets that it will take time to prepare for a demo: cleaning the team space, setting up a demonstration environment, getting scripts ready, and ensuring that critical stakeholders are prepped.  These activities can be part of the tasks in the Sprint Backlog.
  16. Prototype Not Shippable: A Scrum team should attempt to produce production-quality, “potentially shippable” software right from the very first Sprint.  Building prototype code just delays the inevitable need to write production code.  Similarly, wireframes, detailed designs and other similar tools should also be avoided.
  17. Distributed Team: Although Scrum does not officially require team members to be collocated in a “war room”, the reality is that any distribution of team members (even just into separate cubicles) has a huge negative impact on transparency and communication, which in turn has a huge impact on productivity and quality.
  18. Directive ScrumMaster: The ScrumMaster needs to be a facilitator who supports the team in learning self-organization, and the Scrum rules.  The ScrumMaster should never succumb to the temptation to suggest how a team member does his or her work, nor what task next to work on.
  19. Changing Team Membership: Scrum is a framework for creating high-performance product development teams.  If the membership of a Scrum team changes, it forces that team to re-start the Forming-Storming-Norming-Performing sequence.  If the team is in Norming or Performing, then changing team membership for any reason is a waste of quite an investment.
  20. Non-Scrum Roles on the Scrum Team: It is very common for an organization to create a Scrum team without changing the official title and duties of the people who are members of that team.  For example, a person who is a Project Manager might be given the responsibilities of the Product Owner without an official change of title.  Scrum teams should only have a ScrumMaster, a Product Owner, and Team Members.
  21. Giving Up On Quality: Scrum has very high demands on teams regarding the quality of their results: “potentially shippable software”.  It is easy for a team or organization to fall back on the crutch of defect tracking software instead of maintaining extremely high levels of quality at all times (due to pressure to release features).
  22. Imposed Deadline Scope And Resources: Scrum is reality-based.  If an external stakeholder wants to impose a minimum scope, a deadline and constrain the resources available to the team then they must allow that quality will slip… which in turn is against the principles of Scrum.  The reality is that no-one can predict the future so any such imposition is simply a fantasy.
  23. Definition of “Done” Imposed:  There is confusion between the concept of the definition of “done” and “standards”.  Managers and other stakeholders often incorrectly impose standards on a team as its definition of “done”.
  24. ScrumMaster Not Present: I once saw an organization that had created a room for a “team” of ScrumMasters.  They worked there together most of the time!  The only time the ScrumMaster should be away from the team is when he/she is working on removing an impediment that is outside the team.  Otherwise, the ScrumMaster should be in the team’s room.

Good Explanation of INVEST for User Stories

Posted on by
Reply

Mike Caspar, a fellow agile coach,  just forwarded me this YouTube video to Bill Wake talking about INVEST for User Stories.  I worked briefly with Bill back in 2004/2005 at Capital One where he did some excellent coaching.  I strongly recommend checking out the video!

Comparison of OpenAgile with Scrum

Posted on by
1

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

OpenAgile Reference Sheet Download – First Draft Available

Posted on by
1

Hi Everyone!  As you know, I’ve been working with my team at Berteig Consulting and with some of our clients to create the OpenAgile method.  OpenAgile is based on Scrum and Lean, and integrates some important learning and teamwork principles and practices.  We’ve just published the first draft of the OpenAgile Reference Sheet.  This is based on the OpenAgile Primer as well as integrating some late-breaking learning about the use of Agile in non-software environments.  I hope you like it, and let me know if you have any suggestions!  We’re going to get to an official first release of OpenAgile soon, and when that happens, we will also be starting the official “open” part of it – OpenAgile is meant to be an open-source agile method!

Growth Facilitator role on an OpenAgile team

Posted on by
Reply

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

Scrum Gathering – Orlando Florida – Day 1 Summary

Posted on by
Reply

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

Some observations:

More People Using Agile and Scrum for Non-Software

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

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

Economic and Recession Fears

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

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

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

Reconnecting with Friends and Collegues

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

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

Highlight of the Day

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

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

Looking Forward to Day 2

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

Agile Successes and “Failures”

Posted on by
Reply

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