Stacy Simones

Stacy Simones


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.


When Building Process, Ask Why

Process is not a term belonging uniquely to business. Process fills our lives.

There are things we all do on a regular basis which are wrapped in processes we may not even realize have been established. (I bet you washed the same parts of yourself in the shower this morning in the same order you washed yourself the last time you showered. It’s your process.)

The most critical piece of creating any successful process is knowing why.

agile developmentWhy can be a bit of an irritation, so we like to avoid it. But without knowing why we do something, why we own something, why we buy something, etc – we end up with waste. Wasted time, wasted space, or wasted money.

Process in business often goes unquestioned. Nobody asks why.

If those same processes were implemented at home, someone would ask why. 


At home, imagine you were asked to cook dinner.  You were told that you’d be cooking it with two other people, but none of you could be in the kitchen at the same time.  You’d each take turns alone in the kitchen, working on the same meal.

You’d ask why.

How will the other people know that you edited the recipe or began the sauce already? You will have to devise a way to pass that information on before you hand things over. When it’s again your turn to be in the kitchen, you’ll need a way to know what the others have done.

But wait – what if you forget to tell each other that you salted the meat, and it’s over-salted? I guess you just have to be sure that your communication is flawless.

Can you imagine tag-team dinner preparations at home every night? You’d ask why.

But in business, we don’t ask why.

We hand things off to other people, wait to see what they do, they come back and ask questions, we explain or document so they all know what they’re looking at, and then we get it back again to finish.

(Many times, the meat ends up double-salted. We dump it out and start the process over again. We don’t ask why, we just repeat the same process we used when we screwed it up the first time and hope for a better outcome.)


documentationIf you were asked to keep notes as you vacuumed the living room, you would ask why.

But if someone in business asks for documentation to go along with whatever is being created for them, nobody asks why.

Sometimes there is a good reason. Maybe the person who bought the vacuum wants to know if the cord is long enough to reach the entire room.  Maybe they are shopping for a new vacuum and they want to know if a more powerful vacuum is needed.

Maybe there is some sort of regulation requiring your customer to own complete documentation of the product you’re building.

(Knowing why you are documenting something can also help you understand how it should be documented.)

You don’t always have to say no. But you should be asking why.


At home, if someone told you that they were going to put a couch in the hallway, you’d ask why.

I mean, couches are cool.  Someone might want to sit in the hallway one day. But they cost a lot of money and take up space, not to mention the work it will take getting it crammed into the hallway.

So why?

But in business, cool features are often accepted without question. Rarely do people stop and ask why.

Process & Change

I regularly use a screwdriver to tighten the hinges on our kitchen cabinets. For a long time, I would go get the screwdriver from my tool bench in my garage, use it in the kitchen, then put the screwdriver back on the garage tool bench where it belonged.

One day I asked why.

It’s common sense and it’s simple, but now that screwdriver belongs in the kitchen.

Also common sense: I did not talk to my husband or children when I made this change. I am the person who uses the screwdriver, I am the person who does this task, so I made the change without wasting their time or mine by sitting down and having a family meeting about it.

In business, a similar change would have required meetings, input, discussion and possibly a bit of documentation.


Stop doing things without knowing why.

If you can’t answer why something deserves your time, money, or space, then it’s time to examine your process.



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

Your Process Does Not Make You Agile

This is a cheeseburger: mcdonalds-Cheeseburger This is also a cheeseburger: june_blog2b_gourmetburger There are many things you can change about a cheeseburger without causing it to no longer be a cheeseburger:  You can change the bun, add some veggies, use whatever kind of cheese you like – and it is still a cheeseburger. But if at some point you decide to stop using cheese, you’ve got a hamburger. If at some point you decide to stop using meat, then you’ve got a cheese sandwich.

As long as key elements are present, you’ve got a cheeseburger.  Even if it looks different from the cheeseburger across town.

As long as key elements are present, you’re Agile.  Even if it looks different from the Agile across town.

(See where I’m going with this now?) Cheeseburger_web We can vary how we create a cheeseburger, and we can vary how we embrace Agile. The primary reason for this flexibility is this: Agile is not a process. Agile isn’t something you “do”, Agile is something you “become”. agile development You see, as long as you’re embracing the mindset, values, and principles of Agile – you can implement any methodology you choose.  You can even use pieces of methodologies and create your own hybrid way of doing things. If you’ve chosen an Agile methodology – like Scrum, XP, or Kanban – but you have not adopted the mindset, values, or principles of Agile:  you are not Agile. Just like the cheeseburger, which requires meat, cheese, and bread in order to become a cheeseburger, certain elements must be present before you become Agile. agile manifesto

 The Agile Manifesto and the 12 Agile Principles explain how to become Agile.

Everything else is just process.


Talk to Us Today

One80 Services Announces Custom Development Solutions

One80 Services is launching a new core offering: One80 Custom Development Solutions. This new offering includes the development and maintenance of:

  • Custom Applications
  • Software Development
  • System Modernization
  • Mobile Software Solutions
  • Website Design
  • Project Recovery
  • Automating Manual Processes
custom development solutions There is a trend for organization to outsource development of technology solutions.  Many of our clients are asking us to step in and work with these vendors on their behalf. One80 Custom Development Solutions will bridge this gap, providing our clients with the technology solutions they require as well as the communication, processes, experience, and guidance they’ve come to appreciate from One80 Services.

Our Agile Training and Coaching services will continue – helping teams improve by examining and modifying processes is our passion.  Custom Development Solutions are just one more way for One80 Services to help your visions become reality.

Rather than watching from afar and waiting for someone to tell you how your project is progressing, with One80 Custom Development Solutions you will be an integral part of the process from start to finish.

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



Event: How to Write Agile User Stories

Tonight at the Kauffman Academic Center and Raikes School on UNL downtown campus in Lincoln, we presented to the Lincoln Agile Community.

Andre Simones, Managing Partner of One80 Services, gave a great presentation.  I’ll just post a few of his slides here for you, so you can get the general idea.

(To pause this slide show, just hover over it.  It will stop moving until you move your cursor away again.)

If you’d like to join the Lincoln Agile Community and attend one of their free monthly meetings, head on over and join!

If you are interested in our seeing our full list of great Agile courses click here.

Thanks to those who joined us tonight, and thanks to the Lincoln Agile Community for the opportunity to come and speak to your group.

Agile User Stories


Are you interested in having One80 speak at your next event?

Talk to Us Today

Event: Managing Your Workflow

Today’s Omaha Startups June event included pizza, networking, and a great presentation given by One80’s own Andre Simones.

Agile WorkflowsWe discussed:

  • Types of workflows
  • Symptoms of not managing your workflow
  • Solving common workflow issues
  • Workflow tips
  • Visualizing your workflow
  • Prioritizing your workflow
  • Minimizing your work in progress
  • Measurements and metrics
  • Workflow management tools

If you’d like to join the Omaha Startups Group and attend one of the free monthly meetings, head on over and join!


If you are interested in our seeing our full list of great Agile courses, click here.

Are you interested in having One80 speak at your next event?

Talk to Us Today

Event: Using Science to Design an Agile Team

Today we went to the Scott Conference Center at UNO Peter Kiewit Campus to talk with the PMI Heartland NE/IA Chapter about the science (Emergenetics) involved in creating and running a successful Agile team.


We all know that Agile is all about self-organized and empowered teams delivering value to the customer. How do you know that you have assembled the right team?

In this workshop, we learned how to us Emergenetics to motivate and design teams that align to a project’s objectives, environment, and organization.

We discussed factors that influence team dynamics and how they can be harnessed to make  teams and projects successful.

It was a fun and worthwhile event.  Kudos to Nick Kramer, Managing Partner of One80, for a great presentation and workshop!

Thanks go to PMI Heartland for hosting this event, and Mutual of Omaha for sponsorship.

If you would like to learn how Emergenetics can help your teams, or you would like One80 to speak at an upcoming event, talk to us today!

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

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 =