Agile Adoption

, ,

Non-Agile Scrum

You may have adopted Scrum, and you may be following its rules quite exceptionally. Daily Scrums(stand-ups) take no longer than 15 minutes. At the end of Sprint Planning, you may have a solid plan for the upcoming Sprint including tasks, test cases…the whole 9 yards. You have a demo at the end of the Sprint and even a retrospective. Hurray! You’re agile!

Or are you?

Why do I keep hearing people say things like “I will never do agile again!”, or “I was on an agile team, it was horrible!”?

Hearing comments like these are very common. What’s happening here?

I think there are two things happening.

Scrum as a Silver Bullet

Companies typically implement Scrum because they are having significant problems with delivery, quality, or budget which makes for very unhappy customers and loss of revenue.

Why Scrum? Probably because they hear all the success stories from their peers…and it is the most popular agile framework after all.

The fallacy is that Scrum will “solve” your delivery, quality, and budget problems. That is not true…it will shed light on “why” there are delivery, quality and budget problems. It could be inadequate skills, too many hand-offs, too much bureaucracy, etc. These types of things would be the impediments that Scrum-ists talk so much about that need to be removed.

If you implement Scrum but do not remove the impediments it exposes, you aren’t really “doing” Scrum.

Non-Agile Scrum

Scrum is an agile framework, but all agile is not Scrum. It’s the same thing as saying that macaroni is a noodle, but not all noodles are macaroni. There are lots of agile frameworks, and Scrum is one of them.

Almost 100% of the time, when I talk to leaders and they say “we’re doing agile”, what they really mean is “we’re doing Scrum”.

The reason I think that this is important is that if you don’t make that distinction, you may miss out on what’s really important, the principles and values of agile.

Agile says nothing of 2-week Sprints, Sprint Planning, a Product Owner, a Scrum Master, etc. Nothing. However, the theory is that you follow Scrum, you are getting a great start on being agile.

Many teams will implement Scrum by implementing the roles, events, and artifacts. However, if they don’t understand agile, they may miss the point and end up no better than when they started.

When Scrum is implemented without an understanding of agile, and with the idea that Scrum in and of itself will solve every problem, you end up with non-agile Scrum. You may follow all the “rules”, but if you follow them in a prescriptive way, you are missing the point.

Agile Scrum

In my view, to have a truly agile implementation of Scrum (or any agile method), you need the following:

Self-organizing, cross-functional, empowered teams

This is indeed the most difficult goal to achieve. However, I believe this is the cornerstone of any agile transition. Leadership must change from a command-and-control perspective to one of support and empowerment of the teams. Since the teams are the ones who know best how to deliver, they should be allowed to do just that.

This does not mean that the team adopts the “wild west” style with no constraints. On the contrary, leadership provides those boundaries, and then the team will do anything necessary within those boundaries to deliver the best product possible. An example of some boundaries that I’ve seen are acceptable:

  • Use TFS for code management.
  • The team cannot spend more than $300 on software without approval.
  • The screens must be constructed adhering to our company’s style guide.
  • Don’t introduce new open source libraries, tools, systems, etc. without checking first if we already have something similar available. If you need to include a new open source item, make sure to add it to the corporate development wiki so others can learn about it.
  • Since we work with PII, no production data will be allowed in development environments. If it’s absolutely necessary to work with PII, the data must be de-identified.
  • All code must work on Edge, IE 11, the latest version of Chrome, Safari, and Firefox.
  • Make sure your code is tested using some kind of automated framework.

I think these boundaries are very reasonable. The team still has quite a bit of latitude to be creative. These boundaries not only have impact on the team itself, but also all the other teams.

On the Non-Agile Scrum Teams, I’ve seen boundaries such as these:

  • Every team will have a physical board with the columns “To-Do”, “In Progress”, “Done”.
  • Every team will write every requirement in the user story format “As a __ I want to __ so that __”.
  • Every team will perform code reviews Friday afternoon at 2 PM.
  • Each developer will create a design document before they code. They must review this document with the architect before coding begins.
  • Each team will schedule their planning session for no less than 8 hours.
  • Each team must post their retrospective notes on the Sharepoint site.

Hopefully it’s obvious that these kinds of “rules” take the wind out the team’s sails and kills any hope of creativity. These rules are somewhat arbitrary and ultimately if your team has rules such as these and are doing Scrum, you’re not doing it right. Understandably this is not a problem with the team. It’s a problem with leadership not understanding the concepts of self-organizing teams and empowerment


If you find that your team is not able to deliver any working software at the end of a Sprint without waiting on another team to perform a task, you most likely need to rethink how the team is formed.  Dependencies and hand-offs kill team productivity, predictability, and morale.  Here’s a great read on options to structuring teams – Feature Teams

Prioritized Product Backlog

This one appears to be pretty straight forward.  However, it surprisingly is not very common.  The Product Backlog is what anchors the team.  This describes the software that the team must deliver.  If there is not a clear Product Backlog, the team has idea what to deliver, and chaos ensues.

Below are the attributes of a well formed Product Backlog


The Product Backlog contains items that are valuable to the customer.  This does not include technical tasks.  Technical tasks are included in the Sprint Backlog (a topic for another post).  There is a tendency to include technical tasks in the Product Backlog.  When this happens there is no clear understanding or traceability as to what is actually important to the customer.


The Product Backlog must be available for anyone and everyone to see.  There should never be any surprises.  During the Sprint Planning session, the team should have already have pretty good idea of what’s coming up.

Consistently and Frequently Maintained

The Product Owner and the team must consistently maintain and refine the Product Backlog (it’s mentioned in the Scrum Guide as “Product Backlog Refinement).  It must be ensured that the team knows exactly what the next most important item is to work on.  Refinement includes adding additional detail when necessary, adding/refining estimates, and ordering.

Exists at All Levels

There should be some definition of “valuable deliverables” starting from the corporate vision.  Now, at the higher levels in the organization, it isn’t called a “Product Backlog”, but it really serves the same purpose.  You may have a Product Roadmap, Product (or Project) Portfolio, etc.  You get the idea.  What the team works from is the “Product Backlog”.  There typically is “line of sight” from every item in the Product Backlog all the way through the Portfolio or Product Roadmap.  

“What” exists at all levels is dependent on the size and complexity of your company.  Some companies may only have a set of Product Backlogs at the team level. Other companies may have a complex set of roadmaps and portfolios.  The point is that they should exist where appropriate and there should be traceability all the way to the Product Backlog item.

One Product Backlog Per Team

Quite frequently I see multiple Product Backlogs per team.  They may have a “product” Product Backlog, a “bug” Product Backlog, a “small requests” Product Backlog, etc.  That causes confusion for the team.  How does the team know what is next if there are multiple Product Backlogs?  They don’t.  


If you’ve been doing Scrum for a while and aren’t seeing the benefits, take a look at your teams and your Product Backlog.  Are the teams self-organizing, cross functional and empowered?  Can they deliver working software to the customer without depending on other teams?  Is there a Product Backlog?  Is it actively maintained?  Is there only one Product Backlog?  If you answered no to any of those questions, then there’s work to do!

This stuff is easy conceptually but hard to implement.  If you’d like help making your Scrum more agile, please feel free to contact us here.  



Press: Agile Implementation

Agile implementation trends have changed, as we inspect and adapt.

I was recently interviewed for an article in the Midlands Business Journal’s technology section as a contributor to their technology trends overview.  Here are some snippets from that conversation:

MBJ: What do you think our business-owner readers should most know in the 2016 version of this annual section, as it relates to technologies or industry developments of interest?

In the past during Agile implementation, companies were more apt to start with one Agile methodology and then later experiment by adding pieces of other methodologies.  As Agile becomes more understood as a set of values and principles vs just a process or set of processes, we see a trend toward mixing Agile methodologies from the beginning of an initiative.  

At One80 Services, we see a lot of companies begin their Agile journey with perhaps a basic Scrum framework, incorporating aspects of Kanban and XP into their process right away, rather than waiting a year or more to experiment with combined methodologies.

It’s encouraging to see this trend, as people become more and more familiar with the basic principles and values that Agile exists to sustain.

MBJ: What are some examples of memorable current or recently-completed projects or initiatives your team has taken on, which illustrate some of the aforementioned technologies, approaches to solutions, or broad industry developments?

One80 Services is currently working with several clients in highly competitive industries. Each client is hoping to complete a number of projects in the next 12 to 18 months in order to satisfy customer demand. The projects address a range of clients goals including project visibility, improving ROI, strategic planning, capacity planning, collaboration and accountability, and others. 

Agile puts individuals and interactions above processes and tools – meaning that how things are working for you is always more important than which process you choose. We customize solutions to each client, and in some cases even to each team. 

This means that in one company, we may have several different teams implementing different pieces of varying methodologies. One80’s clients are delighted and often surprised by the flexibility that exists within an Agile framework.

MBJ: What would you describe as the biggest 2 to 3 changes in the 6 months to a year, as it relates to some of the aforementioned products, solutions, and approaches?

As mentioned previously, One80 Services has been working with clients on multi-methodology approaches from the beginning of their Agile implementation.  This is a change from how we and others in our industry would previously implement Agile. Rather than teaching a course about pure Scrum, we now go in and show a mix of methodologies that would work best for each client’s specific needs.  People are really open to using pieces of several methodologies together when they see how well it fits their situation. 

Coming at Agile training from this angle makes it imperative to begin with a conversation. It’s really important to understand the dynamics of the organization and the projects involved – how the teams are formed, what they are focused on, and what challenges they face – before a process is created.

At One80 Services we call this an Agile Kickstart. It’s a conversation followed by training and backed by coaching. This seems to be a magic potion for Agile success.

Really understanding the needs of the company, the team, and the customer before an Agile implementation is key.   Many Agile failures are caused by a lack of understanding or upfront planning.

MBJ: What are the implications of the changes highlighted in the preceding question for our employer-readers?

The competitive edge of Agile development has been proven over and over again.  A willingness to blend methodologies to create the best possible process for your project is the best way to achieve Agile success.  

You can achieve improvement in a variety of areas such as better, empowered, self-organizing teams; a greater focus on delivering value to your customers; faster project delivery times; and improved overall company culture.

If your outsource partner doesn’t use Agile, consider contacting One80 to see how our expertise can help your company to achieve its goals.

Contact us today.

, ,

Plan Your Agile Training

When it comes to Agile training, there are a limitless number of options.  It can be a bit overwhelming to decide who should be trained, what type of training they will need, and when to begin.

I’m going to list a few training options here in this blog post, but I want to start by saying that One80 Services exists because we recognized the need for customized training and individualized coaching.  We begin every contract with a conversation, to ensure your training will meet the needs of your team or organization.


Reducing Silos

The first step in reducing silos is to ensure training occurs on a cross-functional team.  Simply sending a few “key members” of a team for training without realizing that every member of an Agile team is a “key member” can slow or even block your transition to Agile. 


Basic Agile Training

Basic Agile training creates a foundation on which to build, and goes a long way in answering the “why” behind the roles, artifacts, and events which are included in many Agile methodologies.

Advanced Agile Training

Advanced Agile training is for those who have already begun their Agile journey and are ready to figure out some of the more complex solutions and methods. 

Targeted Deep Dives

Targeted deep dives are for teams who want to improve in one area.  For example, teams who want to improve their user story writing techniques, story sizing, metrics, or improve their meeting facilitation skills.

Agile Leadership Training

Agile Leadership training helps anyone in a leadership role – from CEO to ScrumMaster – understand how leadership changes when an organization becomes Agile.

This is not a “choose one” scenario.  

Depending on your needs, we may combine one day of basic Agile training with one day of advanced Agile training, followed by one day of deep dives into relevant topics or skills.

Maybe what you need is targeted leadership training, so we’d spend a half day on basic Agile training, then move on to Agile leadership training including facilitation, team structure, and metrics.

You may have no idea where to start – that’s okay. Learning about teams and determining training needs is our speciality.

It all starts with a conversation. 


Agile training can occur at the start of a project, in the middle, or even toward the end.

“Lost time” in training is a common and valid concern.  We like to remind people that the time you spend in training is quickly made up by the improvements made to your process.  

It’s also relevant to point out that in our workshops, a portion of our training is often spent working on your actual project.  For example: A three day workshop may involve 1.5 days of courseware and 1.5 days of writing your user stories and grooming your backlog.

We don’t like waste – we make the most out of the time we spend with you to ensure we’re not wasting your time or ours.


Typically, we come to you and teach on-site at your location. If your site doesn’t have space available for training, we will provide a location for our course.


There is a method to our madness.

We do provide pre-packaged courses for companies who know exactly what they need.

But in our 20+ years of experience, a customized approach works best for most teams.

We have seen pre-packaged courses leave teams with questions and a lack of solutions. Blending our courses together to create customized learning for each client results in teams leaving us with solutions to implement immediately, as opposed to leaving teams with a few days of book learning.


Much of the “how” depends on your organization, team, and project needs.  

Ideally, our courses are designed for 10-20 people.

  • The minimum size would simply be due to our belief in teaching cross functional teams. Ensuring that everyone is on the same page from the beginning. Depending on team size, potentially training more than one team per course.
  • The maximum size would be due to our desire to enable personal contact and interaction with each person in our course. Group interaction improves with smaller class sizes.

That said, we’ve taught in rooms of 100+ and we’ve worked directly with individual learners.  It really is all about your individual needs.

The best first step is to give us a call.

Do you want to know more about Agile implementation strategies?  Check out our free guide here.


, ,

Custom Software: Products vs Projects

Custom Software: Products vs Projects: Making a shift in technology projects and teams that focus on products rather that projects can be a seismic shift.

Stop thinking in terms of technology projects and begin the shift towards product thinking.

Many companies kick off individual projects with specific goals, timelines, budgets and resources.  These teams are tasked with a singular focus – clear the backlog and finish the project.  They rely heavily on the Product Owner to work with the stakeholders to determine features and priority.  They trust that the Product Owner is making the right decisions, and why should they ever question the Product Owner?  Scrum indicates that the Product Owner is responsible for the backlog and that the team is responsible or the execution.

Sometimes this is referred to as: Product Owner controls the ‘What’ and the Team controls the ‘How’.

A project is a planned set of interrelated tasks to be executed over a fixed period and within certain cost and other limitations.

This thinking is quickly becoming a limiting factor of organizations that are in highly competitive markets or industries.  Companies are finding that thinking in terms of a bunch of horizontal projects instead of vertical products is hindering their ability to adjust to ever shifting customer demands and to drive innovation.

Individual project teams are normally chartered to work set of deliverables.  Often these teams work in a limited vacuum blissfully unaware of other projects or company objectives.  This approach creates silos that makes it difficult to track and coordinate dependencies.  These silos generate gaps in knowledge, skills, and architecture platforms across the organization making it difficult for companies to shift project between teams without huge retooling costs.

The business dictionary has an interesting definition for product under it’s marketing category:

A product is a good or service that most closely meets the requirements of a particular market and yields enough profit to justify its continued existence. 

Building a product focused company required a shift in strategic and tactical thinking across the organization.  Companies must begin to empower teams to build products and services that meet current customer demand.  Teams must be allowed to shift priorities and to begin to innovate to drive customer retention and acquisition.  

software that allows them to identify what customer really want, and will retain and attract new customers, what they are will they will pay for.

Allowing a team to become Product focused required change in team dynamics.  The Team and Product Owner must begin to develop tools and approaches to developing software that allows them to identify what customer really want, and will retain and attract new customers, what they are will they will pay for.  Only when a company makes a shift in this thinking can they start to leverage the software to build a completive advantage.

Benefits to product focus:

  • Focus on Customer
  • System Scalability – efficiency of scale (services, web components, hardware…)
  • Consistency 
  • Quality
  • Modern software development practice
  • Building a better, more innovative product
  • Understand the customer – likes and dislikes, needs, wants, what they are willing to pay for, nice to haves, must haves…

Reach out to One80 to Ask us how we can help you make a shift to a product culture or for your Custom Software Development needs.

Going Agile Can Be Scary: Chapter Two

Risk is Scary…

More than a decade after my own transition to Agile and after having the privilege of watching other teams make their transitions to Agile as well – I have realized how scary it can be to take that first step into Agile development.

Why? Because Agile transitions typically occur in a moment of crisis or upheaval.

People reach out for something to help them out of their chaos. Agile typically arrives at a time when teams are over worked, stressed out, and pretty much struggling just to maintain their basic requirements. Taking time out of an already over-burdened schedule to learn something new seems like a risky endeavor.

Another thing we see: Agile is sometimes adopted at the beginning of a huge new project when process management becomes critical. Starting a huge new project is stressful, and applying a new methodology can feel like you’re only adding to your pile of stress.

A change in leadership can also bring a change in methodology. An organization acclimating to new leadership wonders how much things will change when they are asked to adopt Agile. It’s stressful to not know what the future holds.

Very rarely will I see a successful, productive, happy, thriving waterfall shop make the choice to go Agile.

When you decide to apply a new methodology – a whole new process in many cases – during a time when you’re already stressed out, that can feel like a risk.

Fear Slowly Fades…

stepsAgile adoption is a step process. First you learn the most basic aspects of Agile and your chosen methodology, and then you begin applying them.

You don’t need to be an Agile expert to begin.

In our Agile Foundations course, for example, we begin by teaching the basics of Agile – which are really only a set of principles and values. (“Agile” itself is not a process to follow.)

Next, we quickly go over a few of the most common Agile methodologies such as Scrum, XP, and Kanban.

We walk you through the beginning steps of your chosen methodology, and engage teams as they begin applying what they’ve learned to their own work load.

Before anyone realizes that they’re Agile, they’ve begun!

It’s a lot less painful than most people anticipate it to be.

But that first step? Well, that first step can be scary.

It’s less scary when you’re moving forward with experienced trainers and coaches. Call us today to discuss taking your first step. You’re going to ace this! We’ll show you how.

Talk to Us Today

Going Agile Can Be Scary: Chapter One


I vividly remember the first time I was introduced to Agile. I was working for Intuit at the time, building a new piece of finance software. The project was on schedule, but only because we were all working 12 hour days, and working 7 days per week.

working lateThe people I worked with – all great people – and I rarely spoke about anything but our project. When we left the office, it was to go home, see our families for a bit, then sit back down at a computer and continue working.

In hindsight, I suppose it felt a bit like treading water with a weight strapped to one foot and the other foot tied to the people I was working with. (When you take an hour on Sunday afternoon to go to the park with your kids and you spend the whole time on the phone putting out fires – you begin to understand what I mean by this.)

One day, our Project Manager (PM) walked into the conference room and plunked down a book. “We are doing Scrum.”, he announced.

We looked up with bleary eyes, half-ignoring him, waiting to be excused so we could go back to our desks and continue our daily grind.

PM said, “I have one of these books for each of you. I’ve highlighted the chapters I want you to read – do it today, because we’re starting this tomorrow.”

Our responses varied from hostility to disinterest to what could best be described as numb capitulation.  (Some of us had lost all of our fight by this time.  Any hope for “greatness” had been worn down by investing countless hours just to squeak by as “okay”.)

I’ll go ahead and admit that I was one of the people who responded with hostility.

We were barely able to get by as it was, and now PM wanted us to read some book and learn new terminology for things that already had perfectly good names?  (I didn’t understand at the time that test cases and user stories were actually different.)

The Agile Manifesto just about made my head explode.  “Responding to change over following a plan?  Now we’re going to build this massive product without a plan?!”

Honestly I thought it was the stupidest thing I’d ever been told to do.


We followed our PM into the Scrum process, slowly acclimating to the Agile principles and values.

I can’t really say this was something we embraced – it was more of a surrender at first.  Capitulating to the fact that we weren’t in charge, and accepting that we’d probably fail because we stopped working hard and started marching to a whole new tune.

Honestly at times I felt like Fred Flintstone walking into The Royal Order of the Water Buffalo.


One day, maybe even just a few weeks into our Agile journey, I looked up and realized that we were on schedule.  We were done at 4pm – ready to go home, and we were killing that extra hour by meeting for a beer or appetizers, talking, laughing, and bonding as a team.

These amazing, smart, funny people I worked with – they were my team now. My friends. We actually had time and bandwidth left over at the end of our work day to unwind and enjoy each other as individuals.

Our project drew attention from the Intuit offices in California as people saw our progress.  They wanted to know what we had done to achieve greatness.

And Agile grew.


I will never again work on a development project without implementing some form of Agile development.




[continue to chapter two]

Talk to Us Today

Using Agile to Untangle

You may already have a good idea what Agile Training and Agile Coaching entail.  But the term Agile Transition or Agile Transformation may seem vague or daunting.  Allow me to explain what One80 Services does during an Agile transition:

The short answer:  

We improve development processes which reduce waste, provide visibility, and increase time to market.

The long answer:

Many times development processes become tangled, which reduces time to market and frustrates leadership, teams, and customers.  

Our purposeAgile Training, Agile Coaching, Agile Transitions

Untangling development processes sometimes feels a bit like untangling a group of necklaces, because there is never just one chain we’re working on.  There are many different roles involved, many different steps involved, and often many complex dependencies or requirements involved.  None of them can be broken or ignored, so it’s a delicate task when they become tangled.

Agile Training, Agile Coaching, Agile TransitionsOur process

At the beginning of an Agile transition, we get a nice long look at a client’s current processes and projects, and identify a few very simple moves we need to make.  These moves are communicated in a way that builds knowledge and confidence.

Unlike untangling a necklace, untangling business processes requires more than one set of hands.

We all need to understand the problem, share a solution, and work together in order to succeed.

Our plan

Many Agile transition companies offer packages that are pre-made solutions for clients to choose from, depending on where they are in their Agile journey.

One80 Services very purposefully does not do this.

Agile Training, Agile Coaching, Agile TransitionsWe could give you a pre-made six week package, dump a bunch of Agile information on your desk, and wish you luck.

But you’d be left with an instruction manual and a tangle, as well as whatever issues led to the tangle forming in the first place.

(Note:  Every company has different needs.   This is why we also offer courses designed to provide targeted learning to those who are looking for just a little help when it comes to one or more aspects of their Agile transition.)

When we come in to help, it’s our goal to study your situation, present solutions to you, and then together with you, work to untangle it.  As we untangle, we create new processes – with you – that will prevent new issues from forming in the future.

Agile KickstartOur Agile Kickstart program is the closest we come to an “Agile package”.

During an Agile Kickstart with One80 Services, we begin by sitting down with you and taking a look at your current situation, along with where you hope to be when we’re done.

Once we’ve had a good look at your situation, we design a plan to untangle it.

We work with you to implement that plan and we stay long enough to ensure your success.

Agile Training, Agile Coaching, Agile Transitions

Still confused?  

Ha!  I don’t blame you.

When something important becomes tangled, it’s overwhelming at times.

Give us a call or send us an email.

You can reach me personally by email stacy@one80agiletraining.com

 If you’re in the Omaha area, we can even meet for a coffee and start there.

I promise your tangle is not something that can’t be undone.

Talk to Us Today


TrustI’ve been thinking a lot lately about what makes Agile work, and what types of things make Agile fail.

I like to strip things down to their smallest, most basic point. When I do this with Agile, I keep coming back to trust.

Many times Agile fails because leadership fails to trust the team. Or because team members fail to trust leadership. Sometimes it’s because team members and/or leadership fail to trust the chosen processes. Now and then it’s because team members fail to trust each other.

When Agile works, it’s because the members of the team trust each other. Leadership trusts the team. Everyone trusts the processes.

I do not think that Agile is such a difficult thing for people to learn. Agile is awesome because it is such a simple, easy concept.

I do, however, know that lack of trust can be a huge barrier to overcome.

I’ve worked with people who don’t trust. I can see them working against the team, reaching for their own goals, making assumptions that the team will turn on them if they aren’t somehow protected.

These are people who hoard responsibilities and avoid visibility. They chafe at requests for communication, and have a difficult time seeing the team as a unit with a shared goal, rather than as a group of individuals each working independently toward their own benefit.

I’ve also worked with people who have no problem trusting. People who gladly collaborate and who see the team’s successes as something shared, which everyone owns equally.

Sometimes it’s a personal thing, where an individual just can’t trust anyone – in any setting.

Often, however, it’s due to a culture of distrust in the business environment.


We know that “culture” is a common barrier to Agile adoption. Cultures in the past – cultures which I feel are antiquated and outdated – have created environments where leadership must oversee every aspect of productivity. Where team members must account individually for their contribution.

That type of antiquated culture breeds distrust, and a lack of trust impedes a lot of other important aspects of Agile, such as visibility and communication.

If you want to adopt Agile, the first step is addressing your culture. Take a good hard look at the trust in your organization.

Gone are the days when each person stood alone on their own pile of achievements.

Gone are the days when a success was owned by one person who was fast enough, sneaky enough, or powerful enough to put their name at the top.

Gone are the days when developers had to be monitored and babysat (usually by someone who had no idea what they were working on or how to tell if they were actually producing anything of value).

Gone are the days when we had to worry that if we didn’t hoard our tasks, someone else would step in and take them, getting that promotion or accolade.

Today, we work in teams.  Each success belongs to a group of people.  (The team may choose to high-five one person who came through in a big way, but the “win” belongs to the team as a whole.)

Today, tasks flow freely through a group and you trust the person next to you to share your goals.

Today, visibility and communication have improved to a point where leadership no longer needs to bear down on team members in order to have an idea of where a project is in its development cycle.

Today, we trust our team members to self-organize, to create their own processes and choose their own tools.Trust is such a simple little word. We all know what it means, and I think we’d all like to do it.

The trick is identifying how your current culture – your processes, your tools, your relationships, your organizational hierarchy, and even the physical layout of your office space – creates distrust.

I am 100% convinced that Agile can work anywhere.

But without trust, it’s going to be a very difficult and painful process.

Talk to Us Today




Do you really need a Product Owner?

I recently was visiting with a potential client about the need for a Product Owner.  They asked: “How much time will the person assigned as Product Owner need to dedicate to this project?”

This is a very common question that we get from clients. The answer I give is always the same:  How important is this project to your organization?”

The response is almost always the same:  “This project is part of our strategic objectives and it is crucial to the company’s success, but we can’t spare a Product Owner for that much time.”

This is where things get interesting.

If a project is critical to your organization in any way, you must provide a dedicated Product Owner.

If you can not provide a Product Owner, your project is doomed for failure.

How can you not dedicate someone to work with the team to ensure that it delivers that highest values features, to inspect and adapt during the course of delivery? Why would you not want someone working with the team to help them understand each piece of functionality from the perspective of the users?


Why would you not want a Product Owner to learn about the new technology, to learn the advantages, disadvantages, and conceptually how all the pieces work together? Why would you not want a Product Owner to learn to communicate with the team as well as outside stakeholders?

Why would you not want the project to be a success?

Let’s state this in another way:

  • confused-faceYou would never plan a wedding by contacting a wedding planner, provide a few requirements, and then just show up on the big day.
  • You would never build a house by just approving architectural diagrams without doing continuous walk-thrus during the building process.
  • You would never trust a financial adviser to ‘get you to your retirement’ without constant planning sessions to review your needs, goals, and priorities.

No matter how much effort you take in creating a top notch, high performing, self-organized team, they will only be as successful as the quality of the Product Owner. Even the best teams need to understand the value stream of an organization. They need someone to help keep them on the right path. If left to their own devises, the team will build what they THINK is important rather than building something they KNOW is important.  This will most certainly not provide items of the highest value. Priorities shift, requirements change, objectives change, customers change – the team needs someone to help them understand all of this.

The company needs someone to protect their investment

– that is the role of the Product Owner.



To increase the effectiveness of your Product Owners, check out our training course, Scrum Master & Product Owner. Schedule a course for your organization now!

Talk to Us Today

Scrum Masters-Learning the Mastery of Scrum

Learning to be a good Scrum Master is hard, but how does a new Scrum Master learn the the mastery of Scrum?

I had it easy. When I learned, I had an awesome team. They were open, engaged, and always wanting to improve. The Product Owner was awesome-again, open and engaged. The thing they all had in common was that they wanted to be better and they wanted to learn Scrum. I was one of group that introduced Scrum to our department. I read a little, implemented a little. Screwed up, tried again. Read a little more, tried a little more. And so on. It was basically a self-study program with help from blogs, books and the team itself.

For me this was easy. I was never really a “command and control” person anyway. Sure, I had my tendencies, but pretty mild. I knew that my teammates were the ones that really knew what to do anyway…so why not give them the tools and empower them and help them to focus on quality and value? There wasn’t a lot of “unlearning” that had to take place for me.

After those first (great) experiences, I became an agile coach. Now it was my turn to help teams transition to Scrum by educating the team, Product Owner, and Scrum Masters. Well, admittedly, I was winging it for a while, but through trial and error I fell into a pretty good groove.

There are three options/approaches to helping others become Scrum Masters.

Scrum Master-Agile Coach leads

The Coach Leads

With this approach, the coach plays the role of the Scrum Master, while the soon-to-be Scrum Master watches, and assists. Then, after a while (depending on the Scrum Masters comfort level), there is a switch, and the coach becomes the observer/helper.


Scrum Master-Agile Coach observes

The Coach Observes

Here, the new Scrum Master will be the acting Scrum Master. However, the coach will be there to observe (and help) while the new Scrum Master is facilitating. The coach would only correct/advise/encourage in private.


Scrum Master-Agile Coach Advises

The Coach Advises

In this scenario, the coach is not directly involved in any of the ceremonies. They are only there to advise and hear situations from a third party perspective. The new Scrum Master and coach meet regularly to go over gotchas, smells, and issues, etc. This approach works well for Scrum Master who just need to bounce ideas off of a Coach or validate their approach.


Scrum Master-Agile Coaching

Coach? What Coach?

This is how I learned. We didn’t have a coach. But, we were completely empowered to do what we needed to do to be successful. And, there was buy-in from the team and leadership. Oh, and we were allowed to make mistakes. And, I think what really made it work was that none of us had any “baggage” from other environments. It is rare to work in this kind of environment and going down this road can lead to great success or bigger failure. Choose wisely!

I give my team (and anyone else in the organization who wants to be a Scrum Master) those three options. #2 is the most popular. However, I just had someone pick #3.

So, which the best option?  It depends on the experience of the new Scrum Master and the team. It also depends on who the coach is in the organization. If you are introducing Scrum and have hired an independent consultant (coach),  #1 is typically the best. If the coach is there to help “improve” their implementation of Scrum, or if the organization is backsliding, then #2 is best. When there are experienced Scrum Masters that are experiencing new situations and need to just bounce ideas off of someone, then #3 fits the bill.

As far as #4…I’ve heard about many teams that tried to “do it on their own”, and completely tanked. They didn’t have that utopian environment that is oh so rare. So if you do decide to do it on your own get some formal training from experts or start reading. Read, read, read, and read some more. Blogs, books, and user groups. Ask questions on these user groups…you will find a wealth of knowledge and people who want you to be successful. Many people post awesome information and articles that are thought provoking and free.

If you are looking for Agile or Scrum Master training check out this link for amazing Agile Training

I would love to hear from others on this topic. What are the approaches you have taken in coaching, or have seen others take? How did YOU learn to be a Scrum Master?

Talk to Us Today

Agile isn’t something you do, it’s something you become

I would not dub myself the queen of anything.  But if I were to dub myself the queen of something, I would be the queen of abstract logic.  That’s a thing, right?   I love speaking in metaphors and analogies.  (And it’s totally not annoying at all.  Usually.)

It comes in handy when I’m asked questions about fitting Agile or Lean into situations one doesn’t normally consider when thinking of Agile and Lean practices.

There are numerous examples I could give where I’m asked about applying Agile methodologies in areas where typical Agile practices we focus on need to be thrown out.  In many of these situations, Agile development tools and processes don’t apply.

pile-of-booksFor example, I was recently approached by a woman who, along with her children, runs a mail order second hand bookstore from her home.  She wanted to know how Agile could help her become more efficient.  (This is where after explaining what Agile is, I go into Lean processes and get giddy about Kanban.)

topicHomeschoolTeaching_smallIn another example, I homeschooled for 14 years.  In the homeschooling community there is a constant strain toward making the most of your time, accomplishing certain milestones, and struggling with the balance of “the way things should be done” versus “how things work best for our family”.

Situations like these are where I get to talk about Agile as a principle.  I love it.

Agile is not an instruction manual for success.  It is a principle.  The processes and tools we use – such as Scrum, XP or Kanban – have been created to assist us in applying Agile principles in areas that require some kind of team structure and standardization.

But “Agile” is not a process.  Until you can wrap your mind around that, it will be hard to truly bring “Agile” into your situation.

I find myself often saying to people, “Agile means pretty much what we all picture when we hear the word:  the ability to move quickly and easily.”

Very often in life as well as in business, we lose agility because we get bogged down by routine.  Things we do out of habit because that’s The Way it’s Always Been.

To become Agile means that you begin to analyze your own actions and change the way you do things if those ways are making you slower.

Agile does not mean you throw out all standards and structure.  Agile means that you only have standards and structure that work to push you toward your end goal.

One simple example I use involves kitchen organization.  Do you make coffee every day?  Is your coffee maker in one part of your kitchen, your mugs in a cabinet across the room, and your coffee in the pantry?  Why?  Because “dishes must be in the dishes cabinet” and because “coffee must be with the food in the pantry”?  Who made that rule?

1As far as that goes, who said your coffee maker has to live in your kitchen when you spend your morning in the bathroom?

If you’re Agile, you stop and question the way you do things.  You are free to move the mugs and the coffee so that they’re within reach while you’re standing at the coffee maker.  (Or heck, put them on your night stand if that’s where they work best for you.  Just don’t tell people I suggested it.  They already think I’m weird enough.)

You don’t stop and question if that is the “right” way to do things.  You simply realize that it makes you more efficient, and you adjust to make the change.

“Agile” isn’t the part where you move your coffee mugs.  “Agile” is what made you stop and question where the coffee mugs were in the first place.

“Agile” doesn’t care where you keep your mugs.

“Agile” only means that you continue to review your own process and make improvements when you need to do so.

Many times, people get stuck on this and think that “Agile” means you’re following some sort of standardized plan.

Agile is exactly the opposite of that.

When I think of great examples of agility in this world, I always think of monkeys.  There are few things more demonstrative of agile than a monkey who quickly and expertly moves from branch to branch in a tree.  They’re agile little suckers.

Monkey-On-Tree-50Monkeys aren’t bogged down by wondering what is right or wrong when it comes to grabbing branches and moving themselves along to their destination.  They trust themselves.  They adjust as they go, quickly grabbing which branch makes the most sense and moving on to the next.  Rarely will you see monkeys following the exact same climbing pattern on four different trees.  They adapt quickly to their current task and they move fast.

I once saw a monkey fall during his climb at the zoo.  I don’t know if his grip failed or if he missed his mark, but he aimed for a branch and ended up falling about two feet before he grabbed a lower branch and continued his climb.

He didn’t stop.  He adjusted his climb without pausing – skipping that tricky branch his second time around – and made it to the top of the tree seconds later.

That’s agility.  That’s being agile.

Agile isn’t a method.  It’s a principle.  It’s not something you do.  It’s something you are.

Because this is so hard to understand sometimes, artifacts like the Agile Manifesto have been made to put it into terms that apply directly to our industry.
agile manifesto
But when I’m asked by a homeschool mom or a college student, “How can Agile help me?” – there is no manifesto.

That’s when I get to talk about coffee mugs and monkeys.

Talk to Us Today

Agile won’t work on [fill in the blank]

I have four kids ranging in age from 21 to 10. For some reason, people without children really like to give my wife and me advice on how to raise kids. Usually they will provide analogies using their favorite pet. Or they will tell me about their second cousin twice removed who “just had a baby”, and here’s what they plan on doing. I just politely nod and say “thank you”.

Find out if Agile will work for youSo what’s my point? I also tend to get a lot of advice regarding agile development and how it won’t work on certain projects. I’ve heard it won’t work on complex projects, big projects, geographically disperse projects, mission critical projects, non-software projects – you name it.  Everyone who tells me this has either a) never worked on an agile project or b) worked with a poor implementation of agile.

Instead of politely nodding and saying “thank you for your advice” as when I’m given child-rearing advice, I’ve recently decided to politely challenge these ideas with questions such as:

“What experiences have led you to that belief?”

“Why can’t an offshore project implement agile methodologies?”

Below is a post that I saw on LinkedIn:

As with any project management tool, it is situational. If, like in many software development environments, there are one or two key people involved in each and every task, Agile tends to break down. In this case, there are better methodologies to employ. Like any concept, I think the rub is that no technique fits all situations.

This was written by someone who has clearly either never worked in an agile environment, or has suffered a poor implementation.

I responded:

“There is a very broad spectrum of agile methodologies out there to cover any situation. Being agile also means adapting the process to fit your needs as it’s an empirical inspect & adapt approach to managing projects. For instance, typically Scrum & XP are implemented together. Scrum only addresses project management practices, while XP addresses development practices.

The failed agile implementations I have seen were caused by one or more of the following:

  1. The team is not empowered and self-organizing.
  2. Team members are working on too many projects, resulting in excessive context switching.
  3. Management is committed to command and control (related to #1).
  4. The customer or customer representative is not involved.
  5. Processes are not allowed to evolve.
  6. There is no dedicated product owner, i.e. someone responsible for the ROI that the team can go to (getting rid of the multiple boss syndrome).
  7. Those leading the agile implementation have not been properly trained in agile.

Agile works on huge complex mission-critical projects

Agile breaks down when the organization is not ready to accept its principles. If the organization is not willing to change from command and control to servant leadership, empower the team, assign one product owner, and get the customer involved, then it will fail.“

If you feel that agile just won’t work on _____, I encourage you to find out for yourself. There are plenty of cases where agile has worked on huge, complex, mission-critical projects.

Below are some examples of successful agile implementations where I’m sure many would have said “agile won’t work”:

Talk to Us Today

Paired Programming Does Have an Impact

Nothing strikes fear into management more than the suggestion of Paired Programming.  They start envisioning multiple people sitting around one computer.  One person is working while the other is eating popcorn and reading magazines.  To be honest, I was once a ‘Pair Programmer denier’.

During a retrospective, a team brought up the idea of Pairing.  They even brought a video: www.mobprogramming.com

As a good Scrum Master I had no choice but to allow the team to at least try pairing for several hours a day.  I had every expectation that it would fail.  After one iteration the experiment was not a complete failure, and the team requested another iteration to work out the kinks.

After the second iteration, we were hooked.  Not only did pairing not fail, but our velocity began to increase, quality begin to improve, and the team started to spend even more time in pairs.

This blog post is a list of statistics that have I found that prove paired programming works, and my top 3 quick wins I received once I put paired programming into practice.


paired programming stats


Paired Programming Benefit #1: Communication

This benefit seems simple: ‘The team starts to work closer together, and communication goes up”.  However, the effects are more far reaching than that.  The team learned how to talk to many different personalities and skill sets.  They started to put our Emergenetics profiles into practice.  The team began to look beyond the ‘title’ of each team member and they began to utilize each team member’s vast talents and experience.  Our meetings per iteration decreased and our Retrospective and Demos became super-charged.

paired programming stats

Paired Programming Benefit #2: Quality Improvements

Quality on many levels began to increase. The team’s documentation quality increased while the number of pages per document decreased.  The number of bugs reported in production took a dramatic decrease while the amount of time needed for regression testing and hardening also decreased.  Job satisfaction increased as team members began to learn new skills by working closely together.

paired programming stats

Paired Programming Benefit #3: Self Organization

Planning sessions started to revolve around who would pair on stories.  The team started to self-organize in ways that I had not seen before.  The team started to ask questions like: “Who needs to learn this feature?”, “Who has experience…?”,”Who can assist with…?”.  As the team began to understand the ‘big picture’ they began to provide input on release planning and backlog grooming.  Their suggestions offered insight, innovation, and efficiency where there was none before.

What kind of experiences have you had with pairing? Positive or Negative? 

Talk to Us Today


paired programming benefits




Work S.M.A.R.T.E.R. not Harder

We have all heard the phrase ‘Do more with less’. It is a common phrase is used to justify Agile. Executives equate that by transforming IT project management to Agile they will be able to do just that. While it is true that Agile can help an organization ‘Do more with less’, it can not begin to create results until organization begin to work S.M.A.R.T.E.R

S in smarter stands for Specific. You need to set specific steps and targets for the gradual achievement of your goals. Goals that are too general are easy to forget.

M in smarter stands for Measurable. You need to measure your progress with concrete iterations and daily milestones. Make sure you update your metrics often to ensure you’re on track.

A in smarter stands for Attainable. Give yourself goals that you can achieve within a given period of time. If you are forever striving for a goal, it may take too long and you could give up.

R in smarter stands for Realistic. If your team’s commitments are way out of the ballpark, you’re setting yourself up for failure. But don’t make the mistake of not believing in your team — it’s a fine line – trust that they can meet their goals.

T stands for Timely. Am I working on the highest priority item right now? So often, teams get caught up in the wrong activities. Always think: what adds value?

E stands for Exciting. Get your team excited about the vision of your project. Allow your teams to self-organize to drive innovation. Your teams will surprise you and attain results you never thought possible.

R stands for Ready, Set, Go!

Talk to Us Today

Why I Would Never Go “Enterprise Scrum”

I’ve had some recent debates regarding whether we should start an “enterprise Scrum” initiative, i.e. WE WILL BE A SCRUM SHOP.  I would have completely supported this several years ago.  Now, I am completely against it.

In an organization of any significant size or age, there typically have been methodologies that have been introduced, pushed, then they fade away into the far recesses of everyone’s memories.  One characteristic of these methodologies is that they have very specific rules.  You can’t add to, change, or remove any of the rules.  Why?  Well, because you wouldn’t be “doing” X methodology!!!

People have a habit of dogmatically following whatever methodology management makes them follow.  Now let’s say we are doing “Enterprise Scrum”.

This means that you are performing the following ceremonies:

  • Release Planning
  • Sprint Planning (every sprint)
  • Daily Scrum (every day)
  • Sprint Review (every sprint)
  • Sprint Retrospective (every sprint)

And, you have the following roles:

  • (1) Scrum Master
  • (1) Product Owner
  • Team (self-organizing)

And you will have the following artifacts:

  • Product Backlog
  • Sprint Backlog
  • Burndown/Burnup charts (some say Scrum requires these, I don’t think it does as it’s not clearly articulated and varies by source)

So we’ve gone enterprise Scrum.  We’ve introduced this “by the book” Scrum.  However, we’ve also preached “inspect and adapt”.  But, in Scrum, the above items are non-negotiable…you can inspect and adapt all you want, but you can’t change the ceremonies, artifacts, and roles.  Can you add to them?  Sure, but you can’t “change” them.  And, in reality, making “inspect and adapt” a cultural “habit” is spectacularly difficult and rarely truly attained.

What if we have a Scrum team that wants to do a retrospective every other sprint instead of every sprint?  Blasphemy!!!  <finger-pointing> YOU are doing SCRUM-BUT!!! </finger-pointing>.  Really?  What if the team, Scrum Master, and Product Owner are all cool with it?  Now we have a bunch of stress, spinning, and politics because we want to make a change to our enterprise standard Scrum.  In reality, this is perfectly okay.  However, since we’ve pushed “Enterprise Scrum”, we have totally boxed ourselves in.  There will even be people who will not want to add techniques because “Scrum doesn’t say so”. Do those people truly understand the essence of Scrum?  No.  But they will cause disruption and waste

What if you don’t want to do iterations?  What if you want to deliver continuously instead of iteratively?  No Iterations?!?!  Blasphemy!!!!  <finger-pointing> YOU are doing SCRUM-BUT!!! </finger-pointing>.

You know all of this could have been avoided?  By NOT saying we are going “Enterprise Scrum”.  I believe the best way to roll this out is by pushing Agile and Lean and what makes sense on a project by project basis.  Along with this there should be some foundational elements that are standard regardless of the methodology/toolset that is used. In addition, there needs to be a COE that can ensure that consistency is maintained without bureaucracy, and that knowledge gained is effectively utilized to continuously improve.

Please don’t misunderstand my intention here.  I am not bashing Scrum.  I LOVE Scrum.  I always use Scrum when I execute projects.  However, I’ve had rare cases within the same company where Scrum was NOT optimal, but Kanban was. I was very thankful that Scrum was not the required standard.

Talk to Us Today

Experiencing the Agile Transition

There’s a benefit to working on a team as it transforms to Agile as opposed to jumping ship and moving from a company without Agile to one that practices Agile.

Don’t get me wrong – moving to a new company and experiencing Agile is a cool thing. But seeing a team of people you’re familiar with as it transforms is powerful. Watching familiar frustrations fade and seeing timelines shrink – with the same people on the project – is exhilarating.

The first time Agile was introduced to me, it was proposed that we adopt Scrum. My team was barely meeting our deadlines and we were working twelve hour days. We always managed to deliver, but it was because we were killing ourselves to do so. Often we’d be on conference calls at night from home, trying to finish up pieces of our product before a release date. We operated under a sense of constant panic and rush.

When we were asked by our project manager to read sections of Agile Estimating and Planning and User Stories Applied (both by Mike Cohn), we couldn’t believe he was making us invest time in something like a new methodology while we were all struggling to just keep our heads above water. But he insisted, and we all grumbled our way through our first few weeks of Scrum, waiting for it to fail and for our PM to allow us to go back to what we were doing before.

I clearly remember thinking that this would be the thing that pushed us into failure. We didn’t have time to mess around with some new methodology. I hoped that our PM would realize that before it was too late, but I had no option other to go along with him and indulge his new hair-brained idea.

Somewhere into our second week, we began to understand the process and embrace the tools. Somewhere into our fourth week, it became something that we would all insist on continuing even if it was no longer required of us.

Days of frustrated moans and frantic hallway conversations morphed into coordinated efforts and understanding.

Nights of working from home vanished as our estimates and efforts became more effective.

Rather than packing up at the end of the day and rushing home to complete something that we just found out we had to do, we were packing up and heading out for drinks because we knew that we were on schedule.

Relationships began to solidify, and our team felt a bit like soldiers returning triumphant from battle. (I know that sounds dramatic, but it really was a battle for us before Scrum. We all have mental scars from the days of fighting toward deadlines. From giving our all and realizing that our all was barely enough to pass muster.)

Other teams saw what our team was doing, and began to implement Agile, as well. Scrum terms became a part of daily communication, and the entire office changed dramatically.

Before Scrum, it was a stressful environment full of high achievers who constantly felt as though they were tugging against some invisible force in order to complete the bare minimum.

After Scrum, those same high achievers were allowed to sail forward together. The entire culture of our office changed within six months of Scrum making its way onto our team. (Remember – same people, same products, same office, same leadership. The only thing that changed was the fact that we became Agile.)

If I hadn’t been there for the transformation and experienced it firsthand, I don’t think I would have understood the significant difference that Agile can have on not only project completion, but on the people involved, as well.

Talk to Us Today
post =