Scrum Development Blog

Better teams make better products.

Posts Tagged ‘scrum’

Agile vs. Waterfall: A Tale of Two Teams

Agile Pathways | Posted by liz.weatherhead
Jan 23 2012

Agile vs Waterfall Video Reactions:

Kate and Rusty have the same goals: to build a great product for their client. Their approaches, outcomes, and results are very different. Neither is right nor wrong. BUT I sure know which team I would appreciate.

Tear down the walls of silos, put multiple heads on a problem, and engaging the client frequently are all hallmarks of agility and gaining business value. Every wonder how they get those video games to market so fast? Agility. Proudly deliver a product every two weeks to your clients…

Agility is the ultimate in teamwork. Projects move fast and everyone pulls their own work, thereby creating accountability. Boss-worker mentality is a thing of the past. Kate’s team stays fresh and motivated. Rusty’s team has a hard time staying in for the long haul.
Which team are you on?

Break the Habit

Agile Pathways, Musing, Well Formed Teams | Posted by liz.weatherhead
Oct 31 2011

Want to ditch your Retrospective?  

Are Product Demos painful and shallow on the feedback?

This is what we hear from our Scrum teams over and over.  The Scrum framework is simple and elegant, but implementation can be complex.

Communication and learning are highly intertwined and as Scrum believers, we are compelled to do both at a high level.  We need to shape questions to drive the learning and to forge a path for the product development.  How can we ever gain robust, vital feedback without engagement of our audience?
  • Don’t abandon the Scrum ceremonies, re-frame them with robust and relevant questions that drive the learning.
  • Build better products by building better teams with awareness of communication patterns.
  • Navigate the pitfalls of stuck perspective by shifting team thinking.
  • Tell stories to illustrate a point or perspective.
Asking questions is risky business.  We have no control over the answer and we may not like the answer.  But as ScrumMasters, Product Owners, and developers, we must be fearless in our quest to drive greatness for our end users.   Here are some question examples to bring life to your next Scrum ceremony.  
Daily Scrum
  • What is frustrating you?
  • What new information has surfaced?
  • What skills do we need to finish the story?
  • What’s your gut reaction to _______?
Product Demo
  • What are your biggest dreams for this product?
  • What are the pros and cons to this product release?
  • We have run into a challenge and are seeking your input to solve it.
  • If we could take one risk with this product it would be_____.  What do you think?
These are solutions that will propel Scrum meeting into a higher level of engagement. Break the habit of the same old, same old Scrum meetings.  Learn to ask significant questions.  See where the questions will take you.

Read the rest of this entry »

Agreement

Scrum Terms | Posted by The 3Back Team
Sep 22 2011

An Agreement between the Product Owner and the rest of the Team that defines whenStory will be complete. The Agreement consists of the Acceptance Criteria, the Doneness Definition, and possibly additional General Agreements. This notion can be extended to Capabilities, Sprints, Releases, and so on… (synonym for Definition of Done)

We use an agreement driven approach to handle planning at all levels. In each case we are building an understanding of what we think we can do. For complex work we often encounter new information while doing the work that causes us to rethink and build new agreements.

When Your Strength is Your Weakness

Musing, Well Formed Teams | Posted by liz.weatherhead
Jul 07 2011

What is your strength?

Is is creating ideas?

Is it researching the latest and greatest data for a project?

Perhaps your strength is figuring out how the system is going to work in the real world.

Maybe your strength is bringing ‘good to great’ thinking to the latest product.

Whatever your strength may be, if it is a deep and strong attribute, it has potential to become your shadow or weakness. Think about a tree. The larger and stronger it becomes, the darker and deeper its shadow.  The same with people.  So, we need awareness when this is happening and strategies to minimize the negative.

Let’s talk about what that may look like in the real world.  If I am a strong, analytical thinker who reflects deeply on all decisions, what are the symptoms of my assets crossing the line into a weakness?  I may find myself commenting on every little detail of situations, projects or even the BBQ sauce on my friend’s sandwich!  Becoming paralyzed by analysis—never believing you have enough data and facts to make decisions—and to make the decisions correctly.

Or you may struggle getting things accomplished, producing results and implementation.  If the strength is fostering corporate culture and team relationships,  then processes, systems and planning may not be on my radar.  I may even be challenged with staying focused and choosing a plan to implement.  When the team asks for direction, you may reply with a dream or a vision for the future instead of a concrete game-plan that can be executed.

So, what to do about it? Awareness is the first step.  Listen to your team and your friends when they point out your habits and share their frustrations with your pattern of thought and conversation.  Ask for what they need from you and make a conscious effort to deliver what they ask for.  Seek out the viewpoint of teammates with the opposite strength.  Look for how their comments contrast and balance your own thought patterns.  Strive to blend the two to create a vibrant, relevant solution and pathway to success.

For more strategies to maximize team strengths, come learn with us at 4MAT for Scrum Teams.

Learning can be Agile

Musing, Well Formed Teams | Posted by liz.weatherhead
Apr 08 2011

Agile is defined as a ‘quick, resourceful and adaptive character’.  How can we be quick and adaptive in problem solving on our teams? By tapping into the hard-wired learning machines that we are.  Diverse learnings styles that are present on every Scrum team can be tuned for driving rich and vibrant solutions to project challenges.

Learning strengths and weaknesses are hard-wired, but, through awareness, we can grow our abilities as a team to chew through the learning curve. Team members abilities to process information in diverse patterns, is an untapped resource.  A resource that is both efficient and effective.
basic scrum team building block
Preferences in learning are not complicated. People perceive, or take in, information  through experience or through thinking and judging.  Some of us would like to learn by the experiences of feeling, tasting, touching, smelling; being immersed in an experience.  In other words, they prefer to go to Disney World, not read about it.  Others would perfer to read about Disney, to learn about it.  In fact, credible resources, whether print or people,  are very important to analytical, thinking learners.

Once we have taken the information into our brains, we need to process, or digest it. Again, there are two preferences.  Reflection is hard wired for some of us.  The need to ponder and draw purposeful conclusions by observations, serves them well in developing solutions.  Others are active learners.  They process information by doing something with it.  Testing it, adapting it or plunging head first and learning by trial and error.

This world of ours demands that we go fast, fast. It requires that we churn though complicated, complex and even chaotic problems in a rapid fashion. To do that, we need awareness of our team learning strengths and learning gaps.  When Scrum teams have thinking and experiential learners that are both reflective and active, they can derive solutions from multiple perspectives.  With diverse learning styles, they can understand the many voices of the stakeholders.  Well formed teams can question and learn more effectively in daily stand-ups and Sprint Reviews.

A resourceful and adaptive team spins the Scrum wheel and embraces the learning wheel to listen to their product and stakeholders effectively and efficiently.  This will raise your team from formed, to well formed.

Find the latest team tools and skills in our 4MAT for Scrum teams course.

Teams: Meet Keith.

Musing, Well Formed Teams | Posted by liz.weatherhead
Mar 22 2011

I once chaired a small leadership team, just four people.  Keith, my operations lead, was highly tuned into telling us how our ideas could or could not be implemented.  Keith had a million ways to process, but he appeared to have a  lack of caring about the people we were serving.  Keith was bottom-line results focused and preferred to take on projects alone.  As the team leader, I was concerned about Keith’s ability to collaborate and listen to all the voices on the team. Additionally, I questioned Keith’s seeming desire to take over as leader.

As a team, we took learning style assessments.  I discovered Keith’s characteristics had nothing to do with me or his lack of feelings.  It was simply an outward product of his preference to learn. Armed with this new awareness, I began to seek out Keith for decisions.  His viewpoint was juxtaposed to mine and we created a heightened creative tension. This led to problem solutions and pathways that served our organization in dynamic ways.

Keith’s strengths were testing and tinkering with how ideas could be realistically implemented.  Keith questioned the experts…were they really promoting the most efficient methods possible?  Making unilateral decisions was his preferred method to tackle problems. Keith was a hard worker and strove to make the team and organization productive and profitable.  Getting to the point and editing out “fluff” was Keith’s conversation strong point.  Keith had common sense in spades.

As a ScrumMaster, how do you manage Keith’s energy? How does his preference to work alone fit into the team mentality of the Scrum framework?  What does a coaching conversation with Keith look like?  What if you have an entire team of Keith’s?

Awareness of learning styles is essential to managing the energy and patterns of any team member.  Keith may never be thrilled to do team and small group work, but you will find better success by teaming Keith with team members who value his point of view.   Teammates with a strong voice are also important to pair with Keith.  Implementing few, but reasonable and enforceable rules around team interactions will also appeal to Keith.  Acknowledging Keith’s ability to problem solve is the best way to keep him motivated.

To build your awareness of learning styles on your team, join us for our new teams course, 4MAT for Scrum Teams.

Stories Too Big – Stories Too Small – Stories Just Right

Development | Posted by doug.shimp
Feb 23 2011

Perhaps one of the least well understood patterns by scrum teams is finding the right size for a story. A story is just a chunk of work. And finding the right size is about estimating the chunk of work.

And story is right size if it is something that can be worked on now within a sprint. Each team is different. For each team the right size of the story will vary. When a team can commit to a story they are starting to give you feedback that a story is getting closer to the right size. We use relative sizing to find what the right size for a story is. As the team does more work it will settle on a pattern that is just right. Finding the right size of a story is something the product owner does by listening to the team and figiruing our what the team can commit to.

If you only plan 2 stories into a sprint then story size is probably too big. If plan 50 stories into a sprint then you are probably decomposing too small. In both cases the assumption is that you have a typical 7 person scrum team. The product owner with the help of the team is trying to find the right size of a story. As the team and the product owner work together they will establish a flow of work. As the team does work for the product owner a just right size of a story will start to be preferred. Analysis will be controlled such that the stories tend to be just right. About 10 stories in a sprint is a good rule of thumb. We call this application of sizing “The Goldilocks Theorem”, Dan.

3) large 1) small 2) medium

too big too small just right stories

This basic pattern of sizing work has been the corner stone for every estimating system.  Names like delphi estimating or base lining are legitimate techniques but often mask the basic pattern described. People are hard wired to recognize too big, too small and just right. We simply need to leverage this innate mechanism to begin sizing stories. By leveraging this innate mechanism we will find the chunk of work that leads to “One bite at a time” and “Work from a known center”.

 

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.

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.