Scrum Development Blog

Better teams make better products.

Team Rhythms and Noise

Scrum Questions | Posted by doug.shimp
Feb 07 2011

quiet scrum teamsScrum makes an assumption that you have a dedicated team who can focus on something for a sustained period of time. Most highly cognitive products require sustained focus and a consistent team rhythm.

Teams tend to get into a common rhythm in which quiet time andscrum rhythmsnoisy time are synced so that team members don’t bother each other very much. People whose work is disconnected have different rhythms. Noise is a real problem when you’re trying to do something that is highly cogitative.  So protecting the team from out-of-sync noise can be very important.

Questions

How do you protect teams from out-of-sync noise?

One might expect that surrounding an entire team with some noise protection (walls or space) would be sufficient. Does that work?

It shouldn’t be important to protect team members from each other’s noise. Do you agree?

What have you observed? What has worked in the past?

Is there a demographic shift between older and younger?

Teams: Meet Jake.

Development | Posted by liz.weatherhead
Jan 28 2011

Meet Jake.  At our small team daily stand-ups, Jake has more ideas than anyone else and he feels the need to share them all at every meeting. Although,  I must admit, Jake is the only team member who is concerned that everyone gets a chance to contribute.  Yet, at the large group meetings, he is reflective and quiet and is very intent on listening.   When he is asked a question, Jake takes a long time to respond.  Jake tries to be friends with everybody and sweet talks the boss, in my opinion.   Thriving on consensus, Jake needs to know all the opinions before we make any decision at all.  He takes everything personally!  The core ethical values of the organization are the rationale Jakes relies on  for drawing conclusions.  We must be in alignment with them!  He communicates well, but it’s feeling based, not grounded in best practices or expert thinking.  And team building is his absolute favorite.

Sound like a teammate of yours?  What I described is Jake’s learning style, how Jake prefers to take in and process new information.  Learning styles are often mis-labeled as personalities.  That is how learning can breed team conflict.  We see things as personal, not a function of brain-wired learning.

Let’s get back to Jake.  Jake is a reflective, feeling learner.  He functions more comfortably in small groups, and shows his deep need to be watchful and take it all in.  ”Sweet talking” the boss has no hidden agenda.  It’s Jake’s way of connecting and creating harmony, similar to Jake’s desire to reach consensus with team decisions. Team building is essential to build trust on a team, and Jake brings that voice to the table.  Trust is not a :touchy-feely” attribute, it is a mathmatically proven equation to produce better results in the business world.

As for Jake’s need to ground all things in feelings rather than fact…well, that is simply an example of effectiveness striving to balance efficiency.

Next blog, we will meet team members who are also reflective in communicating and learning.  However, they are trenched in the facts instead of the feelings.

If you are seeking skills to improve team interactions, join 3Back for our newest course, 4MAT for Scrum Teams.

Why should a ScrumMaster be a Master of Learning?

Development | Posted by liz.weatherhead
Jan 17 2011

Listening to the product.  Communicating in daily stand-ups.  Solving the problem.  They all have one thing in common.  Learning.  Every time we share information, it is learning.

When the Scrum teams listen to products, they listen through their own learning perspective.  They have preferences in how they consume information.  This is their learning style. During daily stand-ups, demos, and retrospectives, Scrum teams dialog and listen to each other; they process knowledge individually and uniquely.  This is their learning style.  As teams strive to problem solve, all learning preferences converge as they seek resolution.

When aScrumMaster can master the knowledge of learning styles and preferences, he can more effectively nurture his team to their best performance.  ScrumMasters can seek team members to complement each other in their learning styles.  Conflict can be managed through awareness of thought patterns.  Effective and efficient questioning pathways can be sought in sprint planning meetings and product demos.

There are four distinct learning styles as differentiated  by the Learning Type Measure (LTM) designed by 4MAT.  4MAT has simply, but elegantly, plotted the learning preferences on a grid of four quadrants.

4mat learning styles

If you are a One, you prefer to take in knowledge through experiences.  How you feel about the knowledge is important on your learning path. Once you have taken it all in, Ones will reflect, and especially enjoy reflective dialog in small groups.  Most important to you is the question “Why?”  Why is this meaningful to me?  Why should I care about this?

If you are a Two, you share that reflective strand, but would rather be surrounded by facts and expert thinking than experiences.  ”What?” is your driving question. Twos are the data driven, quiet team members.  You think carefully before sharing an idea.  You want to know what.  What are the facts and what do the experts say?

Threes, like Twos, want to know what credible experts believe. Then, you like to  test the theories for yourself before you buy into it. Threes will tinker with and explore the ideas.   Threes will not believe until they can prove it to themselves.  They ask “how?”  How does this work in the real world?

Threes and Fours are both doers in their learning.  They literally want to get their hands on it.  However, Fours circle back and share the desire for experience with the Ones.  Fours ask, “What if?”  What if, I adapt the expert way and make it my own?  Fours will jump in and learn as they go.

As a ScrumMaster, if you could master awareness of your team’s learning style, think of the benefits.  Diverse learning styles on teams would raise sharper questioning paths about the product. They would spark each other to greater problem solutions.  Team conflict would no longer be seen as personal, but rather as style differences.  Daily stand-ups, demos and retrospectives would be charged with creative tension, always pushing bigger and better thoughts.

Doesn’t that sound like a well formed team?

Learn more about well formed teams with our new course from 3Back, 4MAT for Scrum Teams.

Scrum Team’s Purpose

Agile Pathways | Posted by The 3Back Team
Jan 11 2011
The Scrum Team’s purpose is to create a result that satisfies the Stakeholders needs, wants and desires, often so that more demand for their services is generated. This production is done through a series of relatively short, fixed-length iterations, called Sprints, in which results are produced by working on items that lead up to satisfying the stakeholders.


Stakeholders can be anyone who has an interest in the product. Important stakeholders are those who are requesting the product and often (almost always for commercial products) end users. End users are often considered the person who pays for the product (your customer) but, this is not true for all products. A classic example is medical making software for equipment. In the medical industry, you often build the product to 1st satisfy the end user buyer and then figure out what is best for the end user.product flow scrum purpose

Regaurdless of who your Stakeholders are and your end user is there are a few assumptions that are worth noting in “agile / scrum development“.
  • there is a flow of work
  • the work is conceptually demanding enough to warrant a scrum team
  • there is a well formed team available to do that work

When these assumptions are not valid then scrum implementations get very interesting :)

Should I Take Advanced or Beginner Agile Training?

Scrum Questions | Posted by The 3Back Team
Oct 21 2010

Agile / Scrum Training should cover the fundamentals in every course. Agility is a deep practice that requires years of effort to master and maintain mastery. The fundamentals are the underpinnings that enable a practitioner to manifest deep applied skill and technique in the face of day to day complex work.

We are regularly asked questions like the following section in green.

fundamentals of agility

We would like to sign up a group of people that do have some working knowledge of SCRUM. They are currently in the Product Owner, ScrumMaster or Team role.Is your course advanced enough to give us value or is it meant more for beginners?  We want to know more about how to properly create and manage our stories, prioritize, etc….do our jobs better and more effectively…but we already do understand the high level scrum process.

Our response typically goes something like …

The difference between advanced and beginners is a concept that we work to break down as follows. By asking for advanced or beginner agile training you are already driving thought in an unnecessary and limiting way, which is not agile! Agile training should always cover the fundamentals, which never go away and you will always need to work on. So an agile course should hit the fundamentals of agility and exploring agility using a Scrum Framework (or other agile method). The course should be built and driven by an experienced practitioner that also trains. Experienced practitioners should be able to coach as well as train so that the deep skills of agility are manifested and show up in practice. Our curriculum is designed to bring out the deep practice of Scrum as it relates to the Product Owner, ScrumMaster or Team role and help the practitioner pick up real skills / techniques that they can put to valued use. Our course is not about basic scrum mechanics / process.

Our goal with this post is to raise awareness that Agile / Scrum is a practice that requires agility for mastery. An agile pathway is needed to produce individuals with real skills that join teams that can enable real agility within an organization. Agile well formed teams are the key for product development and innovation within organizations.

When you look for agile training, look for training that comes from fundamentals.

Agile’s 2 Big Rules

Agile Pathways | Posted by The 3Back Team
Sep 24 2010
Agile’s 2 big rules is a way to guide the team toward maturity while they are pursuing a product outcome.

Rule One: The team will adapt it’s processes to realities encountered and improve their ability to deliver quality product, within organizational constraints.

Rule Two: The team will seek regular feedback on behalf of the product from any acceptable source.

Start your team …

… in a …

Prescriptive Manner: Tell the team how to get started, balance and which constraints to apply.

… then look for …..

Descriptive Signs: Observe, support and nurture  the team to mature and take team ownership as they pursue product outcomes.

Scrum Values, Visibility and Trust Loops

Development | Posted by The 3Back Team
Aug 22 2010

Trust is earned.

Some fundamentally disagree with this statement. For those that disagree Trust is given freely. They give trust freely until such time as a person irrevocably betrays that trust.  They believe that this leads to a method of management that creates hostile antagonistic workplaces rife with fear. A pattern of mistrust is established that leads others to be mistrustful and perpetuates a negative cycle of oppression.

I would agree that it sets up a behavior pattern that is negative and learned. However when I am asked to just trust someone this feels wrong to me. It’s not that I don’t trust them or do trust them It is more that I have no reason to trust them. For colleagues at work I have evidence to suggest that they won’t attack be suddenly with a gun or knife. So I trust them not to do that. However, for a man who steps out suddenly from a darkened alcove in a lonely ally… I don’t trust him that far. Why? I have no data to suggest that pattern of behavior is appropriate in that context.

So I propose that trust is earned not given freely. Most people conceptualize trust as a bank account +- (data from cognitive psychology).  So how do we open an account and start filling it?

If someone says to me, you just need to trust “xxx” and I lack data to agree then I am paused. If I say I don’t trust them will they call me a distrustful or suspicious person? Are they trying to attack my value system? What do I say here to not get painted as an oppressive mistrustful person?

Think of trust as a Trust Loop and visibility as the key to seeding that loop. I make shared work or activity visible so that we can do something/anything together.

visibility, trust loop and scrum values

Trust is earned. Anything else is what I call faith. I avoid using faith (blind intuitive leaps) for what should be an empirical approach. Now you might argue I should have enough evidence to be comfortable with something and should trust them. Truly, if I can find the data and convince myself without spending too much time, then I will. But, please let’s not argue about lack of trust. That makes me crazy and I see it too often as a bullying technique to beat someone down or attack their value system because you don’t agree with them.

Scrum Values and I propose another

1. Commitment

2. Focus

3. Openness

4. Respect

5. Courage.

6. Visibility

Visibility is valued by me because it allows me to seed the trust loop. Once I can see or have experienced working with someone on anything my trust account grows. It takes time to know and grow a relationship. As the relationship grows it becomes easier to work with that person and make bigger leaps of understanding based on previously established rapport.

Hence my rule: Make it Visible

Make it visible is one of my foundational legs that the Scrum framework rests on.

Transparency and Visibility for Better Engagement

Scrum Terms | Posted by The 3Back Team
Aug 20 2010

When a process is confusing to me and I am not sure why then I pause. Confusion encourages me to back away because I don’t understand it. Transparency alone is that way. Too much of the wrong information and I cannot tell where to apply my energy. Everything is at the same level of visibility.

How about appropriate visibility so that I know where to apply effort?transparency visibility scrum

  • Where do I apply energy?
  • When do I apply energy?
  • How should I engage?

How about appropriate transparency so that I know which decisions to consider?

  • What am I looking at?
  • Should I dig in?
  • Does this tell me anything?

Please don’t pummel me with a ton of info (an open dump of transparency). I should be able to expose details on demand and find detail when I want it. Details should be well summarized so that I know when and if to dig in.

If people are engaging in the wrong way it is because we have emphasized the visibility wrong and not found balance with transparency. Transperency is not an end all answer but actually has an twin in visibility. Balanced both then the whole process is natural and obvious. So maybe these rules would help and maybe a better way to think about process would help more.

Rule: Make it visible.

This reminds me that self-organization will occur when we get the visibility right.

Rule: Keep it transparent.

This reminds me to help with informed decision making so that people feel comfortable with the data they receive to make choices.

Also, we need time to learn if the game keeps changing our learning has not stabilized. Changing fast&often is not learning it is just frenetic. We have to consider learning as a community not an individual which means we need to look for a critical mass of understanding (Do not have evidence of that?).

In either case engagement is informative, it should not be mandatory. Positive or negative feedback is useful since in either case we are learning and can use that to emerge a balanced process.

New Certified Scrum Developer Program

News | Posted by tuna
Aug 17 2010

3Back,LLC announces Certified Scrum Developer (CSD) Program.

3Back has announced the introduction of their new Certified Scrum Developer (CSD) course program, this program is aimed at software development professionals who need to raise their technical game, in order to build robust scalable products in today’s modern enterprise environments. The program is delivered in 2 parts: 3 days of core technical engineering agility training, and 2 days of scrum process training.

The 3 day core technical training is delivered in a course called Effective Scrum Developer (ESD).This new training course is unique, by balancing the effort to learn theory, with applied practice. The ESD course is delivered in a tool specific manner using Visual Studio 2010.

The 2 days of scrum process training can be achieved by completing either a Certified ScrumMaster (CSM) or other qualified course. The first ESD course will be held in Minneapolis, MN., beginning June 9-11, at the Normandale Community College.

3Back Senior Trainer & Managing Partner, Douglas Shimp, CST. believes this Agile Pathway™ is another stepping stone towards improving organizational agility and team success.

3Back is a Scrum Management Consulting and Training company that helps leading companies improve their applied business agility. 3Back regularly provides 1st step training in the form of public and private scrum training around the United States for Certified ScrumMaster and Certified Product Owners. Additionally, 3Back provides adoption and tuning services for improved business agility with their Agile Pathways™ program. They are experts in applied Scrum. “We make teams better.”

Source:3Back Scrum Consulting and Training

##

Should we adjust the time box in Scrum?

Scrum Questions | Posted by The 3Back Team
May 19 2010
Pick one:
  1. Yes, it is ok, the team needs to be managed by the Scrum Master who decides when to adjust.
  2. Yes, if the Product Owner approves
  3. No, use the time box to help detect when things are not well understood and where clarity is needed. Time boxes bring rhythm
  4. Sometimes, if the Product Owner and Scrum Master agree

scrum timeboxtime box is a common practice underlying most agile processes especially, Scrum. Time boxing is a the closest thing in agile or scrum that we have to something that is clearly a best practice. Most managers or early adopters of Scrum wonder what they do to create a sense of urgency and the answer is simple “Time Box”.

In Scrum we have 6 formal timeboxes.

  1. Release Planning
  2. Sprint Planning
  3. Sprint
  4. Daily Standup
  5. Sprint Review
  6. Sprint Retrospective

Time boxes are a key element in Scrum. They form the a bases for how we manage the team’s energy. The general rule in using time boxes is to not adjust the time once you have set it. When the clock runs out the bell “dings” and things change.

#1 mistake those new to Scrum make is to adjust the sprint length to give the team more time to complete their work. Basic Scrum training should cover and provide an in depth explanation of why not to adjust the time box.