A Blog About Agile from Davisbase Consulting

Becoming Agile is the Davisbase Consulting blog about all things Agile. It features regular posts by our staff, whose diverse expertise and backgrounds enable us to offer fresh perspectives and insightful observations.

Check out some of our favorite entries by visiting the top posts page, and be sure to subscribe by RSS feed or email to keep up-to-date.

Tuning the Agile Team Engine

Why is Team Success so Important?

Organizations without strong teams is a like racecar driver without a car. You will go nowhere fast. Healthy, performing teams are the building blocks of a successful organization, especially one that desires to scale agile from the Team level to the Program and Portfolio levels. No matter what endeavor an organization undertakes nor how advanced the technology used is, it will either succeed or fail based on the quality of the people involved and how well they work together. The greatest challenge facing any organization is how to get people with diverse experiences; skills, opinions, beliefs and motivations working together as a cohesive unit toward a desired, common goal.

There are many techniques to assess and tune an Agile team in order to maximize their performance. This article provides a survey of techniques and ideas to improve the overall performance of your Agile team.

Become Aware of Agile Team Dysfunction and Smells

Recognize Team Dysfunction

The Five Dysfunctions of a Team by Patrick Lencioni is an excellent resource for ScrumMasters. Lencioni’s book does a great job of defining key dysfunctions teams experience and informs you as to how to recognize and address them in order to effectively remedy them.

Below is a break down of the Five Dysfunctions from wikipedia:

  • Absence of trust—unwilling to be vulnerable within the group
  • Fear of conflict—seeking artificial harmony over constructive passionate debate
  • Lack of commitment—feigning buy-in for group decisions creates ambiguity throughout the organization
  • Avoidance of accountability—ducking the responsibility to call peers on counterproductive behavior which sets low standards
  • Inattention to results—focusing on personal success, status and ego before team success

These dysfunctions impede a team’s ability to evolve to a state of high performance and keep a team in the Storming and Norming stages defined by Bruce Tuckman in the 1960s and discussed later in this article.

Become Aware of Team Smells – No, not the body odor variety.

Just like as a racecar driver is attuned to every nuance of their car, from the sounds the engines makes to the smell of its exhaust, the ScrumMaster must be aware of their Team’s nuances in order to determine if adjustments are needed.


A ‘smell’ is as an anti pattern and an indication that something isn’t working right. Below is a list of potential ‘smells’ that may surface on your Agile team. Each smell is a manifestation of one the five dysfunctions defined by Patrick Lencioni. Examples may include:

  • People working in functional silos
  • Developers not assisting Testers
  • Excessive information handoffs
  • Only the BA is in requirements discussions
  • Only a few team members few up in Retrospectives
  • Team members show up late to meetings on a regular basis.
  • People multitasking in meetings
  • Team Members hogging tasks rather than only signing up for a task if they have capacity to work on them.
  • Too much work in process (WIP) – not enough swarming
  • Tech Leads sizing work for the whole team
  • ScrumMasters assigning work to team members as opposed to team members taking ownership.
  • Etc.

Dealing With Growing Pains

As people come together to form a team, they follow a natural pattern as they learn to work together to achieve a desired goal. Paul Tuckman observed the stages of team development during the 1960s with his definition of the Forming, Storming, Norming and Performing stages. A team must pass through each stage in order to achieve the ideal state of performing. Rushing through any one stage may hinder the team’s maturity and cause it to revert back to a prior stage. The ScrumMaster should be aware of these stages so they can take the right steps to steward a team through this process.

The diagram below lists the behaviors exhibited during each stage. It may take a team approximately 2 months or so in each stage to properly mature. The goal is to achieve the Performing stage and then to monitor and adjust team behavior in order to sustain this state.

Assess Natural & Adaptive Behavioral Styles

Diversity of thought, experience and skills is essential to creating high performing teams. However, it also posses the greatest challenge to a team since each person is unique with their own behaviors, opinions and beliefs. Psychologist William Marston developed a theory that centers on the four personality traits: Dominance, Inducement, Submission and Compliance. This theory expanded upon by other psychologist who developed a personality assessment tool known as DISC. There are many personality tools available, such as Myers Briggs, but DISC has proven to accurately assess a team member’s natural and adaptive behavior styles.


Your natural style is how you behave when you are being most natural. It is your basic style and the one you adopt when you are being authentic and true to yourself. It is also the style that you revert to when under stress or pressure. Behaving in this style, however, reduces your stress and tension and is comforting. When authentic to this style you will maximize your true potential more effectively.

Your adaptive style is how you behave when you feel you are being observed or how you behave when you are aware of your behavior. This style is less natural and less authentic for you or your true tendencies and preferences. When forced to adopt to this style for too long you may become stressed and less effective.

Team members can take the DISC assessment to determine both of their behavior styles based on the following dimensions:

  • Decisive — your preference for problem solving and getting results
  • Interactive — your preference for interacting with others and showing emotion
  • Stability — your preference for pacing, persistence and steadiness
  • Cautious — your preference for procedures, standards and protocols

The output of the assessment assesses the team member across each of the following values: Aesthetic, Economic, Individualistic, Political, Altruist, Regulatory, and Theoretical. The analysis presents the best way to communicate with the individual.

Creating a DISC profile for each member of the team is a great way to learn more about each other so that we understand our different personality types and how best to communicate and interact with one another. The profiles are very enlightening to a ScrumMaster to determine why certain people on the teamwork seamlessly together and others are always at odds.



Evolve to T-Shaped Skill Sets

Identify Skill Gaps

The ScrumMaster should assess the team to determine what skill(s) is either lacking and/or is an area of growth in order to mature and evolve the team.  Once the gaps are identified, the ScrumMaster should have a conversation with each team member and their functional manager to discuss opportunities for growth and determine which skill(s) the team member is interested in and has the ability to pursue.

The next step is to incorporate the growth in these identified skills into a training plan to achieve the desired result. Fulfillment of the training plan should become part of each team member’s performance review so that the right priority and accountability is established.

Develop a Training Plan

The functional manager and team member are responsible for creating the training plan but ultimately the team member is accountable for its execution. The ScrumMaster provides guidance and an objective assessment of the results of the plan. The plan should be reviewed periodically with the team member so that the necessary assessments and adjustments are made.

The plan itself can be comprised of some of the following:

Formal Training

Formal training can take the form of in-class or online learning sessions. This is a great way to get more in-depth training regarding a skill set and most incorporate exercises that reinforce the concepts learned. The more hands-on the class is, the better since most passive learning associated with training is lost if not applied shortly after class.

Informal Training

Informal training can be as simple as conducting topic driven lunch-and-learns or participating in a Community of Practice that is pertinent to the skill needed. There are also several places on the web to register and attend free webinars.


Pairing entails bringing an experienced team member together with a less experienced one to work together in learning a new skill.

Self Study

There are a plethora of web sites, wikis and books on every subject pertinent to any desired skill set. Any self-study effort should be incorporated into the training plan.


The role of the mentor is to assist the team member on their journey since they may be more accessible than the team member’s functional manager.


Realize There is an ‘I’ in Team






The saying goes there is no ‘I’ in ‘Team’. Unfortunately this is expression is somewhat counter productive. Focusing on just the team undermines the autonomy of the individual, which demotivates the individuals that make up the team. Teamwork is essential but a ScrumMaster must not forget that a team is comprised of individuals and individuals have their own motivations and needs. A ScrumMaster should find the right balance between team autonomy, which is drives self-organization, and individual autonomy, which motives the individual to become a productive member of team.  Wikipedia defines intrinsic motivation as:

“Intrinsic motivation refers to behavior that is driven by internal rewards. In other words, the motivation to engage in a behavior arises from within the individual because it is intrinsically rewarding. This contrasts with extrinsic motivation, which involves engaging in a behavior in order to earn external rewards or avoid punishments.”

As a ScrumMaster, be cognizant of what intrinsically motivates each member of your team so that have rewarding work while working as part a team.


Conduct Retrospectives

At the end of the day, one of the most effective tools to help fine-tune your team is something you hopefully are already doing – the retrospective. This ritual is key to improving a team and evolving it to the Performing stage and keeping it there. An essential reference for effective retrospectives is Esther Derby and Diane Larsen’s book entitled Agile Retrospectives: Making Good Teams Great. If you are not conducting retrospective, it is essential to begin doing so. If you are currently doing them, then determine how you can improve them so that you maximize the benefit and keep them fresh and informative. Track the outcomes in a process improvement backlog hold the team accountable for addressing the items on this list in a progressive fashion.



Part of the ScrumMaster’s role is that of a servant leader and if we return to our analogy of the Agile Team has a high performing engine, then the ScrumMaster’s role is that of a master mechanic. Not only does the ScrumMaster need to understand how the engine works but also what tools and techniques are used to tune the engine for optimal performance. I hope that this survey of some effective Agile Team tuning techniques will inspire you to apply one or more of them to your team to see if they move the needle on performance.

Agile Field Trips

When I first learned about Agile, I took a 1-day class with my team and was given a book (which I didn’t really read) and we were off to the races.  We got the concepts, they made sense, but we had a really hard time breaking out of our old habits and making a difference in what we were doing.  My whole team hated Agile.  And so did I.  As you might have guessed, I got over it.

I remember when it happened, the getting-over-it.  It was when I saw a real Agile team in action.  I got to observe three software teams at another company for a few days and it was during that time that the lightbulb went on for me.  I got to see what a productive Standup was.  It turns out it wasn’t the ScrumMaster asking everyone for status, it was 15 minutes of everyone on the team coming together and resetting with each other – who was working on what, who needed help and where there were breakthroughs the previous day.

During the planning session, I got to see what a real environment of trust looked like.  One team came back from their tasking and told the other teams that they were going to have to drop a story from their original goal.  The teams and management took it in stride, rearranged a few things and everyone kept moving.   There was no rolling of eyes or assumptions that anyone was slacking off.

Mind.  Blown.

If you’re having trouble getting a team over the hump, think about taking them on a field trip.  It doesn’t have to last days, but get them to see a standup, a planning session or just a team in action.  Let them draw their own conclusions about what they could bring back to their own group.  You’ll be surprised how seeing this type of possibility will change some people’s outlook.

How can you find a team to observe?  Certainly ask around in your own organization.  Or ask at your local user group.  Put it out on LinkedIn or ask your coach.  Teams that are doing well love to show off how far they’ve come and help other teams get there – they really embrace the value of collaboration, not just inside their own teams!

Agile Gravy St. Louis

As you may have heard, Southern Fried Agile is putting on the very first all-agile conference, Agile Gravy, in St. Louis on April 10, 2014.  Southern Fried Agile is a non-profit group based in North Carolina.  Since 2010, SFA has been coordinating the Southern Fried Agile conference each fall and had over 400 attendees at their 4th annual event in Charlotte, NC on Friday, October 18, 2013.  Agile Gravy is their first annual event in the St. Louis market. The team is excited for the opportunity and hopes to grow the agile community in St. Louis!

The schedule is packed with many different topics from Test-Driven Development and Best Practices to Agile Game Play and Leading Agile Transformations.  You can view the full list of speakers and the schedule here.  Our very own Andy Painter is the afternoon keynote, his topic is Continuous Delivery.

You can still purchase tickets for this event and better yet, if you use this link you will receive the early bird price of $99 – that saves you $30 off the current price!  Come witness this first time event and stop by the Davisbase sponsor table for some free goodies and information.  We hope to see you there!

Scrum Team Needs Story Time With Scott

I’m always amazed at the endless characteristics of the human spirit.  There are times in our lives where people make lasting impressions even if they don’t believe that they are doing anything extraordinary at the time.  For some of us, these times come with the same frequency of the sun rising each and every morning.  For others, inspiring scenarios such as these seem to be far and few between the regular occurrences in our daily lives.  Many of us have had lasting experiences at one time or another, but rarely do we have the chance to reflect on them in the moment or observe how others around us react to the experience.






The story that you are about to read is true and it’s definitely worth telling.  Scrum teams need story time with Scott.  What?  Who is Scott?  How are Scott and Scrum connected?  Why should I care about Scott?

Well let’s just say that Scott is indeed a real person.  We work with each other on a Scrum team.  Scott actually knows that I’m writing this article with him as the main character, but he’s not really sure why I’m writing an article about him as of yet.  Maybe you’ll be able to determine the “why” as you continue to read this story.  Don’t hesitate to comment on any thoughts you may have regarding “why” and let’s help Scott with his journey toward discovery.

Anyhow, let’s get back to the story.

Scott’s a member of an initiative that’s using Scrum.  Scott’s not an immediate member of the Scrum team, which is a fancy way of saying that Scott’s works on the fringes of the Scrum team.  He’s not a developer.  He’s not a member of the quality team, but then again, he is.  We’re all really members of the quality team whether we know it or now.  Scott’s not the Scrum Master, Development Manager, Quality Assurance Manager or Architect.  He’s also not the Product Owner.  Scott doesn’t event sit in the Scrum room.  He’s not even on our floor, but all members of the team secretly know where we can find him, which now means that he’ll have to change his physical location in order to hide from us.

Scott’s knee deep in communication, collaboration, coordination and clarification activities amongst the team’s many business partners.  Our Scrum team provides him information so that he can keep the business partner wheels turning at a constant pace.

Ok, at this point you should have a fairly good idea of who Scott is, but what does all of this have to do with Scrum?  In order to do that, we’ll need to take a step back in time. Depending on your age, it may either be a big or small step back in time; yet that’s where we need to go for now.

Do you remember a time in your life when someone read your favorite story to you?  If you can’t remember the exact moment – it’s alright.  Try to remember some of the key words that you are able to associate with these memories, such as:

  • Interest
  • Excitement
  • Attentiveness
  • Adventure
  • Concentration
  • Happiness / Sadness depending on the ending of the story
  • Relaxation
  • Comfort

I could go on and on taking you down memory lane, yet by this point you really want to get along with something related to Scrum.  Do you and/or your teams associate any of the keywords above with your Scrum teams?  If so, then you’re probably a step ahead of many Scrum teams.  And, if so, how did you get any or all of the characteristics above to be part of your team?

For us, we get infusions of these characteristics from Scott from time to time.  Now, you’ll remember that Scott doesn’t sit in the team room, but he does visit us occasionally.  Scott brings a certain “joie de vie” when he enters the room.  Up to this writing, he’s had some really great stories to tell and definitely captures the attention of everyone in the room.  We’ve seen, on several occasions, where team members actively push back from their computer screens and immerse themselves in the story that Scott is telling.  Somewhere along the way, a member of the team coined the term, “Story time with Scott” and it just stuck after that.

It’s not the stories that Scott tells that are important for Scrum teams.  What is important is to actively seek and encourage your team to find their own version of Scott.  Challenge yourselves to find someone or something that breaks the routine of the day or sprint and allows folks to look at things from a different lens.

With everything that we’ve talked about up to this point, why should you care about Scott?  You may never meet Scott, yet I can guarantee that your teams definitely need characteristics of what people like Scott bring to the table.  Scrum isn’t about conforming to a prescriptive process and a little laughter and dare I say “fun” should be a part of what we do at work.   After all, we know that Scrum isn’t for everyone; it takes a certain kind of individual that wants to play in this space.  Playing in this space takes a tremendous amount of dedication, concentration and willingness to actively communicate with others.  Yet, while you’re in the throws of your sprint commitment, don’t forget about the value of story time….or any other mechanism that will help give everyone a brief pause during the daily grind.

A Manager’s Role in an Agile Organization

At the end of the day, software creation it is not about scope, budget or deadlines – It is about people. It is people that come together day after day as a cross functional, self-organizing team to produce value for the business, and it is an effective and enlightened manager that is the lynchpin in making this happen. Software projects that fail are less about the people and the process, than the leadership of the organization.

Core Scrum defines 3 roles – ScrumMaster, Product Owner and Team. The role of a People Manager is not a core scrum role and this has become a very conscious thought across all organizations on an agile journey. So where is the Manager?

The role of the manager in agile is focused on all the grey areas that surround an agile team and everywhere through out the organization.

This webinar examines the importance of the manager’s role in the software creation process and how they must effectively manage the process while acting as an effective servant leader that guides and facilitates their team to high performance.

The agenda will cover:

  • Where is the Manager in an Agile Organization?
  • What is the Manager’s role in an Agile Organization?
  • What are the Management Responsibilities in an Agile Organization?
  • What is Agile Leadership at the team level in an Agile Organization?

This event takes place at 12:00 PM EST on Thursday April 3, 2014 and is hosted by Davisbase Agile Trainer & Coach, Anu Smalley.  Sign up now!

What Kind of Agile Coach Are You?

Over the last three to five years, the Agile coaching space has seen a tremendous amount of growth as the popularity of Agile based initiatives has grown.  Coaches bring an enormous amount of both intellectual knowledge and practical application experience to the table, both of which are invaluable pieces for any organization either starting or continuing their Agile journey.   As a general observation, Agile coaches that I’ve seen in the past are extremely passionate about creating something special and will explore every possible means that will allow their teams to achieve as much success as they can.  Yet, with the best of intentions, coaches can find themselves in situations where what they have done for the last 20 years doesn’t work in the current environment that they are working in.  Therefore, as coaches, we’re constantly looking for ways to take clients to higher and higher levels.

Not that long ago, a group of us were training together in preparation for new a Agile project and I was fortunate enough to be serving as the Agile coach.  The group was still learning about each other as many members had not previously worked together up to that point.  Individuals were very cognizant about the training agenda that we were going through; yet appeared somewhat confused about what the coach would really provide.  Specifically on this topic, team members really wanted to understand what type of behaviors and characteristics that the coach would bring to the table.   One team member then asked a very important and pertinent question.  He asked, “What Kind of Agile Coach Are You”?

A question, phrased like this one was, is one of those pivotal items that need some significant thought before answering.  The challenge with this situation was that this Agile coach was standing in front of a room of twenty-five people and I didn’t exactly have the ability to call a time out before answering.  Answer the question too cautiously and you’ll appear indecisive in front of the customer.  Answer the question too aggressively and you’ll appear arrogant in front of your customer.  Yet, the question raised was an important one, which deserved discussion and dialogue.

Fortunately, during this particular time of year, the NFL (National Football League) playoffs were in full flight and people had been talking about sports all morning long.  Being a sports enthusiast myself I had been right in the mix of the football banter with other colleagues.  Luckily for us all, we had been given the ideal platform to address an extremely important question that the audience deserved an honest and candid answer to.

The platform that we elected to use would be coaching using various sports to highlight certain behaviors and characteristics.   From a coaching criteria viewpoint, the group agreed to create a grid to visually represent these behaviors and characteristics.   Our grid was broken down into three distinct areas below based on how the group perceived the coach on game day:

  • How often do we see them on camera?
  • What is their outward appearance?
  • What are their mannerisms?

The Head Football Coach

How often do we see them on camera? 

  • Continually throughout the game
  • Especially when things don’t go well.  We want to see if they’ll throw something on the group or stomp around.

What is their outward appearance?

  • Blue collar and down to earth
  • Down in the trenches

What are their mannerisms?

  • Driven
  • Goal Oriented
  • Frequent input at the entire team level


The Basketball Coach

How often do we see them on camera?

  • Continually throughout the game

What is their outward appearance?

  • Polished and business like
  • White Collar
  • Highly focused on the players

What are their mannerisms?

  • Encouraging
  • Immediate outcome based
  • Frequent input at the individual level


The Soccer Coach

How often do we see them on camera?

  • Very seldom


What is their outward appearance? 

  • Blue collar with a polished outward appearance

What are their mannerisms?

  • Thinking and evaluating
  • Periodic input at the individual level


The Tennis Coach

How often do we see them on camera?

  • Very seldom if ever


What is their outward appearance?

  • Polished
  • White collar

What are their mannerisms?

  • Focused
  • Little input (on game day) at the individual level
  • Evaluating


“Don’t be afraid to ask for permission”

At the end of this discussion, team members came full circle and still wanted to know what kind of coach I was.  At this point, I asked them if they would be willing to accept multiple coaching behaviors and characteristics.   After some further discussion the answer was “yes”; which would prove to be a very important cultural aspect that would help determine my interaction methods with the team on a go forward basis.

As coaches, we’re constantly trying to find out how we can approach and work with the team(s) that we’re interacting with.  There are and will always be barriers to consider when coaching like corporate culture, team culture and language.  Understanding these types of barriers will provide coaches with the ability to provide the best coaching to our teams.  As such we should ask ourselves, “What Kind of Agile Coach am I?”  Taking this initial view into ourselves and coupling this with the ability to ask/answer this question in front of our customers will take coaching to new levels for our customers’ benefit.

Delivery vs. Project Teams

Many organizations I work with desire to evolve their agile adoption from the Team level to the Program and Portfolio levels. One of the key challenges they encounter is how they define the lifecycle of a Team.

Most Teams are formed around projects. Once the project is initiated a team is formed to implement it. The team then progresses through Bruce Tuckman’s group development model starting with forming then progressing through storming to norming and eventually achieves the performing stage. The investment of energy expended to get a team to the performing stage is immense and may take months to achieve. Unfortunately the return on this investment is all to often cut short once the project is complete and the team is dissolved only to have its members re-assigned to new project teams and the process starts all of over again.

This is an incredibly wasteful exercise and is the organizational equivalent of an NBA team whose coaching staff spends countless hours developing the right mix of players to be their starting 5 during the regular season, only to scrap that effort by putting in a new starting 5 once the playoffs begin. It makes no sense, yet we do it time and again in our development organizations.

If we can agree that keeping high performing teams together increases the creation of value within an organization, then the next question we should ask is how do we keep them together?

The first step is to identify value streams in your organization. Below is a definition of a value stream from the Scaled Agile Framework (SAFe):

       A software value stream is the series of system definition, development and                          deployment process steps used to provide a continuous flow of value to the                        business, customer or end user. Each should be a compelling, longer-term initiative            that drives programs that ultimately differentiate an enterprise from its competitors.

The basic idea is to determine what value your projects have in common to the organization and group them into the appropriate value streams. For example, a value stream in your organization may relate to a product or suite of products or services your organization provides. Each product may have several projects throughout the year that are initiated to expand the capabilities of the offering.

Rather than form a new team around each new project initiative, consider if it is possible to have a team or teams focused on a single value stream and have the various work flow through that team. The next step is to then form a team or teams for each value stream and have these teams remain intact for the life of the value stream.

This approach optimizes the return on investment made to progress a team from the forming to performing stages by keeping them together once they have achieved the performing stage. They are able to continue to deliver value without disruption and this approach minimizes the waste incurred by teams having to go through each of the development stages again and again.

The final step is to determine what work gets done in what order within the program or portfolio. Traditionally, new projects are initiated without any awareness of the organization’s capacity. This results in too many projects in flight, which ultimately slows down the completion of any one project. You may have witnessed this first hand when implementing Agile at the team level. One of the first reactions I get from a majority of the team members is that there is no way they can be fully dedicated to this project since they are participating in five other projects. The allocation of a team member to multiple projects is a clear symptom that the organization has too much work in process. Everyone is busy but nothing is getting done.

How coarse grain work is prioritized and allocated to a value streams is key. Whichever group manages this process in the existing organization, such as the Project Management Office or Product Management team, must become more aware of the true capacity of their value streams so that the right level of work is allocated to optimize flow.

Once again I will refer to the Scaled Agile Framework that utilizes a Program Portfolio Management group to focus on an organization’s strategy and investment funding at the Portfolio level and Product Management group that works at the Program level to define and prioritize the work that gets completed in each value stream. The Product Management group must be aware of the capacity of each value stream so that the right amount of work is scheduled for a release. This ensures that the teams working within a value stream are focused only on the work within that stream and not bouncing between multiple initiatives. Furthermore, the teams stay intact so that they can realize the benefits of a sustainable delivery focused team vs. the more temporal and disruptive project focused team. The diagram below illustrates a simple example of aligning an agile team or teams to each value stream pertinent to the organization’s business. The Product Management group or PMO, Enterprise Architecture and Infrastructure groups support and span each of the value streams. Project work then flows across one or more value streams. The teams assigned to a value stream only work on items that pertain to that value stream, regardless of the project.


Agile Needs You to Get it Out of Your Head

It wasn’t that long ago that I had a chance to work with a group of individuals who were beginning their very first Agile journey.  Standing in front of the room, I took some time to observe the mannerisms of individuals as they collected their coffee and crumpets and began to settle down into their respective chairs.  Having just met many of the individuals a few moments earlier, I made the assumption that what I was observing was a collection of uncertainty, excitement, anxiousness, trepidation and the fear of the unknown.  After all, many of these individuals were meeting each other for the very first time; and this brings a certain amount of anxiety in almost any social setting.

This group of people was going to be part of a new project and came from a wide variety of backgrounds.  Listening to the introductions, I learned that they were coming together to “Do Agile” as this was the buzz term that was being used throughout their organization.  I heard this expression used by multiple people during the introductions and placed the phrase to the back burner for the time being.  Other companies that I had worked with in the past were also “Doing Agile” and I knew that it could take some time to move in a direction where they were not “Doing Agile”, but rather “Being Agile”.  However, getting into this conversation too early on the first day had the strong likelihood of being a deterrent and I wasn’t quite ready to take them there yet.

We all had a chance to learn a little more about each other as the introductions continued with the new work group.  The new work group was to be made up of both brand new people to the organization as well as individuals who had been with the organization for years.  What’s more, some of the individuals had worked on a predecessor project and had amassed an enormous amount of intellectual capital.  They were analysts and subject matter experts with a knowledge base that was both deep and wide in the particular field of study.

It wasn’t long after the meeting started that a few individuals in the room whom I would place into the “skeptics” category came forth with some very interesting statements.  Their paraphrased statements were the following:

  1. I’ve heard that our new Agile team has to write these things called User Stories.  What’s the point?  We already have our entire project requirements spelled out in our format.  This is going to be a huge waste of time.
  2. We know what we need.  It’s all in the requirement documents and it’s right up here (one individual pointing to their head). 

Oh, this was going to be a turning point in the day; yet many people in the room didn’t yet realize just how significant it would be.

Not more than a millisecond after the last statement was articulated, all eyes turned to the front of the room in order to see what the official response would be.  After all, up to this point, I was there to help them “Do Agile” and the gauntlet had definitely been thrown down for everyone to see and hear.   That gauntlet, more like a very heavy anvil, made a resounding thud as the crowd of onlookers waited anxiously to see if I could hit that one back over the net.  Yes, yes, yes indeed, what would be the response?

Thoughtfully, I rubbed my chin as I took time for what’s known as the collective pause and said, “Agile needs you to get it out of your head”.

What they didn’t know then, but most certainly embrace now is how important this step is in the creation and formation of any Agile team.  The response given wasn’t just about User Stories, but we’ll stay with the User Story example for now.  Being that this was a new group, further explanation was definitely expected and warranted.  I had a few thoughts to share with the group.

First, after our initial introductions, it was very apparent that this group had a very wide range of expertise in the project at hand.   Next, through discussions in the room, we all learned that the requirements had not changed much in the last 6 to 9 months.   This was an interesting observation for sure.  Then we learned that not everyone in the room had even seen these requirements up to this point and I sensed that the group wasn’t ready for the question whether or not those who had seen them truly understood what they meant.  Finally, while the requirement format could be considered a very standard version, I sensed that the team was open to another approach.

The interesting caveat to the preceding discussion was not only the items that the people listed, but also how the individuals began to resonate with each other.  This discussion was quickly taking a group of individuals and forming them into what would eventually become a collective team.   They were beginning to assemble and encouraged to express themselves for topics that resonated with them deeply.  This was the hottest topic of the day.

Well let’s fast-forward about 3-4 months and summarize where this discussion eventually took this team; especially since their executive sponsors didn’t give them an option not to go with User Stories.   A quick synopsis of their collective experiences are found below:

  1. Initially everyone participated in the User Story creation process.  Everyone.  Not just a few select individuals, everyone on the team.  Paraphrasing for them, they found this experience:  Brought them a deeper understanding of what was to be built; started to bring them together as an autonomous team since everyone had a stake in what was written; provided a non-biased forum for qualifying questions and answers; allowed for team based flexibility and avoided a historical feeling that they had to conform to the pre-dictated requirement template; helped to provide a baseline of understanding for everyone; provided everyone with a better “feeling for purpose” in terms of how their collective input would help everyone succeed
  2. Not surprisingly, some of the initial skeptics also discovered that what they historically thought was “good enough” wasn’t really that good to begin with.
  3. They found that requirements needed further elaboration for the benefit of everyone.
  4. They discovered better requirements for the customer’s benefit.
  5. They made comments and statements like, “I hadn’t really thought of that”; which only gave the team a better chance of success.
  6. They learned, they grew and they turned into a team from an initial gathering of individuals.

Agile does need you to get it out of your head.  While this story has heavy undertones on User Stories, this mindset and the statement is not just for User Stories.  It’s for everything that we do literally and figuratively in the Agile community.  It’s for growth.  It’s for change.  It’s for the willingness and desire to continually evolve.  Enjoy your own Agile journey and keep pushing the boundaries for what Agility truly has to offer!

Agile Open Northwest – A Great Un-Conference

If you’ve never been to an Open Space event before, please go check one out.  I was first exposed to Open Space at a Scrum Gathering a few years ago and fell in love – they had 2.5 days of traditional conference and saved the last ½ day for what they called the “Un-conference”.  Basically nothing is scheduled in advance; instead, anyone attending can pick a topic and post a session.  You don’t even have to know anything about the topic – you could pitch a session and tell everyone that you’re just looking for ideas – and people will show up to give you ideas – as they say in Open Space, the right people will show up.

Now, instead of a ½ day of this, imagine an entire Agile conference based solely on this idea.  Enter Agile Open Northwest.  I just got back from attending and was so reinvigorated with new ideas and quite frankly, sad to leave.  As someone at the conference put it on the last day “It feels like we’re leaving summer camp”.

I got to try out Lean Coffee – a fantastic concept that I immediately implemented with a client as an alternative to lunch and learns.

Think Paired Programming is interesting?  Try Mob Programming!  Instead of two developers at one computer, try 7 or 8 at one computer.  There are some teams doing this at Microsoft and one team claims a 10x productivity gain.  Holy cow!

Want to try something fun?  Try Presentation Karaoke.  Put together the most random slide deck ever and a list of also random topics (you can make them Agile specific if you’d like).  Then a volunteer picks a topic and the audience picks a slide number on which that person will start.  Then the volunteer gives a presentation on the selected topic while attempting to tie in random slides that she’s never in her life seen before?  Talk about hilarious!

There were lots of great and more down-to-earth sessions too: Kanban vs Scrum, Managers’ roles in Agile,  Agile resumes and interviews, Culture Refactoring…the list goes on.  If you can’t find a local Open Space Conference, take a sneak peak at the session notes and get that brain turning on some new ideas!  And if you want to join this group next year, keep a close look out – they sold out in less than a day this year!

Writing Agile Contracts

Working with a third party organization as either a customer or as a service provider is challenging and fraught with risk. There are several options for contract types spanning from Fixed Price to Time and Materials. For those organizations using Agile internally to deliver a solution or service, or for those that want to receive a solution using an Agile approach, the question becomes what contract type is best suited for Agile related projects?

The Writing Agile Contracts webinar addresses this question by discussing why Agile is used for software development, how it effectively manages risk, what the various contract types are and which ones are best suited to support to support an Agile approach.  The agenda will cover:

  • Why use Agile
  • Agile Specific Challenges
  • How Agile Manages Risk
  • Acquisition Approach for Agile
  • Contract Features
  • Writing Agile Contracts
Join our very own Agile Coach & Trainer, Tom Wessel, for this informative webinar on Thursday March  6, 2014 at 12:00 PM EST.  It’s FREE – so sign up now!