Tag Archives: Process

Reference Information, Scrum, XP and Lean

The Rules of Scrum: I am willing to learn any skill needed to help my team

2 Comments

Scrum Team Members, excluding the ScrumMaster and Product Owner, must be completely open-minded to learning new skills.  Skills can be technical, business, personal, tools-based, etc.  A Team Member is sensitive to the needs of the Scrum Team and will learn skills by multiple means as the needs of the team evolve.  A Scrum Team where people are not willing to learn new skills will suffer from bottlenecks, time pressure, quality problems, and often will become generally demoralized as the willingness of some people on the team turns into apathy and cynicism when others refuse to learn.  In a team where everyone is willing to learn new skills, there will be a consistent raising of capacity and the team will be able to do more and more work more effectively.  This attitude is a key requirement for the formation of high performance teams.

Affiliated Promotions:

Register for a Scrum, Kanban and Agile training sessions for your, your team or your organization -- All Virtual! Satisfaction Guaranteed!
Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail
Agile Management, OpenAgile, Scrum, XP and Lean, Theory of Agile

OpenAgile is not (just) Empirical

Leave a comment

A few weeks ago, David Parker and I had a conversation about some of the differences between Scrum and OpenAgile.  We hit upon one really interesting thing: Scrum strongly emphasizes that it is a purely empirical approach to doing work… and OpenAgile does not make that claim.  In fact, OpenAgile, while it includes empiricism, is definitely not an empirical process framework.

Ken Schwaber has long been adamant about empiricism with his phrase “Inspect and Adapt” which is the core of Scrum.  All the artifacts, meetings and roles of Scrum are meant to be supportive of the inspect and adapt approach in a product development environment.  A Scrum self-organizing team inspects and adapts on the product it is building.  It inspects and adapts on the obstacles that arise as it does its work.  It inspects and adapts on all the organizational processes, technical tools, team dynamics,… everything!  This is Good.

But Scrum, in its pure empiricism, also lacks something.

OpenAgile has components of Scrum’s empiricism.  Certainly, OpenAgile owes a great deal to Scrum.  The concept of “Systematic Learning”, one of the foundations of OpenAgile, is similar to Scrum’s empirical framework.  The process structure of OpenAgile is also similar to that of Scrum with short cycles of work delivering value on a regular basis.  The main difference comes from a simple concept: Guidance.

In OpenAgile, guidance is a critical component of systematic learning.  Guidance allows someone outside the team to intervene.  This might be a manager, a stakeholder, a family member… anyone who sees things from an “outside” perspective.  It might also be someone within the team pulling in guidance: asking for advice, doing a web search, reading a book, or even meditating in the hope of inspiration.

In Scrum, there are some very strong boundaries around outsiders providing guidance.  No changes mid-sprint.  All requests for work go through the Team’s Product Owner.  The ScrumMaster “protects” the team from outside interruptions.  “Chickens” cannot participate in the Daily Scrum.  The team self-organizes with individuals volunteering for specific tasks.  Team members discard all organizational titles when working within a Scrum team.  All of these boundaries support a pure empirical approach to working.  They also provide a form of safety for the team.  This safety is deemed necessary with the implication that stuff from outside the team is dangerous.

In OpenAgile, guidance comes to the team through the conduit of love.  Yes… love.

The team develops a love for its work.  This love then opens the team members to guidance.  Think of the opposite: if I hate my work, I’m not likely to be interested in taking any advice about how to do it better.  If I love my work, I will always be seeking ways to improve it.

Of course, love is not binary.  It’s not on or off.  In that continuum, the more an OpenAgile team loves its work, the more receptive it will be to guidance.  The more receptive to guidance, the more sources of guidance will be “safe”.  And the less reliance on pure empiricism will be necessary.

Let’s be frank: pure empiricism, in its most extreme form, means that Scrum teams would re-invent things that may have already been invented many times before.  In the Scrum community, the most obvious example of this is the Agile engineering practices that come from Extreme Programming.  Scrum teams seem remarkably resistant to adopting these practices at the outset… despite the fact that eventually most Scrum teams working in software succeed or fail based on their eventual adoption of these practices.  Scrum teams are often left without the guidance that XP practices can help them.  Instead Scrum teams seem expected to re-discover XP practices on their own.

For what it’s worth, I don’t think that Scrum is fatally flawed.  In fact, I think that in some environments, where teams truly are unsafe, where people tend to hate their work, where dysfunctional bureaucracy is deeply embedded in the organizations culture… in these environments Scrum is actually the right place to start.  Scrum is great for product development in high-crisis situations: save your product with Scrum!

OpenAgile, by accepting guidance into its framework, allows teams to progress rapidly when they can leverage other people’s learning.  Scrum does not dis-allow this, but it sets up an environment where the team culture tends towards the “Not Invented Here” syndrome.  OpenAgile puts teams on the other path: the path of allowing for greater and greater learning from others.

Affiliated Promotions:

Register for a Scrum, Kanban and Agile training sessions for your, your team or your organization -- All Virtual! Satisfaction Guaranteed!
Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail
Agile Case Studies, Agile Management, How-To Apply Agile, OpenAgile

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

Leave a comment

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.

Affiliated Promotions:

Register for a Scrum, Kanban and Agile training sessions for your, your team or your organization -- All Virtual! Satisfaction Guaranteed!
Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail
OpenAgile, Reference Information, Scrum, XP and Lean, Theory of Agile

Comparison of OpenAgile with Scrum

2 Comments

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

Affiliated Promotions:

Register for a Scrum, Kanban and Agile training sessions for your, your team or your organization -- All Virtual! Satisfaction Guaranteed!
Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail
Agile Case Studies, Agile Management, How-To Apply Agile, OpenAgile, Reference Information

Growth Facilitator role on an OpenAgile team

Leave a comment

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

Affiliated Promotions:

Register for a Scrum, Kanban and Agile training sessions for your, your team or your organization -- All Virtual! Satisfaction Guaranteed!
Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail
Miscellaneous

Stonecutters, Paycheck Earners, or Cathedral Builders?

Leave a comment

All credit for this is due to Mary Poppendieck as this is entirely cribbed from her Agile2007 talk on agile leadership.

A man walks into a quarry and sees three people with pickaxes. He walks up to the first one and asks, “What are you doing?” The first quarry worker irritably replies, “I’m cutting stone, what does it look like? I cut stone today, I cut stone yesterday, and I will cut stone tomorrow!” The man asks the same of the second person who replies, “I’m making a living for my family.” The man turns to the third person and asks him, “so what are you doing here?” The third worker looks up for a moment, looks back at the man with a proud expression and says, “I’m building a Cathedral!”

The moral of the parable is likely clear, but it bears applying to organizational dynamics. Basically, consider that everyone gets annoyed with aspects of their jobs. The question is one of response. Basically, if a person is annoyed with his job, does he:

  • Complain? He is probably a stonecutter.
  • Ignore it? He is probably a paycheque earner.
  • Fix it? He is a cathedral builder.

Cathedral builders are absolutely critical to a healthy organization. They push the organization towards a vision, often propagating the high-level vision throughout all levels of the organization. Unfortunately, these are also people who annoy the stonecutters and paycheque earners, because they won’t participate in the complaints, and they agitate for changes which make it hard to ignore things and just “do the job.” But your success will rely on them… find them, shelter them, and grow them. And whatever you do, don’t “promote” them into positions where they aren’t effective. Empower them, and if you need to add salary and title that’s fine, but let them find their own area of maximal contribution. Guaranteed you, Mr. business owner, aren’t smart enough to see what that is.

Organizations that fail to see this remain mediocre or failing organizations. Organizations that find ways of harnessing their workforce and coaxing people into the next level of engagement, succeed.

Affiliated Promotions:

Register for a Scrum, Kanban and Agile training sessions for your, your team or your organization -- All Virtual! Satisfaction Guaranteed!
Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail
Agile Management

Agile Benefits: Responding to Change

Leave a comment

The fact that agile methods increase return on investment, accelerate learning, increase stakeholder satisfaction, and enable better control of work are all an interesting result of this final benefit: responding to change.

Continue reading Agile Benefits: Responding to Change →

Affiliated Promotions:

Register for a Scrum, Kanban and Agile training sessions for your, your team or your organization -- All Virtual! Satisfaction Guaranteed!
Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail
How-To Apply Agile, Links to Agile Info

Agile Retrospectives and the Plan of Action

Leave a comment

Bas Vodde has published a good article about making goal oriented action plans for agile projects. It is a nice piece of the puzzle on how to do effective retrospectives. It also nicely ties into the “Learning Circle” Reflection/Learning/Planning/Action steps.

Affiliated Promotions:

Register for a Scrum, Kanban and Agile training sessions for your, your team or your organization -- All Virtual! Satisfaction Guaranteed!
Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail
Agile Management, Theory of Agile

Time is Not Negotiable

Leave a comment

The Project Management Institute refers to three variables that can be negotiated or constrained for a given project: scope, resources and schedule. Schedule is an interesting “variable” in that we have no choice about how time flows. We can control how much scope to ask for, we can control how much money to put towards the work, but we cannot actually “buy” more time than, say, our competitors. This has important implications which deeply challenge the PMI’s PMBoK model of project management.

Continue reading Time is Not Negotiable →

Affiliated Promotions:

Register for a Scrum, Kanban and Agile training sessions for your, your team or your organization -- All Virtual! Satisfaction Guaranteed!
Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail
Agile Case Studies, Agile Management, How-To Apply Agile

First Interation Ending

Leave a comment

My first iteration using Agile Work for my business development has come to a close. Here is what I did for a “demo” and retrospective.

Continue reading First Interation Ending →

Affiliated Promotions:

Register for a Scrum, Kanban and Agile training sessions for your, your team or your organization -- All Virtual! Satisfaction Guaranteed!
Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail
Agile Engineering, Agile Management, Theory of Agile

Technical Debt

Leave a comment

Last night I was thinking more about the analogy of technical debt. In this analogy, design and quality flaws in a team’s work become a “debt” that must eventually be paid back. This analogy is fantastic because it can be taken just a little bit further to understand just how bad defects are…

Continue reading Technical Debt →

Affiliated Promotions:

Register for a Scrum, Kanban and Agile training sessions for your, your team or your organization -- All Virtual! Satisfaction Guaranteed!
Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail
Agile Management, How-To Apply Agile, Links to Agile Info

How to Avoid Context Switching

Leave a comment

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.

Continue reading How to Avoid Context Switching →

Affiliated Promotions:

Register for a Scrum, Kanban and Agile training sessions for your, your team or your organization -- All Virtual! Satisfaction Guaranteed!
Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail
Agile Case Studies, Agile Management, How-To Apply Agile

The Case for Context Switching

2 Comments

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.

Continue reading The Case for Context Switching →

Affiliated Promotions:

Register for a Scrum, Kanban and Agile training sessions for your, your team or your organization -- All Virtual! Satisfaction Guaranteed!
Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail
Agile Management, How-To Apply Agile

Process Facilitator “Smells”

Leave a comment

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.

Continue reading Process Facilitator “Smells” →

Affiliated Promotions:

Register for a Scrum, Kanban and Agile training sessions for your, your team or your organization -- All Virtual! Satisfaction Guaranteed!
Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail
Berteig
Upcoming Courses
View Full Course Schedule
Scrum Master Bootcamp with CSM® (Certified Scrum Master®) [Virtual Learning] (SMBC)
Online
C$1895.00
Jun 7
2023
Details
Real Agility™ Team Performance Coaching with BERTEIG (COACHING-TPC)
Online
C$750.00
Jun 9
2023
Details
Real Agility™ Real Agility™ Ask Me Anything / Coaching
Online
C$750.00
Jun 9
2023
Details
Win as a Manager with Your New AI Coach: Max Good (WEBINAR)
Online
C$0.00
Jun 9
2023
Details
Kanban System Design® (KMPI)
Online
C$1895.00
Jun 13
2023
Details
Product Owner Bootcamp with CSPO® (Certified Scrum Product Owner®) [Virtual Learning] (POBC)
Online
C$1495.00
Jun 14
2023
Details
Real Agility™ Team Performance Coaching with BERTEIG (COACHING-TPC)
Online
C$750.00
Jun 16
2023
Details
Real Agility™ Real Agility™ Ask Me Anything / Coaching
Online
C$750.00
Jun 16
2023
Details
Kanban for Scrum Masters (ML-KSM)
Online
C$495.00
Jun 20
2023
Details
Kanban for Product Owners (ML-KPO)
Online
C$495.00
Jun 21
2023
Details
Team Kanban Practitioner® (TKP)
Online
C$1015.75
Jun 21
2023
Details
Real Agility™ Team Performance Coaching with BERTEIG (COACHING-TPC)
Online
C$750.00
Jun 23
2023
Details
Real Agility™ Real Agility™ Ask Me Anything / Coaching
Online
C$750.00
Jun 23
2023
Details
Real Agility™ Team Performance Coaching with BERTEIG (COACHING-TPC)
Online
C$750.00
Jun 30
2023
Details
Real Agility™ Real Agility™ Ask Me Anything / Coaching
Online
C$750.00
Jun 30
2023
Details
Scrum Master Bootcamp with CSM® (Certified Scrum Master®) [Virtual Learning] (SMBC)
Online
C$1270.75
Jul 5
2023
Details
Kanban Systems Improvement® (KMPII)
Online
C$1610.75
Jul 11
2023
Details
Product Owner Bootcamp with CSPO® (Certified Scrum Product Owner®) [Virtual Learning] (POBC)
Online
C$1270.75
Jul 12
2023
Details
Team Kanban Practitioner® (TKP)
Online
C$1015.75
Jul 19
2023
Details
Advanced Certified ScrumMaster® (ACSM)
Online
C$845.75
Jul 19
2023
Details
Scrum Master Bootcamp with CSM® (Certified Scrum Master®) [Virtual] (SMBC)
Online
C$1270.75
Aug 2
2023
Details
Team Kanban Practitioner® (TKP)
Online
C$1015.75
Aug 15
2023
Details
Product Owner Bootcamp with CSPO® (Certified Scrum Product Owner®) [Virtual Learning] (POBC)
Online
C$1270.75
Aug 16
2023
Details
Scrum Master Bootcamp with CSM® (Certified Scrum Master®) [Virtual] (SMBC)
Online
C$1270.75
Sep 19
2023
Details
Team Kanban Practitioner® (TKP)
Online
C$1015.75
Sep 19
2023
Details
Product Owner Bootcamp with CSPO® (Certified Scrum Product Owner®) [Virtual Learning] (POBC)
Online
C$1270.75
Sep 26
2023
Details
Kanban System Design® (KMPI)
Online
C$1525.75
Sep 26
2023
Details
Scrum Master Bootcamp with CSM® (Certified Scrum Master®) [Virtual] (SMBC)
Online
C$1270.75
Oct 3
2023
Details
Team Kanban Practitioner® (TKP)
Online
C$1015.75
Oct 18
2023
Details
Product Owner Bootcamp with CSPO® (Certified Scrum Product Owner®) [Virtual Learning] (POBC)
Online
C$1270.75
Oct 24
2023
Details
Kanban Systems Improvement® (KMPII)
Online
C$1525.75
Oct 25
2023
Details
Scrum Master Bootcamp with CSM® (Certified Scrum Master®) [Virtual] (SMBC)
Online
C$1270.75
Nov 7
2023
Details
Product Owner Bootcamp with CSPO® (Certified Scrum Product Owner®) [Virtual Learning] (POBC)
Online
C$1270.75
Nov 21
2023
Details
Team Kanban Practitioner® (TKP)
Online
C$1015.75
Nov 21
2023
Details
Scrum Master Bootcamp with CSM® (Certified Scrum Master®) [Virtual] (SMBC)
Online
C$1270.75
Dec 5
2023
Details
Product Owner Bootcamp with CSPO® (Certified Scrum Product Owner®) [Virtual Learning] (POBC)
Online
C$1270.75
Dec 12
2023
Details
Kanban System Design® (KMPI)
Online
C$1525.75
Dec 12
2023
Details
Team Kanban Practitioner® (TKP)
Online
C$1015.75
Dec 19
2023
Details