Chapter 5. Real People, Real Stories

Many times we hear how wonderful Agile is and all the benefits that come from following Scrum practices.

However, the path to Agility is not easy.

Change and discovery require trade-offs, sacrifice, hard work, perseverance ...

In this section, various people from around the Agile community share with us their own personal Agile journeys: where they came from; how they discovered Agile; the challenges, triumphs, and lessons they have learned; and where they are today in an effort to provide words of encouragement and inspiration.

Enjoy!

My exposure to the world of work began at the early age of 15, as my family had just moved to Chicago and I needed to find a way to pay for my recreational activities. The industry I, by accident, fell into was the hospitality industry as I started as a dishwasher at a restaurant called The Anvil Club in Dundee, Illinois.

I was lucky to have a great team in the kitchen and dishwashing area that allowed me to shine and excel and was quickly promoted to pot washer—I know it sounds funny, but it paid $0.25 more per hour and we got to get out earlier than the dishwashers!

I continued to quickly grow into prep boy and finally bus boy—here is where you made the money (tips)! I loved the people I worked with, but a lot of my friends were getting jobs at a local amusement park so I followed them.

This move into the theme park industry unknowingly became my life! After high school I met a mentor who took me under his arm and made sure I learned the business in its entirety. Although to be honest with you, I did not appreciate it at the time.

I remember one day, when I was a games manager, he came to me to tell me he was moving me to be the warehouse manager. What? In that industry the games manager was a lot cooler position than that of a warehouse manager!! I complained and complained, but I did not win, so cursing him, I went to the warehouse.

I did not appreciate it until a year later when I went to accounting and realized how much I had learned about inventory management, cost of sales, etc. It made me a better manager!!

He continued to move me around the organization and assigned new responsibilities for me, and soon I found myself at the age of 24 as the general manager of a water park in Houston, Texas, with over $6 million in revenue and more than 700 employees—this was a blessing and a curse!

It was a blessing because I had the opportunity to lead teams that I had just been a part of before. This allowed me to understand their wants and needs better, not to mention that I had worked in every one of those teams, from operations to finance, marketing, and food and beverage—I knew how they felt about management and their jobs. I believe this is when circumstances led me to the Agile principles without really knowing they existed.

If you really think about it, theme parks have no alternative but to be Agile. Our big parks have 4,000 employees spread over 250-acre properties. These parks get over 20,000 guests attending every day! With an extremely complex and DYNAMIC environment, things change by the minute!

Theme parks are like little cities—we have streets, traffic, parking, restaurants, retail stores, mechanical rides, maintenance, security, etc., so they are very complex environments where traditional hierarchical models just don’t work—we empower our teams to make decisions and create an environment that is safe and fun for our guests!

I believe that one of the advantages I had as I began to take on more complex leadership roles was not only that I was just part of those teams and understood them deeply, but that I had incredible mentors who allowed me to “create my own environment.” This meant allowing me to make mistakes and learn from them—and trust me, I made a lot of mistakes!

It is funny that when I learned the principles of the Agile Manifesto I found that they had always been part of my success:

INDIVIDUALS AND INTERACTIONS over processes and tools—In the theme park industry it is all about the individual. If our employees (funny, we called them team members) are not happy, they are not going to provide a happy service to our guests, so we truly focus on creating an environment where our “team members” are happy!

WORKING SOFTWARE over comprehensive documentation—Even though we don’t develop software products, we do have products, rides, restaurants, retail stores, shows, etc. Our guests couldn’t care less that we have the most comprehensive documentation on how a show should be produced, but if there is no show, well ...

CUSTOMER COLLABORATION over contract negotiation—Again, our customer in the theme park industry is our “guest,” and the contract is the ticket they purchase to enter the park. The name says it all—OUR GUEST—we treat them as they were our guests at our home; we listen to what their wants, needs, and desires are; and we build the best experience for them!

RESPONDING TO CHANGE over following a plan—As I mentioned before, in the theme park industry nothing is constant. When you have 20,000 guests walking through your streets, watching your shows, riding your rides, eating at your restaurants, and shopping at your stores, you better be AGILE and on your feet, ready to adjust when things change—and let me tell you things change!

The funny thing about this is that the more I learned about Agile and Scrum, the more surprised I became as I saw an almost prefect correlation of how I led my teams.

These principles led me to be extremely successful in my career, like leading the first international endeavor for the company at the age of 35, responsible for a $100 million project, and the launch of the international division of the company!

But you are probably wondering where the “curse” is if everything was so great in my career, exactly in my career. But you see, so much success at such an early age made me obsess over power and money. There was never enough. I wanted more power, a bigger position, and more money.

My obsession turned me into a workaholic, working over 80 hours a week. My entire life revolved around my work. I don’t even know how I met my wife and how we had kids if I was always at work. My wife makes fun of me now. She says, “Are you sure they are your kids?”

I was so obsessed with power and money (my job) that I did not attend my daughter’s baptism! I was too busy with a very important job issue, I told my wife. I used to be so proud that I had NEVER in my career called in sick or that I would work for months without taking a day off—that is how this became a curse.

But somebody must really like me up there because as I was wrapping up my international assignment in Mexico my wife and my two daughters were kidnapped for ransom! You are probably wondering why I said “somebody likes me up there.” Well, you see, people don’t change easily unless something dramatic happens in their lives, and I guess I needed this “rude awakening.”

Yes, it was bad. It was a high-level kidnapping where 12 masked men with AK47s in three vehicles surrounded my family as my kids were being dropped off at school. Luckily the bodyguards did not pull out their weapons and start shooting, or my family would have been caught in the cross-fire!

They were taken to an undisclosed location, and the nightmare continued for 16 days!

We were blessed that they were not harmed physically, and after long negotiations and me losing all the wealth I had accumulated and obsessed over, I got them back!

My life began to change very fast, and even though I did not understand it at first, it was changing for the better. The first thing I did when I got my family back was to ensure that I was home for dinner every night at 7:00 p.m., although this brought certain complications with my employer since they were used to me working all the time.

Soon I found myself in a difficult position where, even though at my level you did not get fired, I basically got fired! I thought the world was going to collapse on me. What? I have no money and now the company I had worked for and invested all of me into for 25 years just fired me!!! No money, no job, and a wife and two kids!!

Funny how life works, and I guess I wasn’t ready just yet because as I was being fired one of my daughters was diagnosed with a very ugly disease called myotonic dystrophy. They say bad things come in threes!!!

And the learning began ...

Assimilation Year—The first year after the kidnapping was probably the toughest, because you begin to ask “why?” You can’t understand why things happen and begin to question the purpose of life! But to be honest this was also the best way to learn. I dug deep down inside, read every book there was about life, and my little sister became my spiritual advisor.

It was a very tough year. You go through extreme feelings of sadness (depression), happiness, madness, and hate. I discovered that I had never hated before and how hate only destroys you and the ones you love.

Acceptance Year—The second year, after you have done all the soul searching and you think you understand better the meaning of life, you say, “Ok it’s happened. We are all ok so let’s move on with life.”

Even though this year was easier than the first, there is still something inside you that holds you back, that eats into your soul little by little.

Forgiveness Year—The third year is when I learned about the most wonderful action humans have at their disposal: forgiveness. I learned that forgiveness sets you free! It takes you to a level I never knew existed! Forgiveness is love! And it benefits you and all those around you!

You are probably wondering “what does any of this have to do with Agile,” and I would have to say that my experience led me to live my life under principles that Agile was founded under.

I learned that life is not about me, that life is beyond me and that I have the responsibility to leave this world a little better than I found it! I learned how to be a better husband, a better father, a better leader, and a better human being.

If you think about it, Agile and Scrum are about creating an environment where people thrive, and if people thrive (under the principles of Agile and Scrum), our world thrives and companies thrive and that can only be achieved if people understand that life is beyond us!

I now live my life under four pillars and three principles. The pillars include the following:

Family and Friends—I make sure that I am always including my family’s and friends’ wants, needs, and desires as I go on living my life: what can I do for them, how can I engage with them.

Professional—Work is an important pillar in my life, and I integrate it into my world by finding ways to add value and use it to have a positive impact in the world.

Community—I truly believe that we have a responsibility to participate and help our community, and it does not mean that you have to volunteer at the local shelter—just be a good neighbor, a good citizen, add value to your community.

Health and Spiritual—I combine these two because I don’t believe you can be one without the other. Even though I am not religious, I respect all religions, but I think it is more important to be spiritual; you need to take time to take care of your body and your soul.

These four pillars have been essential in my “pursuit of happiness,” but it also led me to the three principles I live my life and run my business under:

Relationships—I believe everything in life is about relationships. For me relationships are not what you can do for me, but what can I do for you! The funny thing is that there is absolutely nothing I can do for you until I get to know you (this is where the relationship process begins). This takes time, multiple iterations, and work!

Value Proposition—It is through those iterations that we learn, little by little, what your wants, needs, desires, and challenges are. It is only then that we can see if we have a “value proposition” for the relationship—if we don’t bring any value, the relationship will not last.

Honesty—Relationships and value proposition can only happen if we are honest, but I mean honesty at a deeper level. Honesty to me is to be able to look in the mirror at ourselves as who we truly are and not who we think we are (which is very difficult for people); honesty is to be genuine, to be transparent, not to have agendas, to be vulnerable. It is incredible how honesty provides the glue to bring everything else together!

It’s funny how a bad event could have turned out to be the best thing that could have happened to me! It will always be a bad event, but if I had a magic wand to go back and change my life, I would NOT change anything.

This experience has led me to learn how to truly affect our world in a positive way; I learned that there was one more style of leadership besides participative, delegated, or authoritarian, charismatic, primal, even servant—I discovered inspirational leadership.

My introduction to Scrum was my manager telling me “IT is doing something called Scrum—go figure it out.” Until that time I had been a traditional PMI-certified project manager and that was my world. With no formal training, I was anointed ScrumMaster and Product Owner for my business team working with our IT partners. I had to learn how to apply Scrum through much reading and discussion and trial and error, but in the process found myself challenging the way I had been organizing, planning, and managing work before.

The biggest lesson from the first six months of my Scrum experience was the need for focus and commitment. I realized through experience that one person cannot effectively serve as both ScrumMaster and Product Owner. During that time I discovered that the Product Owner role suited my ability and desire to focus on product vision, strategy, road mapping, and release planning, among other aspects. I transitioned away from ScrumMaster to become a full-time Product Owner.

As a Product Owner, I found myself in a surprising situation; I was actually getting the business what they truly needed and not what they thought they wanted months before. My team was successful in completing three projects that had been “in progress” for nearly two years.

At the time I was asked to step into the role of the ScrumMaster in the Professional Services internal technology group, I was managing all their projects—internal and external. As a ScrumMaster it became crucial to let go of the command-and-control mind-set that is required of a project manager. At the same time I was also asked to take on the role of the Product Owner facing outward to IT for our external-facing projects. The biggest learning for me from this was the need for dedicated ScrumMasters and Product Owners for a team and that one person cannot fulfill both these roles for a new team. At any given time I was failing in one of the two roles I had been asked to take on.

I continued this way for about six months—thinking with my old project manager hat that multitasking was good and that once I learned the roles well, I would be able to multitask and be good at both. To my chagrin, I learned that my multitasking ability was actually hiding the fact that I was taking longer to get anything done, if anything at all.

Focus and commitment were what I got out of it. I was able to talk to management and convince them to pull me out of the ScrumMaster role since I had not fit in too well with that and keep me in the Product Owner role. Focusing on the Product Owner role helped me realize that as a PMP I was actually very well suited for it.

For the next 3.5 years I acted as the Product Owner for the Professional Services Technology team. Within the first year the team was able to successfully put into production three projects that had been hanging around for the past year or so. During these 4 years I learned techniques in prioritization that really helped me focus the team on delivering optimum business value. I also was able to try various ways to create and maintain the Product Backlog, story mapping, and decomposing stories. Most of these techniques I learned from reading and watching YouTube videos. The one particular technique was using Jeff Patton’s story mapping. I was able to use this with my team as we started a new project: installing and configuring Microsoft Project Server globally for all Professional Services colleagues. This technique helped the team and our stakeholder truly map out everything that the project required and identify what features would go into various releases. I believe this helped us deliver the first release in four months, which was software released to all colleagues in the United States.

The Product Owner role was very satisfying for me. Apart from teaching, I do believe that is the best job I have ever had.

In my next job opportunity, I stepped into the role of the Product Owner for two groups: Fraud Prevention and Security. The role of the PO in this organization was located in IT, not in the business (as opposed to my previous experience).

As a PO for two groups I quickly learned the traits of negotiation, as I had to work with both groups in order to prioritize the single Product Backlog before bringing it to the team for refinement.

In order for me to take on the ability to make decisions on the Product Backlog, I quickly had to learn the products and become knowledgeable on them so my decisions would be in line with what the business wanted.

I had to find a way to spend time with the business, building that relationship so that I could best enable conversations and collaborations between the Development Team and the business.

These realizations helped the team be more successful as they worked on building product increments with a clear understanding of WHAT the business wanted.

Core Scrum has become an integral philosophy of mine for goal achievement in both my professional and personal life. Looking back, Scrum has provided me a way of thinking, a way of doing, and a way of life.

Oddly, I first encountered many of the core principles of Agile while studying to be a professor of religious studies. That statement needs many qualifications, but it is basically true. I attended graduate school at the Claremont School of Theology and the Claremont Graduate University where I was an Assistant Director for Process & Faith, a program dedicated to exploring and promoting process theology. According the Process & Faith Web site:

“Process theology” does not have its own doctrines or creeds. Instead, it is a basic conceptual orientation that sees the universe as creative, interrelated, dynamic, and open to the future. It does not reflect a specific denomination or faith tradition. As a distinctive way of viewing reality, it is a way for people to deepen the particularity of their own faith while opening the way to mutual respect between faith traditions. Process theology gives people the conceptual tools for thinking and acting theologically as engaged church members and citizens of the world.

Think about that statement for moment.

For both classical theists and atheists alike, the notion that theology is “open to the future” might seem surprising given that classical theology often goes to great lengths to prove that the future is already “known” (and thereby determined) by the divine. To me, the idea of the openness of the future, that the future is genuinely open, is one of most natural experiences I have in life, but that experience often bumps up against various human attempts to control uncertainty by making elaborate plans to avoid it and/or developing complex systems of thought that try to explain it away. This attempt to control uncertainty has been as powerful in project management as it has been in theology. I have found in process theology and Agile methodologies, as well as in Buddhism, an openness to the future and uncertainty that makes sense of my experience. The decisions I make in the present have a real and important impact on my future possibilities. I had been thinking this way theologically for almost 20 years when I encountered Agile methodologies.

It was in 2007 that I first heard Agile project software development presented at a developers conference. I had already been a Product Owner of a failed development project and realized that Agile would have probably prevented my project from failing. I introduced myself to the speaker, Jason Mundok, and we discovered that his polling place at the local Quaker church was the same Quaker church where I had been taking my World Religion students to practice Buddhist meditation as part of their class assignment to explore a religious tradition different from their own. A few months later, I was working with Jason in an Agile company as a consultant. I found Agile to be a natural fit for how I actually lived my life and how I believed the world worked. The decisions I made in the present were always genuinely my decisions, even though I made those decisions within various constraints and influences. I had given up the command-and-control model of theology decades before; I was now giving it up in project management. I immediately saw the power of integrity hidden in the servant leadership role of the ScrumMaster and the wisdom of empowering teams to make their own decisions and commitments.

Eventually, in 2013, I took a job working for the Department of Defense. There is no place on Earth with a more command-and-control approach to project management combined with a fear of uncertainty than the Department of Defense. Yet in the last eight months, I have been part of a small group of people who have worked on an Agile/Scrum team that is slowly implementing Scrum in our IT shop. This change is very upsetting to the traditional project managers, but our results speak loudly. A while back, I posted our first burndown chart on our information radiator. Rarely a day goes by now when someone is not asking for help how to set up and run a Sprint. We have a lot of work to do, and there are many impediments that remain. We have to use Product Owner proxies because we have not been able to get upper management and stakeholder buy-in to the importance of dedicating a real decision maker to our projects. But we are making progress and hope to gain more credibility as the successes continue.

Agile is not just a framework or methodology. Being Agile is a worldview, a way of life. That has always been its appeal to me. And Agile’s openness to the changes the future brings makes it a natural fit for those who are prepared to embrace the uncertainty the future often brings.

I’m Jaya Shrivastava, an IT professional based out of India. As of July 2015 my overall working experience is 13 years. Prior to starting work in the software domain I’ve worked as a research scientist and lecturer.

I’m currently working under the brand of Agile++ Engineering (www.agileplusplus.com), an Agile software development consultancy and training firm. I provide trainings on all popular Agile methodologies like Scrum, Kanban, Lean Software Development, and eXtreme Programming practices. I also provide customized trainings for test-driven development (TDD), contract-driven development (CDD), and specialize in refactoring and metaphor techniques for software development.

I also consult with organizations and help them to be Agile by being on site and actually engaging in their day-to-day activities. My clients include individuals, startups, and multinationals.

My interaction with Agile started around 2007 when I was doing consultancy and training for SAP ABAP (Advanced Business Application Programming). During those days ABAP was one of the main enablers for SAP R3 systems.

The application logics were generally written in big chunks, and the database logics tended to grow beyond control. Sooner or later it becomes difficult to manage multiple application logics and code tends to get scattered throughout.

Having faced all this and to find ways of having better code, I ended up with eXtreme Programming (XP). The idea of clear user stories, planning, small releases, and test-driven development were things we could use immediately with iterations.

Since none of my acquaintances were aware of XP, I decide to learn myself and teach the same. Within a few months I was not only applying some aspects of XP in my code, but also started training people on the same.

XP was my gateway to Agile practices. I later learned Scrum, Kanban, DSDM, TDD/BDD/CDD, LeSS, and SAFe.

This part is my honest attempt to describe my Agile journey and my experiences and learning out of them. I’m deliberately omitting the names of individuals and organizations here so that I can concentrate only on my experiences. To be honest, I’m also not sure if I can mention names without their consent.

The 2008 economic meltdown (started with Lehman Brothers) forced almost all big corporations to cut budgets. With the scaling down of trainings and consultancies, I turned to small organizations and startups and was fortunate enough to get a good amount of work.

As far as my Agile training goes, by far, I got the most perfect audiences for my training in startups. They were lively, involved, and always listening with an intention of learning something.

Here are my experiences and observations on them.

For almost all the startups, having more than one day of training was a big NO. It seems that their work loss will be enormous if all of the people are involved in training for more than a day. Most of the time startups asked me to train people on weekends. Detailed planning is a slightly obscure term for startups.

Having a one- to two-hour Sprint plan is something that doesn’t fit in their way of working. Most of the time the work items/problem statement is communicated by the client or the management verbally.

Their work generally starts immediately, and the person responsible starts writing code, sometimes even without discussing it in the group or team.

Also, many times startups are working on a single project/projects from a single client and the client dictated the working environment. If the client says that they want XYZ, everyone will stop what they are working on and start working on XYZ.

The higher management and clients seem to be the real Product Owners, which don’t honor any boundaries of methodologies.

Well, I must say that the customer/management always took precedence over the practices and methodologies prescribed by me.

I insisted on User Story–based task breakups and getting sign-on with the person giving the requirements (client/management). Although this prevented work from being started immediately, most of the later problems are resolved by this. However, someone needs to be pushing them hard for this, and without management’s active support, it was almost impossible.

Despite training them for a while, they always insisted on having Product Owner and ScrumMaster as additional roles.

To some extent, situations demanded that as the Product Backlog remained an exclusivity of clients and most of the time startup teams follow ScrumBan behavior more than anything else.

I also realized that the best model for them could be ScrumBan. I proposed ScrumBan in a few organizations and they seem to be at least happy with it.

However, I must admit that their Agility (as far as changes are concerned) was far more greater than any Agile methodology.

This was extremely detrimental to the way of working as each review ends in requirement changes, and the change again was communicated verbally.

To manage this, I changed client reviews to weekly/biweekly Sprint-based delivery and mandated their presence. I also mandated that any requirement change should be in terms of an agreed User Story.

However, this works well only if we push for it. Most of the time startups bow down to the client’s wish.

Well, Agile is relatively young (~15 years) but not an unknown thing. It has changed the way people used to work.

Even with lots of success, it still needs to pass some major hurdles. We still need to encourage desire and adaptiveness to people toward Agile.

I don’t say that it will rectify each and every problem faced by Development Teams, but something is better than nothing, and a good start is half done.

There I am, entering a classroom of high school juniors and seniors whose main motivation is to pass an upcoming project so they don’t have to repeat this Biology class. My anticipation grows as I wonder how these students will take to using Agile techniques to complete their project.

The majority of my Agile coaching and training is with large Fortune 100 companies, with some in the top 10. Yet, entering this room of high school students is intimidating as they glare at me wondering what this Agile “thing” is that I am about to bring their way.

Let me take you back to how this opportunity to bring Agile to a Chicago high school classroom came about.

Entertaining at my place is a joy of mine, which means visitors see how I live. Well, I live what I coach. My refrigerator is full of large yellow sticky notes, smaller colorful sticky notes, and Kanban swim lanes to help organize my life. The colors, and what could look like chaos, always intrigue newcomers who don’t know what I do. Each time someone new comes over, I get to explain the best thing that’s ever happened to my life: Agile.

On this one particular day entertaining at my place, I have the sticky notes for laundry, submitting an Agile talk, planning a story workshop, cleaning the kitchen, and exercise (yes, I have to put that in or I won’t do it). The bottom part of the refrigerator has large sticky notes for items that are all in my backlog to do, which I’ll pull up as priority and size permit.

Ms. Rouse, who happens to be a wonderful teacher at a local Chicago high school, is standing in front of the refrigerator, staring in awe. I explain to her what this type of board is and how it helps me, and my friends who’ve picked it up, live without constraints of unorganized to-do lists. We talk about my role as an “Agile People Transformation Coach” and the companies I work with that want to grasp this better way of working. I spread the topic to how Agile techniques can be used in many different aspects of our lives, not only in the corporate world.

In the past, I have helped teenagers set life and career goals using a personal backlog and Kanban board. There are people I have coached who brought Agile techniques home, focusing on the Agile Principles (with some variances) to change the way they “work” as a family.

As Ms. Rouse and I continue the discussion, she becomes curious how something like this would work for her high school biology students who are beginning a new team project to grow a plant. In the past, it has been hard for the students to organize their work, collaborate, and stay focused. I have just the solution: my refrigerator! Okay, not my refrigerator, but the Agile techniques and practices that are helping me focus my life better are the solution Ms. Rouse needs for her biology students.

Before I enter her classroom, Ms. Rouse and I meet a couple of times to coach her on what Agile really is and the expectations. I also meet with school officials to show that I’m not a crazy person bringing in something that doesn’t make sense. They buy it and I get to come to the school to coach high school students.

So, here I am, in the classroom in front of 19 students. I get started, introducing myself to a room full of students who have no idea what Agile is or even what traditional project management is. The background I give them is this:

I am a coach that works with people and their organizations to help them understand a better way to deliver the most value to customers. How many times have you received an update to an app, and when you open it up, the update was something you’ll never use? Worst thing is that there are actually now problems with the way it works! I know, for me, it happens to me a lot.

I work with companies and people to put out the most value while helping them understand that their focus should not be only on the outside customers, but also within the organization with the way we work. In fact, in everything we do in life, at work, in school, we only want to do those things that bring value. No one wants to do things that waste time. We’re going to work on these biology projects with that in mind; deliver the most value, so you are not wasting your time. Most importantly, you get a good grade because you delivered value.

We go through the basics of Agile together. The students intently listen. They separate into their teams—similar to most companies I work with, they are assigned teams. Here, they come up with what they think their vision for the project is. Ms. Rouse has a vision, but it is important to see how closely aligned they are with what the teacher thinks. There are many times where I work with teams that have no clue what the vision is. They were told in the beginning, but never thought about it since, thus losing sight of the big picture. In my experience, not fully grasping and understanding the vision can lead to people who are workhorses, doing what you say without any stake in the project. So, what is it that this project is supposed to achieve? To successfully grow a plant using only biodegradable materials. How do we know we successfully reached our vision? We create a project Definition of Done. Yes, the students have now created and understand the project vision and created a project Definition of Done; I’m impressed.

Then the fun part starts, or at least that’s what I tell them. We now get to create a backlog with everything that needs to be done. Ms. Rouse, who will play a role similar to the Product Owner, already created the main stories with acceptance criteria:

Spike—Determine the plant they want to grow

Obtain the potting material

Water the plant

And so on ...

Most of the classes’ backlog items will be similar, but there are some noticeable differences based on the type of plant each team will grow. These new additional stories are added by the teams themselves.

We go through writing acceptance criteria for the new stories and understanding the ones there for the existing stories. To my surprise, we have completed all of this in less than 45 minutes. Even corporate teams I work with can take hours creating a backlog. The reason why: project teams in the corporate world who work on the same applications get too much into details, impeding the discovery of stories that should happen. Here in this classroom, the students have a teacher who wants them to achieve their vision in any way they can; the “what” is from the teacher (Product Owner), the “how” is from the students (Development Team).

The backlog is completed from all teams, and now it is time to begin visually displaying their work. It is important for them to understand that the board is for them, not for the teacher to judge them on. It is a means of collaboration, visualization, and transparency. The standard Agile board designed with blue tape and sticky notes is created for each team on glass that looks out on the El Train (Chicago’s above-ground subway) for each team. There is one exception to the wall, as space is slim in schools, so one team uses a modified cardboard box that folds up to take up less space when not in use. The Kanban boards are built with four simple columns: Project Backlog, Iteration Backlog, In Progress, and Done.

All their stories go in the Project Backlog. The rest go into the Iteration Backlog, which is what they feel they can complete in a week. There will be no estimating needed here. Instead, they write their stories small enough to fit into half an iteration (whatever that means for them). Then, they can determine in the first iteration how many they can do based off a gut feel. From there, they can use past iterations to guess how much they can accomplish as they get more and more consistent. Simplicity at its best.

As they pull in stories for the iteration, they task those stories. Tasks will be a day’s length of work to make it easy for them to keep track of. Multiple people should work on a story with one person on a task. Each time they meet in class and have the stand-up, each person will have a new task moved to Done.

We go through what a stand-up looks like and why they want to do them. During the practice stand-up, each team answers three questions:

“What is impeding my work, preventing it from getting done?”

“What did I achieve since the last class?”

“What do I plan to achieve before the next class?”

The stand-ups are meant for the teams to collaborate and help each other, while getting a sense of their progress for achieving their vision. It’s important the students know that Ms. Rouse will not be grading them on the stand-ups or any of the practices; their grade will be determined by what value they are achieving after every iteration. I mention this because one faux pas I see with organizations is that they focus too much on the practices and not enough on the outcome and value.

We go over the review, retrospective, and iteration planning meetings. We talk about backlog refinement and that there will be times when new stories are needed or some are taken out, along with changing priorities. What baffles me is that unlike corporate people, these high school students are okay with this concept.

Day 1 and the students seem to get it. Now, we will see how the rest of the project goes and if the boundaries put on by the school, leadership, and teacher will allow the students to work in the way they need. Unfortunately, I cannot make it the next day to teach a new class, so I coach the teacher on how to present this new way of working together, and she gets the next day’s class rolling along. Voila—both classes with a total of nine teams are up and running using Agile techniques!

The classes run the first week, doing their work, collaborating to get top-priority stories done, and holding their stand-ups. At the end of the first iteration, there is the review meeting where the teams show what they’ve accomplished in the last iteration. The goal is not for the teacher to grade them on progress, but to provide feedback needed to guarantee everyone is working toward the vision.

The review meetings are working; the teams are showing their work off to the teacher, as well as other classmates. Everyone seems to have accomplished something for the first review. A+ in my book, but that isn’t how it is seen from the school. Upper requirements from the school dictate that there needs to be weekly grades. How do you grade students when you comparing progress across teams is not an Agile direction? Without my knowledge, the teacher and leadership come up with a lengthy form that each student needs to fill out, detailing how many stories were done, how much time was spent doing each story, who did what, etc. It is a form that begins to focus on quantity instead of quality and doesn’t ever mention value delivered.

The same thing I coach companies is the same thing that has to happen at this high school. Grades are collective, and with daily collaboration and retrospectives, everyone holds each other accountable. Plus, the task board should show each person working on a task with multiple people working on one story. Here is one instance where information radiators give what they’re supposed to ... information.

If Agile is a team sport, similar to basketball, how do you grade an individual on a team? You don’t. It is like saying that the center position on a basketball team gets the highest grade because they make the most shots, not taking into account that they got those shots from other players who provided rebounds, assists, and passing plays.

Ms. Rouse and the school begin to get the concept and go with the flow. The grades will be based as a team, and each team is told they are to hold each other accountable while working together to get stories completed. If there is someone who isn’t collaborating fully with the team, then it comes up in the retrospective and they collaborate on why and how to fix the problem.

Each day for five weeks, the students held stand-ups, showing off work in review meetings, adapting during retrospectives, tasking and planning during iteration planning, and collaborating the whole way through. Most importantly, the teacher allowed the students to self-organize, be empowered, and work. Funny enough, companies I work with don’t always trust the people who they hire, who have the skills, who went to school for what they are building. Leadership tells me they trust each person, but the culture says different. Estimates are dictated, timelines are strongly suggested, and worse off, micromanagement is the norm.

At the end of the plant-growing project, each team successfully completed their project, growing various plants and having a final “release.” Their final review meeting was a presentation for the teacher and their classmates on what they accomplished. And, right next to each team was their plants, the final product, ready for release into the world.

My main takeaways from Agile in a high school biology classroom include the following:

Allow people to self-organize and empower them to make decisions on their own. They’ll get things done faster, better, and with more desire, no matter the age or knowledge.

Allow for discovery. Backlog items do not need to be so detailed that there is not room for thinking outside the box. High school students weren’t so caught up in the details, and they allowed themselves the ability to discover. The teacher (Product Owner) also wrote stories that allowed for discovery.

It’s all about team performance. Trying to distinguish an MVP by the number of points scored leaves out those who provided assists, rebounds, and such.

Allow metrics to drive the conversation. Leadership will always want metrics, so set expectations early that metrics do not always give a full story.

Estimating is not necessary. Teams can get a feel for what can be done and keep that “feeling” throughout.

What to do comes from the Product Owner. How to do it comes from the team.

Focus on value delivered! Value is crucial.

Simple, simple, simple. This is the only way to be efficient.

I started my Agile journey 14 years ago.

At the time I did not realize that I had even started this journey. While I was working on my bachelor’s degree in graphic design and web development, I got an internship in a small printer in West Virginia.

They had just moved to a new plant and were implementing Lean manufacturing. Over the time I was there I was able to work side by side with the plant foreman. Working with the plant foreman I was able to see Lean in action.

On a bimonthly basis, he would review the job data collected as the jobs moved through the plant from station to station. He identified bottlenecks in the plant and looked for solutions to remove them. It took them close to a year and a half to really figure out the best layout for the plant, working within the constraints of equipment and eliminating 95 percent of the waste from the flow of work through the plant. Over time, he also added various visual workflow boards and signal cards for when jobs were ready to pull to the next station. This was more effective than the electronic-based job management system.

By the end of the second year I was ready to graduate college and start my career.

Surprisingly the small shop was able to compete with other large printers in the area, not because of the size and equipment but based on their ability to be extremely efficient at getting work done. I learned a lot at this stop in my Agile journey, and I knew that these practices would come in handy one day.

Next, I landed a job in the print production team in a large financial institution.

This area supported the design and creation of marketing collateral for acquiring new customers and offers for existing customers. The process to get these offers to the mail would take eight weeks. There clearly was a lot of waste in this system but it was meeting their needs.

When presented with the opportunity to use on-demand printing techniques to drive one-on-one targeted marketing based on customers data, eight weeks was not going to support this type of marketing since the data would be stale. They needed to really streamline the process. I suggested that we look to some of the techniques I had seen applied at the printing company. There was a consensus we would give this a try. We set out to reduce the lead time to three weeks over the course of a four-month period. The steps to create and execute the marketing campaigns was a fairly simple flow; the real waste in the system was time spent at each step in the process due to the extremely manual process. Over the next four months we released to them new tools to support the management of campaigns using office automation to minimize and eliminate most of the manual data entry; we created templates mapped to content libraries that dynamically built letters based on offer data, and we automated validation of content created during the autogeneration stage. We released these items to the workflow incrementally so we could validate that the change worked within the first month we released the office automation. While this only saved a week, employee morale was increased due to a dramatic reduction in repetitive manual data entry. Months 2 and 3 were spent implementing the creative creation automation. This reduced the timeline by three weeks. This also freed the graphic designer to focus more on the actual design of new creative and handling one-off test creative instead of allocating 75 percent of their time to manually creating files. The final phase to implement the audit automation was more difficult than originally planned and we missed the four-month target on getting this change implemented. In the end we were two weeks late on delivering the solution. Thankfully the hardworking people in the audit group managed to save the day for the launch. Once in place it did remove the final week from the process. After being a major contributor to this project as both a developer and project manager, my focus shifted from the graphics department to process engineering and more business analytics for development projects since I could translate business requirements to tech requirements and had a deep understanding of the business. The process engineering was my favorite part of this new role. Over time the process engineering work was reduced and I was slowly becoming more of a business analyst. This was far from where I wanted to be career wise. Around this same time I had started doing some moonlighting as a developer with some friends on the side. I realized my passion was in technology and it was time to move on. Ironically around the same time another division of the financial institution I was working for decided to reach out to me about a job being a data analyst since I have a background in SQL and SharePoint development and they heard about what I was able to accomplish in the graphics department using Lean.

A few months into this new role we were notified that our project management team would be moving to Agile and I would have some additional duties added to my data analyst responsibilities. I would be helping the Product Owner with stories and testing. It was not introduced to us as Agile. We were told we were moving to Scrum. We got three days of training on Scrum. It was an interesting concept to me. No countless days writing requirements, delivering often, and getting feedback so they get what they ask for, all at a sustainable pace. The Agile Manifesto was not mentioned during the three-day training. Project managers were converted to Product Owners and ScrumMasters depending on whether they were in the business or the technology side. Due to the small number of technology PMs the role was opinionated to the development tech lead for some of the teams. Planning seemed to be in a good spot since we at least had a roadmap of what need to be accomplished for the year, and a backlog of items was created from the approved BRD documents. Development was driving the priority and order of the stories being developed since the Product Owner did not understand the concept of MVP and was not introduced to the training. We were three Sprints in and had not had a Sprint Review, retrospective, or a release to production. Development continually delivered all stories at the last day of the Sprint, and there were always bugs. We were carrying these bugs over to the next Sprint. The business was very dissatisfied with the development as Scrum was not living up to its promises and the project was falling further and further behind. The solution to this was to push the Development Team to work more hours to get the project back on track. The ScrumMasters were enforcing this directive and becoming true task masters. I was pretty shocked that we all went to the same training and we were barely following any of it.

I spent a weekend trolling the Internet for all things Agile. I was blown away by the history, frameworks, and practice being used. I came to the realization we were just doing Scrum and doing it badly. We were far from being Agile. The missing ceremonies were not helping anything either. I set out to get a community of practice meeting set up shortly after a weekend of studying. Out of this community we came up with a game plan to change for the better since there were no coaches available. Out of this community we worked to incrementally improve how we were implementing Scrum. The first goal was to get all of the ceremonies in place. Once all of the ceremonies were in place and retrospectives started happening regularly, we were able to get development delivering stories to test earlier in the Sprint. This did not fix the quality issue were having. As a community we came to the consensus that that the Development Team was burning out from being overworked and poor story quality was due to a lack of grooming and collaboration with the Product Owner. We got the business to provide us an extension on the deadline of the project to take the burden from the Development Team. Then we started grooming with a regular cadence, and technology relinquished the prioritization of the work to the business. It looked like things were turning the corner. The addition of grooming did not fix the quality issue as we had hoped. So we looked to eXtreme Programming and pulled in Test-Driven Development (TDD) and paired programming. TTD was more effective than the paired programing for the teams. After five Sprints of incremental change, the 10 teams were finally starting to produce and deliver quality code. While the teams improved, I was also working on an Agile Lifecycle Management (ALM) solution using SharePoint to consolidate the 10 Excel backlogs into a centralized tool so that we could start putting together dashboards and auto burndown and burnup charts and online task boards for the offshore teams. I had also spent a bunch of time creating automated regression testing so that we did not have to do this manually every time we went to integrate new functionality. I automated all of the test cases except the current and previous Sprint. I still use this philosophy to this day, and it still proves effective. The changes leveled out, the tool I built took off and was being used and evolved in an Agile fashion until I was drafted to take over the ScrumMaster role for a team when the current one was out on maternity leave. Finally I had my foot in the door of technology and this could be my path to being the developer I’d been trying to get to. Boy, I was really wrong on that thought. They just wanted me since I had been driving change to a more Agile development. It was really different to see the former tech PM/tech lead ScrumMasters in action. There was no team empowerment—it was more of a world of command and control. Definitely not the servant leader I had understood the role to be. To get to know the guys I just inherited, we went to lunch and we chatted and started working on our bond and building trust. Being a ScrumMaster was a really fun role to play and a lot of the problem solving that I love was there—just different from the problem I solved wanting to be a developer.

Our team became the black sheep in the flock, not conforming to meeting in rooms for ceremonies. We started guerrilla-style grooming (a story for another day), having retrospectives at restaurants, or working out on the patio on the nice days. The team liked this since it broke the monotony of the corporate culture. It also helped that the team was a top performer and delivered quality work.

While this was all fun and good, it still did not scratch the itch like development did. Right around the time the actual ScrumMaster was to return to work, I got a call from my buddy who was starting a SharePoint development group in another line of business at the same financial institution and offered me a job I had been dreaming of for a long time. I jumped at this opportunity. I learned so much here at this stop on my Agile journey.

I was in heaven in this new job. I was getting to do development and process engineering. I would use the Lean techniques to make the process as streamlined as it could be to iteratively deliver solutions to the business, filling in gaps and adding automation and application as needed. I was using all the Agile and Lean knowledge I had learned over the years, but we were not calling it either, as they were not accepted practices by upper management, so we masked it as rapid application development (RAD).

We continued doing things this way for about a year with a lot of satisfied customers, until we started this line of business Agile transformation and a push to consolidate technologies. The SharePoint development group was dissolved. I was faced with a choice to become a ScrumMaster or become a Java developer. Standing at the crossroads weighing my options I came to the realization I was not going to be a 500-line-a-day coder and I was going to fall to the back of the compensation pools for at least a year or two. With a lot of hesitation, I went down the ScrumMaster path. I also requested to be transferred back to the group I left a year earlier. When I returned I was given the team I temp-ScrumMastered for. Not much had changed since I had left except for some significant scaling. I would need to support three teams on three continents and three time zones. I was able to get them to send me to get my CSM certificate. My CST was a fantastic instructor, and I learned a great deal more than I imagined from his class than just how to do Scrum right. He helped spin the ScrumMaster role in a light that I had not thought of. It made me grateful that I had chosen to take the red pill. His class also highlighted areas of extra exploration that could enhance my ScrumMaster skill. He gave me insights into distributed teams I would have to manage through. I wish they had decided to allow us to attend training by a certified individual or brought them on site. This would have made a world of difference and my journey may have had a different path. ScrumMastering for three teams was by no means fun. Thankfully this company had extensive investments in video phones, messaging tools, and Jira as an ALM tool. My Product Owner was willing to work odd hours to support the geographical limitation. In addition to the odd hours, we set up a hand-off note system—thankfully all of the times zones allowed for a four-hour overlap with each other. There would be 24 hours of continuous development daily. Learning to agile distributed was a challenge, but it was very rewarding. Learn about cultures and how to interact with each so maximum team performance is achieved and hopefully happy. I spent a lot of time reading books on Agile testing, frameworks, and better planning and looked for good blogs on the Internet.

The constant grind of the three teams and providing coaching support eventually led me to seek opportunities as an Agile coach. I really loved the role of a ScrumMaster but I loved coaching teams more. It also allowed me to interact with people at all levels in the organization. So I found a consulting company that was looking for a coach to help with an Agile transformation of a large financial services company. This being my third transformation, I was pretty pumped. They were about a year into the journey and looking for coaches to help steer the transformation back on track. They also made the mistake of not hiring anyone with Agile experience or acquiring training from a professional trainer. Instead they bought 200 copies of Scrum from the Trenches and told them to read it. They had a complete lack of dedicated Product Owners. It was interesting to see people trying to do Scrum without the ability to plan and a lack of a vision. To offset these planning challenges we implemented Kanban. We then implemented a Kanban board as a method to visualize the incremental improvement to provide better planning. It’s still a work in progress but we are making incremental improvements. We will see if this works.

Thank you for taking the time to read my journey. If you would like to continue with me on my journey, join me at my blog: www.scrummando.com

One would not really call me an Agile practitioner. Really, I am a process hacker. I noticed my need for high efficiency at about age 7 when I calculated that nine bites was the optimal number for consuming my toast (sandwich bread that is square).

While I work in the technology sector sometimes, I am not typically on product teams. I tend to work in operations or in a coaching role. I facilitate events and write about how to make things work, including organizational design.

I had heard of personal Kanban and played with it a bit, so I decided to modify that process to fit my project. Each essay had to go through a process. I had to invite the contributor, help them develop and submit a piece, edit the piece, match it with a picture where possible, get the contributor to sign off on the final version, and sign a contract for me to use it. No, it wasn’t just the three columns of Kanban, but it used Post-it notes to move across an action space.

Thirty essays seemed reasonable. I loosely planned for that. Then, as people heard about the work, they requested to be contributors or I discovered another person and idea to invite. The project grew to 65 with all the contributors in various states of the process progressing at variable rates. I might, on a given day, have 10 Post-its in the invitation column, 17 in the edit column, 12 in the image column, 5 in the finalize column, and 3 in the sign-off column. I didn’t really even know when I started what all those columns would be. They emerged as I went through the process. I could not have scoped that work out at the beginning and had the same results. It was the emergence and tracking that allowed me to get the whole project to completion in 90 days. The final result was tremendous, leading to speaking engagements across three continents. Personal Kanban was simple enough to expand to the column count needed, while clear enough that at any given moment I knew where the project was in development. I still use a personal Kanban setup or Trello to get projects tracked and completed.

I was thinking a lot about gamification, particularly how you do lots of small confidence building activities before you face off the big boss monster. Daily Scrum was a way to do that. Of course, normally these tools are used with teams working on a project together. We didn’t have that sort of unity. We did, however, have a group of people at roughly the same place in their careers working toward the same larger goals, so people felt connected as peers even if they didn’t share the same project goals.

Now Mark Finner, my life and work partner, and I use a similar process on a daily basis: filling out a short form on what we accomplished, what we have as a goal for the day, and what requests we have of the other to get it done. Sometimes he wants me to edit his writing. Sometimes I want him to help me think through an idea. We have a huge difference in our approach to productivity, so this method is helping us connect across that difference. It also keeps us updated quickly on what the other person is accomplishing.

Similar to the Scrum-like agency, my peers were not working on the same project as I was in most instances. But having a partner to chunk up the work to an hour-long size and then hold us accountable for getting it done offered the kind of support that helped me. Usually we use Skype or GChat to simply post the activity for that hour and decide what little way we might celebrate our success. Celebrations tend to be small things: as friends we might do a catch-up call at the end or maybe share a funny video with each other or each take some time to nap or enjoy nature. However, the rule is, if you get off task, say the mailman rings the door or you are researching and get lost on Twitter, then you have to report this to the other person. The other person then acknowledges it and encourages you to return to task. We don’t judge each other for getting off task. That happens. We just help each other get back on it. I continue to do peer-working when I get a chance: when I find myself procrastinating, when I have an important deadline, or if I have to do a batch of tedious work.

“Dave, we need to switch to Agile.”

Me (with a perfectly honed blend of jaded PM sarcasm and irritation):

“Oh really, Tom? Why do we need to switch to Agile?”

Tom Developer: “It will improve our quality of life.”

Me “Tom, get the F&*% out of my office and go code something! You are a developer! YOU DON’T GET QUALITY OF LIFE!”

“Dave, have your team read this book over the weekend. You are Agile on Monday morning.”

That was it. Needless to say, things did not go well. I often joke that if the Agile Counselor stopped by and handed me a teddy bear and asked me to point out where XP touched me in a bad place, I would be able to do so without even batting an eye. It was so bad that I avoided Agile like the plague. I was convinced it was just another way for developers to get out of estimating anything.

D’OH!

My true Agile journey began when I was laid off from a company I had been at for 19 years. I started with the company when I was in my early twenties. The layoff made me feel abandoned, hopeless, and filled with self-doubt.

While looking for new employment, the job descriptions would often say Agile or Scrum experience for the positions that I felt were most aligned with my background. I decided to do a little Web research on Agile and Scrum to see why so many of the companies were expressing their desire for Agile and Scrum experience. I was about to sign up for an introduction class for Agile and Scrum when I acquired a new position.

I was so relieved to have found a new position and grateful that a previous working relationship provided the referral. However, I soon found out that the position was not what I had hoped that it would be, as it had its own set of challenges.

Although my previous company exposed me to the Agile concept, I was most comfortable with the traditional waterfall methodology. As with my previous company, this new one didn’t use Agile or Scrum. It wasn’t the preferred method for “our” projects, which was strictly the traditional waterfall march to the end date. I was used to tons of artifacts to be tracked with blended resources to keep track of percentages of human resources, since they were parceled off under several different projects, but I noticed that nobody was happy, including me. I was supporting two new contracts, and the projects were tracked by milestone completion dates. Metrics were used to show their success or failure. Unfortunately, most of the projects were failing. I had over 40 projects going on at one time. The human resources were spread across not only my projects, but another project manager with their own set of projects. There were too few resources and not enough time to complete them. Without getting into the details of the contracts, suffice it to say they were set up to fail before the contracts were signed. Both of the contracts I was supporting ended, and being that this new company was a projectized organization, I was again left to look for another job, as were several others.

I decided to take a different approach with this layoff, but as with anything this layoff had its own challenges; however, this time I was going to further develop my Agile and Scrum knowledge. I found a training class that was an introduction to both Agile and Scrum, and took the class. Agile and Scrum seemed like a breath of fresh air. The class was both enlightening and fun. So after my first real taste of what my work life could be like with Agile and Scrum, I wanted to learn more and do more with the information I had collected.

I soon acquired a new position, this time with a mobile software application company; it wasn’t my ideal job, but it was a stepping stone to where I wanted to go in the future. Luckily the new company was receptive to the Agile and Scrum concepts, although they were still using a form of waterfall to deliver.

I decided to sign up for another Scrum class, but this time it was a Certified ScrumMaster class.

My Certified ScrumMaster class was scheduled for January with Daniel Gullo through Apple Brook.

Daniel’s class was informative, engaging, and interactive. We had opportunities to work in teams in scenarios that required us all to deal with people at various skill levels with Scrum.

The class had the opportunity to understand where Daniel came from in terms of his work background and the difference Daniel made in his life both physically and emotionally using Scrum. Daniel showed us a picture of himself while using the traditional waterfall method, and he spoke about how he felt. Daniel looked unhappy using the traditional waterfall method, and it showed in his picture. Daniel showed a picture of himself while using Scrum, and he described how he felt. Daniel looked happy using Scrum. I saw myself in Daniel’s before picture and his description of himself. Daniel said that he wanted to be happy at his job, and I wanted that for myself too. Life is too short to be miserable at your job and dreading to go to work every day. Most everyone has to go to work each day—we spend half our days at a job, and we should at least enjoy it.

So after leaving Daniel’s class, I brought Scrum back to my office, completely willing to change the way that things are being done at my company. Although change is not an easy concept for anyone, I have gone through so many changes over the last few years, so I get it. I am slowly trying to socialize the Scrum concept with the daily stand-ups, integrating the Sprints, (which require some changes to their contracts, but that’s a different story), and doing retrospectives. I have also been trying to convince the CEO to use something other than an open-source solution for the Product Backlog and Sprint backlog because managing a portfolio using an open-source solution is not sustainable over the long term; it’s not robust enough to get a full picture.

I have recently attended yet another Scrum class, and I had the CEO stick his head in my office to ask me about it, and he has asked me to put a presentation together for the teams. So although change doesn’t happen as quickly as I would like, change does happen. I was told a long time ago that in order for things to change, things have to change. Things change over time, and we don’t have all of the answers up front so why build a plan based on a bunch of assumptions that you know will change? Scrum is just a way in which people do work; it’s Agile, and it makes life happier.

It started with the book by Jeff Sutherland Scrum: The Art of Doing Twice the Work in Half the Time. I can’t remember how I found the book at first, but it was probably one of those Amazon recommendations based on other books I was reading at the time.

I really liked the book and I bought several copies and handed them around at work. I work in a family business. My grandfather started it in 1939. It is called Watson, Inc. We make ingredients for food companies. Currently we have about 275 people working with us. About half of the jobs are manufacturing and the other half are laboratory and office jobs. I am in charge of manufacturing and the maintenance department.

We had been doing Kaizen events mainly in the production, maintenance, and warehouse areas with a consultant on Lean. Kaizen events sort of started the ball rolling because Kaizen events involve allowing people to take a week or so away from their normal jobs working “in” the business and instead spend some time looking at how we get the work done, which is working “on” the business.

It was fun to see how engaged people got when they were asked to do this. Initially people would feel a bit uncertain getting started, but after a day everyone was seeing what we did from a new perspective and seeing a lot of opportunity for improvement.

Having read Jeff Sutherland’s book a few times, I happened to see a course on Scrum being held nearby at Fairfield University. I decided to sign up. Daniel Gullo was the instructor. After I signed myself up, I started to think that other managers and supervisors might also be interested, so I put the word out and in the end we had about six people in that class. Everyone enjoyed it and it really helped to make things clearer and answer some of our questions.

Daniel had a second class a month or so later, and I think we sent four or five more people to that class. After the second two-day class Daniel met us at the plant, and we took him around and showed him what we did and talked about what we had done so far.

In the manufacturing environment we were not able to implement Scrum in a pure sense but we did our best to come close. The best way to illustrate this is probably by explaining how we used to do things and then what we changed.

We work three shifts five days a week. Every shift has a start of the shift meeting. In the original way of doing things (before Scrum), before the shift started the supervisor would make a trip around the plant floor to see what was being done currently and compare that to the schedule and discuss whatever was going on and what issues had occurred with the previous shift supervisor. The employees would show up at the appointed time in a room, and the supervisor would assign the work and designate who was to run which machine with whom and what they were going to make and how much needed to get done. If there were equipment issues or raw materials were late, the supervisor would then need to go find maintenance and the warehouse manager and make them aware of what was needed.

In the new way of doing things (after Scrum), the supervisor acts like a ScrumMaster. His role is to help remove obstacles and ask the three questions. In our case they are just slightly different. What did we do on the previous shift? What are we doing today? What is getting in the way?

Each shift decided how they are going to work together. For example, they decide what defines “on time” for the start of the shift meeting. They also decide who is going to run what machine and with whom. One shift decided that each week everyone would make the decision about what machine each person was going to run. Another shift decided to do this each day. This has led to a lot of unusual combinations of people and machines. Many people want to learn something new so they will negotiate/volunteer to run a machine that they have not run yet so they can learn more about it. The team on each shift worked out their own process of how the arrangements are made.

In the current way of doing things before the start of the shift meeting people will have already gone out to the machine that they decided they are going to be running and found out what is going on in that room. If there are any issues they will know about them because they have already spoken to the operator on the previous shift.

The operators then come to the start of the shift meeting and they say what happened on the previous shift, what they are going to get done on their shift, and what may get in their way. Examples of things that could get in the way could be a broken machine or missing raw materials. At the start of the shift meeting in addition to the shift team we now have a maintenance mechanic and someone from the warehouse, so they will immediately be aware of what is going on. The maintenance mechanic will have already spoken to the mechanic from the previous shift so he knows what is happening in the maintenance department. The warehouse person will also have already spoken to the previous shift’s warehouse person so they may already have an update they can share.

Everyone is much happier with the new arrangement. There are some things we still need to do—one of them is to have a weekly retrospective meeting where we discuss what could be done better.

There are two other ways we are using Scrum. During the Kaizen events we would always have some things that could not get done during the week of the Kaizen event but we really wanted to do because they were great opportunities for improvement. These would go on a 30-day follow-up list. Most of the time the 30 days would go by and we would discover that little, if any, of the 30-day stuff got done. We tried having a 15-day follow-up, and that helped, and then we did it weekly, and finally we thought what if a group got together every day and had a quick meeting and asked the three questions? This would keep it on the radar and keep people focused. They would not be able to work on it full time as in normal Scrum, but they would be able to help coordinate their activities and the ScrumMaster would be able to keep removing impediments. We found this to be a good approach.

The Scrum Team may have some members from the original Kaizen team. Generally they are the Kaizen team members who work in the department that just had the Kaizen event. A Kaizen team normally has people from outside departments, and even outside companies, on it to lend outside perspective for the Kaizen event. These people are not on the Scrum Team. The Scrum Team consists of a multifunctional group who should have all of the capabilities on the team to get the job done. The Scrum Team takes the 30-day follow-up list as the Product Backlog. The Kaizen team picks a member to be the Product Owner of the list for the Scrum Team. This is a person who knows what the Kaizen team envisaged and why it is important.

The Scrum Team can then set about completing everything on the 30-day follow-up list in the way they think works best with the guidance of the Product Owner as needed.

The other place we have used Scrum was to work out some complex multidepartment systems that needed improvement. People from each of the departments came together for a few weeks and worked on devising a new system. Scrum is very good for those more complex problems that no one department or person can seem to solve. Everyone on that team had a great time and enjoyed the freedom of working out the new system together.

We still have a long way to go. I have read Harrison Owen’s book Open Space Technology and I am currently reading his book Wave Rider. What these books have really driven home for me is how self-organizing we all are. If you can get people who care to come together to work on something, we will self-organize and figure it out. We will be doing our first Open Space Technology meeting tomorrow morning. The meeting’s theme is how are we going to get all of the new products for the new customers out the door. Harrison Owen says to “prepare to be surprised.” People who are interested and who care will come to the meeting, which is voluntary. In Open Space we will create the agenda ourselves at the start of the meeting by people coming to the center of the circle and writing down what they are passionate about working on and standing up in front of the group and saying it. When everyone’s ideas are posted on the wall, we will “open the marketplace” and people can sign up to meet on these and see what they can come up with.

Gary Hamel is another author I have been reading lately. His book What Matters Now is excellent. The main theme is that the traditional management system is outdated, and we should instead organize ourselves differently.

Another very good book is Reality Is Broken by Jane McGonigal. She makes a very good case that we need to reinvent work more like games. Games have four essential requirements: a clear goal, clear rules, a way to track progress toward the goal, and you can opt in or opt out. It is voluntary. Jayne McGonigal says “Scrum is a very good game.”

All of these writers and systems point in the same direction: more self-directed people working together in the ways they choose to get the work done that they find most satisfying. My goal is to keep moving the ball in that direction.

I work for a large healthcare services organization where our day-to-day activities involve building systems and applications that manage data and provide business intelligence capabilities.

Most of our work was done using the traditional waterfall methodology up until recently where there was more emphasis on reducing time to market and showing value to the customer quicker. The incremental value that was added in return for the investment our clients were making is one of the big drivers of the culture shift to Agile delivery.

As with any organization, especially IT, there is a tendency to use the latest buzzwords without fully understanding what it takes to adopt these technologies and methodologies. When adopting, there is also a tendency to morph these into a process that is not a change but some sort of a variation of the current process, which does not work to begin with.

The first step we took was to evaluate and understand the tool, that is, what is Agile? And how can we use it effectively to become profitable and increase our market share? What training will be required? How will this be rolled out? What is the learning curve like? How will this affect the current pipeline?

We leveraged an Agile coach (an Agile coach is CRITICAL to successful adoption of Agile in any organization) and trainers to build an understanding at the leadership level and drove it from there on to the larger organization. Based on our experience, Agile adoption works best if driven by the leaders rather than from the bottom up.

What the Agile coach was able to do for us is build a level of expertise/set up a foundation for Agile in-house, that is, train our own trainers. Our trainers then went on to get certifications to get that baseline established. This followed the beginning of setting up brown bag sessions, aka, the beginning of the mindset change in adopting this methodology that is very focused on collaboration, accountability, partnership, and quick delivery with minimal necessary paperwork.

What was covered in these brown bags was everything Agile—starting with the manifesto, roles, artifacts, challenges, and a roadmap for how any team that is undergoing this transition can benefit rather than going down the “quick discard” path that “Agile will not work for us/is not suitable for us,” etc.

There are challenges that take time to overcome. The pace of overcoming is determined by the culture in the organization, the strategy the leadership is taking, and the openness to adopt. Some organizations are more open to change than others.

Agile is the future of SDLC, the biggest driver being time to market and having something to show to the customer relatively quickly rather than waiting for months or even years to display the value for the investment made.

If understood and adopted the right way, Agile has the potential to take away a lot of pain for SDLC, streamline processes by making them Lean, and as a result help with employee morale and work/life balance.

All of this does have a maturation timeline, and there are challenges along the way. For us, it started out with getting used to the move from a traditional business analyst being the source of gathering requirements and creating a big book of what the client wants—a BRD—to a more collaborative, iterative process of defining features, epics, and user stories grooming. This also required understanding the Product Owner role and having a clear and concise requirements description along with the what and why and creating an acceptance criteria. This continues to be one of our ongoing opportunities, where we strive to write more concise stories that can be split vertically to enable the team to deliver incremental functionality and a market-ready product after each Sprint.

We continue to work on refining our Definition of Done. Our Product Owners and teams have committed to work together to define done so they can deliver a minimum viable (marketable) product after each Sprint.

The next thing involved engineering practices and making each and every member of the team—from developer, to tester, to DBA, etc.—accountable for the success of the deliverable. This was a shift from the team and stakeholders considering the project manager to be the sole accountable person for the health of the project to a more shared accountability model.

The team had to look at engineering practices and make them more efficient by introducing automation where they could—to deploy code and to integration test quicker. They had to think about how to plan their work to deliver incremental value and get used to constant refactoring as opposed to big up-front design.

Another opportunity we are currently looking at is dedicated resources. The traditional waterfall SDLC model had resources working on multiple projects at the same time, with resources having to explore design and code overlaps and capitalize that to minimize their work for a given release cycle. They were constantly switching back and forth and spending a lot of time in status meetings. This resulted in project delays and in some cases delivery of a product that did not meet customer expectations. Agile practices have reduced meeting time, allowed teams to be more effective, and enabled them to deliver higher-quality code. We now have increased collaboration among team members and shared accountability within the team, all resulting in quicker roll-out of products.

The journey continues for us ...

In summary, Agile is a mind-set more than a framework, which if adopted, can result in great success and positive results for an organization. It is a powerful tool, which if adopted correctly and not morphed can result in reduction in time to market, increased customer satisfaction, and reduced churn and burn. The best start is to engage an Agile coach and understand the core of Agile and how it can benefit an organization.

When I first heard about Scrum, I was a developer—team lead actually. It sounded amazing. Simple and easy and so obvious! I couldn’t believe there was a solution to all my problems.

Problems like: being told the deadline and then being given the requirements half-baked in huge requirements documents. Not fully understanding what we’re building but always finding it easy to blame someone else.

So I told anyone who would listen about this thing called Scrum—well, my weekend reading understanding of it anyway. In practice the team and I decided to try a few of the things, like reducing the requirements document down to 20 from 200 pages for only a particular feature. Features would be built in a two-week period and then handed over to the test team. Things got immeasurably better. But as you might have noted, the team and I had moved to mini-waterfall and had not fully grasped Scrum or Agile. My lesson here was that for things to improve you don’t need to do Scrum or be Agile. Small things can make huge improvements—and that might be enough for some.

Fast forward two years and much reading and trial and error. I understood the true essence behind this thing called Agile. I read every blog post I could, I tweeted and tested out ideas and workshops, I wrote about what worked and what didn’t. I joined local communities and was amazed at how open everyone was to sharing and growing.

I became one of four ScrumMasters who transitioned six teams to Scrum over 18 months. It was fun. And it was more difficult than I ever imagined. It was here that I learned that Agile can’t exist in a bubble for very long. In my case the bubble was the development area. Eventually the organization needs to adapt and change as well or the Agile teams falter.

I guess it is at this point that I felt I finally “got it.” It wasn’t about knowing everything. It was about being ok with not knowing and figuring out what little thing you could do next. This set me free. I started my journey as an Agile coach along with my business partner, Karen, in helping others to reach this point.

Karen got her CST and together we taught CSMs for a year worldwide. The first few were great—we felt like we learned more every time we taught the course. We worked really hard at setting up the training to be experiential and memorable. Soon we realized that the focus of the course was no longer understanding Scrum but more about attaining a certification. Looking deeper we realized that very few companies send more than one person to a training. And then that one person needs to transition a team when they get back with their two days of knowledge.

The question we asked was how could we make training more effective? Our answer was to train whole teams and then guide them through their first few Sprints. After that, focus on growing the ScrumMaster role. Courses give you knowledge, as do books, but it’s how you apply that knowledge and then learn from it that gains you experience. There are no magic steps to “being Agile.”

Karen and I have worked with many teams over the years. The ones I love most are the teams we visit once a month or so. We get to see how they have grown, and they get to experience new techniques we have learned. It’s a symbiotic relationship that’s always learning and growing. The entire Agile community is like this too. We all share our knowledge, our techniques, and our failures. Together we learn and become better.

The most surprising thing I’ve found with Agile is that it creeps into everything you do. It helped with my wedding plans, with my weekly house chores, even with dog training! I feel it has made me a better person—calmer and more understanding. I look forward to learning more every day.

My Agile journey, like that of so many others, started with a BHASP (a Big Hairy Audacious Software Project—I think I just made that up—quote me if you like). This particular BHASP was in 1996 in the financial sector and involved dozens of IT vendors, including IBM, Oracle, and Microsoft. In short, it was pure chaos. If I were to give a name to the methodology we used, I would call it Heroics. We worked 16-hour days, six days a week. Heck, I don’t even think I knew what we were building until we were about three months into the project. I was confident in my technical abilities, but I was struck with a daunting feeling that we might be building the wrong solution rather than building the solution incorrectly.

Fridays afternoons were a day of reflection as our team would all go out for drinks to reflect on the chaos of the week. “There must be a better way ... Isn’t there?” we’d ask ourselves over a few cold beers (well, maybe more than a few some nights). Slowly, over time, we realized that our challenges were less about technology than they were about people. In fact, we came up with the slogan “if it wasn’t for people, this would be easy.” Friday drinks allowed us to share those glimmers of hope, those small “ah-ha” moments when we heard about some small part of the project going well. Why was it going well? What made it go well? Perhaps if we started to make a list of all the things that eased pain, we could all learn from it and adopt those practices in our areas?

About six months into the project I had one of those moments where the cloudy skies opened up and the sun shone on my face. I realized that success in software development was rooted in the HOW. In fact, I realized even further that HOW the team worked together, and more importantly, how they worked with our customers was perhaps the key ingredient. It was that very moment that sparked the focus of my career for the next 20 years (I almost fell over just writing that—has it really almost been 20 years?)

In 1997, at 25 years old, I decided to form a company called Imaginet, an organization would specialize in the HOW of software engineering. It consumed me. I started a practice within Imaginet called SEPI (Software Engineering Process Improvement), the goal of which was to dissect software engineering and bring together best practices that would lead to better outcomes. I learned quickly that the term “outcomes” was subjective. To some a successful outcome was a project finishing on time and on budget. To others it was happy users. To others it was cost reduction. For a while I was in complete input mode studying any existing body of knowledge I could get my hands on, including PMBOK and the Unified Process (and subsequent derivatives), but it wasn’t until I read the book The Goal: A Process of Ongoing Improvement by Goldratt and Cox that I had my next “slap in the forehead” moment.

The book had absolutely nothing to do with software development. In fact, it was a story about a man’s journey to turn around a manufacturing plant, yet as I was reading it I couldn’t help but see the similarities with software engineering processes. Eventually, this book led me to study everything I could get my hands on around the Theory of Constraints and the Toyota Production System (which is the basis of Lean). As I dug into this new world of knowledge I remember being dismayed that these principles and practices have been around for more than 30 years and it still wasn’t the basis of “software manufacturing.” It seemed we were re-creating the wheel.

By this time I had followed the lead of the Unified Process and had dissected the lifecycle of software engineering in my own special way. I had an extensive list of practices building up for each of these different categories of workflows that I was using to help teams become more efficient and deliberate. I have to admit, I really liked how the Unified Process decomposed and represented workflows; however, every single time I’ve seen the Unified Process put into practice (via RUP or some other hybrid), it got turned into what I believe wasn’t the Unified Process, but rather a distorted version of it used to justify an extremely linear/waterfall process. I don’t want to make any assumptions regarding the creators of UP; however, I’m absolutely positive this wasn’t the intent. UP had iterations. UP encouraged incremental requirements and incremental validations. UP encouraged feedback loops and tight integration with customers. UP had a lot of really great things that matched a lot of my own experiences managing projects and teams. For that reason, UP was adopted by many organizations—only to be implemented as the distorted Rule of God, never to be questioned, adapted for scale, changed, or improved upon. That was UP’s failure—it was too easy for it to become prescriptively abused, rendering its value moot.

It was also around this time that I started to meet up with other like-minded people across the industry. I also came across a lot of what I started to call “Agile purists.” These people started to make me feel self-conscious about my own understanding of Agile. I started to hear things like “You aren’t Agile if you aren’t using test-driven development” or “UP is completely anti-Agile” and “The only way to validate software requirements is with working software not through any form of specification.” I started to hear a lot about what an Agile team is and what an Agile team isn’t. I heard comments like “That’s not very Agile” about all sorts of things—from sitting down to figure out a budget to trying to plan releases. Apparently, if you have to have releases (like a product) or need to operate under a budget and need to do a bit of planning regarding how big that budget should be, you are immediately not Agile. Well, I guess I was not part of this Agile clique, then, because I still had to operate in a world that required budgets and some way of predicting when something will be done. I started to feel excluded by the very thing that excited me not so long ago, and that bugged me.

The Agile Club, as I started to call it, began to dishearten me considerably, egged on by listening to speakers at Agile conferences preach things like “You can’t call the method you use Scrum unless you follow every aspect of Scrum perfectly!!” I didn’t care about being in this club or not—I only wanted to build software and help my customers get better at building software. Why was Agile turning into Rigid? For that reason I focused all of my time and effort on Application Lifecycle Management, which was neither Agile nor Not Agile. My customers struggled with the “getting better” part, so this is where I focused my time. My goal wasn’t to work with customers to achieve a fictitious end state of Agile-utopia, but to leave them with the tools to help them get better at building software, whatever that meant for them. Some Agile practices were no doubt a big part of this, but I rarely “preached” an Agile-or-nothing mind-set. I created a system that allowed teams to improve based on an improvement “kata” inspired by Kaizen from Lean Manufacturing. Essentially, I realized that change (real change) is driven by the need to resolve a pain or the want to have a gain (a realized wish for some specific value), not by attempting to blindly adopt a methodology for the hope and promise that it may bring. By focusing on the “why” of incremental change, I was able to see profound changes in teams. The teams I coached focused on the removal of their problems (both pain and gain) by incrementally adopting practices that would address those issues. My goal was to teach them how to change for the better, not to change them into Agile teams, although the end result was that most did become high-performing teams engrossed in Agile practices.

Over time, I met more and more people who were also disheartened by the Agile Club of Agile Purists. We were all discouraged with the absolutely rigid and strict doctrines being preached about what Agile is and is not. Of course, we understood why it was happening. Sometimes it is much easier to follow rules and patterns than to truly understand what drives them. Don’t get me wrong, I LOVE Scrum. I LOVE the practices of eXtreme Programming. I adore virtually all Agile practices and methods. I have spoken and written about these practices many times over the past two decades and believe they all have tremendous value. All of these practices are fantastic, but they aren’t all fantastic for all teams and organizations at the same time. From my perspective, I believed teams need to learn to adopt these practices with an eye of scrutiny and experimentation.

Honestly, I don’t think the term “Agile” will stick over the next decade. I think that we’re starting to see a merger of Lean thinking and Agile, and it will simply become “software development” or “software manufacturing.” It won’t be a doctrine or a set of rigid standards—it will be more scientific and practical in much the same way we see modern engineering and manufacturing processes in other industries. It will evolve through experimentation and empirical evidence.

Since my initial epiphany back in the mid-1990, my latest leg of the journey has had a focus on the continual evolution of the “HOW” based on the realization that it is only about the journey and not the destination. I believe that we should all focus on incrementally adopting practices that we know work through experimentation and incremental validation. I think we really need to erase the dogma of “Agile” and focus on “good practices” that are pulled into a team and organization based on the need and the relative maturity of a team.

Ironically, I’m starting to see a great deal of the same mind-sets being adopted by businesses, inspired by the Lean startup and customer development models. Finally, the entire business is aligned with the very same principles that we have touted from our Agile teams. I believe that this blending of worlds—Lean business and Agile development—will cause a further spark and escalation of what we call Agile adoption today. I strongly feel that we’re at another inflection point as a result, and we’ll see another way of innovation being brought into the industry. We’re starting to see a real recognition from business leaders that the way humans work together, the environment that they work together in, and the mind-set of that team as critical to the health of an organization that is being forced to innovate, or be at risk of being overtaken by new disruptive startups. For that reason, I still believe I’m in the infancy of my Agile journey, and I’m excited to be a part of it all and to see what comes next.

My Agile journey started as a brand-new Product Owner, who’d never been in product management before, or even project management. I worked at a large Fortune 250 company. I was a young, 20-something woman, full of energy, motivation, and a desire to succeed. Sometimes that was for the better, sometimes for the worse.

I was promoted out of our sales support organization after working for a little over two years as a liaison between Product & Technology (P&T) and our sales force. My job was to “keep the sales team honest,” ensuring we represented to our customers accurately what our software did and, more importantly, didn’t do. That required direct collaboration with P&T, and also served to help them have an ear to the ground of what clients were asking for and what our competitors were pitching.

Our organization scattered software development throughout the company. Our division, about 10 percent of the entire company, was focused on software for a niche industry. This completely isolated us from the other 90 percent of the corporation; we had our own P&T leadership, reporting to our division president, separate from the corporate P&T organization. Within our division, there were at least five different siloed development organizations that served different product sets in our niche industry.

We were waterfall. We grew by acquisition. We “synced” our acquisitions, rather than centralizing to common databases. We took two years to roll a release. Even though it had been years since “the cloud” had become a big thing, we struggled with the concept of multitenant hosted software. We thrived on tenure and tribal knowledge. Yet, we created documents for requirements, training, and more hundreds of pages in length.

Then it all changed, right about when I started as a Product Owner.

We had recently made a major acquisition for just shy of 25 percent of our annual revenue. They were a significant size tech company on the West Coast. With them came new perspectives—namely, Agile and Scrum. In relatively short order, our separate technology and marketing executives “sought other opportunities,” and the CTO of our acquisition took over both roles. The transformation had begun.

On Day 1 as a Product Owner, I learned I would be taking the helm of a product we had acquired nine years previous and that had been in the market since the early 1990s. It was one of the few multitenant hosted systems in the company and boasted over $10 million in annual revenue. There had been two product managers before me since the acquisition, one of eight years, another just one.

The Development Team was located on the East Coast just outside New York City (I was in Chicago). Sized enough for one Sprint team. All on the team had been with the company over 5 years, two engineers over 15 years. All but one had children nearly my age. The development manager and ScrumMaster was the former owner and entrepreneur who led a dictatorial organization. It was New York, after all.

Merging Product and Technology was step 1. Step 2 was Agile Scrum. But step 3 was the curveball; our company decided to add a 50 percent headcount per team and an off-shore component in India while concurrently eliminating dedicated QA and eliminating work-from-home-only positions.

I walked into turmoil. Massive waves of change. But I knew no different. I had a job to do: become a great Product Owner. I knew little about how significant these changes were. I just walked into them as the status quo. Boy, was I naïve.

The next six months were trial by fire. We started with two-week Sprints. Every day started with early morning standups. We did our best, but these meetings were a challenge and often took a half-hour or more. Our tools were mediocre at best—we didn’t have Jira or TFS. Our first India teammate was on a crackly phone bridge and difficult to understand.

On top of that, our hosted system crashed monthly, with all clients down on the days and hours they needed our software most. Our organization struggled with this, as most other products our company sold were single-tenant.

The reality that 2,000+ clients were all down at the same time brought us executive-level attention, and pressure to match. Our development manager implemented an “expedite” lane on our Sprint board, and even fully cancelled some Sprints. I was helpless to do anything about it—800 miles away from the U.S. team, I often didn’t know this happened for a day or more.

During this time I had my Certified Product Owner training with Daniel. He also visited our New York office conducting an Agile boot camp. I would travel to New York, and we slowly learned, together as a team, that expediting and cancelling were not going to help us. In fact, it created more confusion and resulted in us delivering less value to our business and our customers.

As our new India teammates were slowly hired, we divided into two Sprint teams, each 50 percent U.S. and 50 percent India. Our company added video conferencing around this time. This helped, but we didn’t leverage it fully.

Around nine months in, the environment stabilized, and our team’s development manager left the company. In came a new development manager who none of us knew, from another product and office.

Shortly after his addition, Daniel visited again, and we focused our conversation on grooming. At that point, our team was reliant upon extensive requirements documents, and the former owner’s vast industry knowledge from building the company from nothing in 1988 to a multimillion-dollar sale in 2003.

Together, we learned how to take a high-level epic, break it into stories, collaboratively define acceptance criteria, remove gold-plating features that would rarely be used, and groom effectively.

We invested heavily on video conferencing. No conversation was to happen without video conference. After some resistance, everyone got on board. Relationships between New York, Chicago, and India quickly grew. We then invested in travel. I was traveling to New York a week a month. I also made a two-week trip to India. Three India associates made six-week trips to New York, and I made sure to be there for at least one. Sure, we weren’t co-located, but gosh darn it, we did everything we could to overcome that.

Around the one-year mark, we finally had a historical velocity. We’d completed enough Sprints where we finally felt like we knew what we were doing. Our retrospectives had changed from complaints to ideas. We had more Glads than Mads. Appreciations and ideas were flowing freely. The team became self-organizing, even with our New York personalities.

We conducted our first complete release planning, aiming for—hold your breath—monthly releases. We set aside two full mornings, 7 a.m. to 11 a.m.—our overlap time with our India teammates—and an afternoon for the New York team. I brought breakfast. Daniel again visited and coached us through. We were lucky enough to have one of our India associates with us too—timing is everything, right?

Release planning was every bit as stressful as a Product Owner as I could imagine. All my dreams, all my hopes, for a bunch of features in a short time frame fizzled. Holding in the anxiety and desire to be sick wasn’t easy.

We were smart, too. We left ourselves a 25 percent buffer and 20 percent allocated to tech. As a Product Owner, that was painful. Cutting out features, much-needed business value we could sell, for blanks in our Sprints. And we kept creating stories! It took a lot to not scream, “How did you not think of that in Grooming” as I watched the timelines for delivering features I’d planned move further and further away.

But I had learned enough to know that it was better to realize what we wouldn’t have now versus waiting three, six, eight weeks and having to deliver bad news. Better to properly set expectations up front. I also knew all too well that investment in tech would mean a more stable product, with a lower long-term cost to maintain. After more than six months of system crashes, I wasn’t about to fight that topic.

We committed to our plan.

Midway through development, our retrospectives revealed another desire. We switched to one-week Sprints. A bit outside the box, but this worked for us. It gave us an ability to avoid injecting work into Sprints. It’s a lot easier to say, “I think I can have someone start that Tuesday” than “in a week and a half.” Our organization expected our team to respond quickly; this helped us do that. Our team had matured to a place where this was our decision, our stories were small enough, and we pulled in new work if we finished early.

On the flip side, though, we had to accept the reality that some things just can’t be done in a week. We agreed to accept a minimal amount of rollover, but only if it was clearly identified up front.

When the end of our release plan came around, we delivered on expectations. In fact, the team overdelivered and was able to complete more work than initially planned.

We’re now three years into Agile. Perhaps as a prize to our success, we are down to just one Sprint team. We’ve tried several other strategies from our retrospectives that may or may not be good for other teams.

We implemented a process called “pre-grooming” where a subset of the team gets together and discusses the detailed technical execution of a story, compares alternative approaches, and decides on one. Then, the story is brought to grooming and reviewed with the team as a whole. This works well as stories are looked at every day and discussed.

We also implemented a developer rotation with other, similar business domain teams. Once a quarter, a member of our team swaps with a member of an alternate team. The goal is to bring new ideas and perspectives between teams, without leaving the company. Best practices in one team might work well in other teams, or fail miserably. It also offers the opportunity to learn and apply new technologies used in another team and bring them back as possible technical solutions to the original team. Sometimes, we also find that some engineers “blossom” on other teams in ways they didn’t in their original team. Rarely, they stay on the team where they “blossomed.” This has been a great practice for us.

Perhaps most significantly, though, has been working toward continuous delivery and deployment. We aren’t all the way there yet, but we’re getting close. When I started three years ago, the team was deploying around two times a year, with a few very minor changes here and there when deemed critical—usually for supporting changes in legal regulations on our clients. Now, we are deploying at a minimum monthly and making more significant changes to deliver functionality off-cycle.

To better work with our stakeholders, we also showcase weekly in a short, recorded, maximum 15-minute session. A link to the recording and a short summary of the new changes to be delivered is also included, written in a voice that makes the content enjoyable to read, understandable by our internal stakeholders, and something they can effectively communicate as needed to users. This also dramatically reduces the time required collaborating with each group separately to build user guide documentation, write release notes, take screen shots, develop internal and external user training, and more. Having the developers do the demo also creates a sense of pride of ownership in the end product.

While our journey to Agile may not be the same as yours, my advice to those just starting, or even well into the process, is patience. Agile and Scrum are not about a single leader. It’s not about mandates. It’s about self-forming and norming teams. Listening. Working together. Growing together. Failing fast, retrospection, and taking action AS A TEAM. This requires investment into building team dynamics and relationships. Great teams care about each other, no matter the age, miles, cultures, experience, and other differences. Invest in your team, continue to offer support, present challenges for new opportunities, and be open to the ideas of the team. Nurturing your team will provide great results for your team, and your users. Stick to the principles, but do what’s right for your team. Good luck!