Back to List

Why Did Our Team Succeed? (Habits of a Successful Agile Team)

Rachel Rieck Rachel Rieck  |  
Jun 06, 2019
If you have experience on agile teams and are looking to tweak a few things or try something different, then this blog series is for you. Our Solutions Consulting Director shares proven strategies and tactics she learned from a pivotal agile journey that you can use to capitalize on your current or future teams.

Introduction to Team Delta

Before we get into the characteristics and habits of a successful agile Scrum team, let’s talk about the journey. Way back when, I was on a project team called Delta. We worked in consulting with various clients, industries, and technologies. The first time Delta worked together (we'll call it Delta 1.0), we were put together based off a budget and had a goal. But they let us choose our framework.
Now, this team had never worked together before. We had a Scrum Master (or Project Manager, depending on the framework we chose), a Business Analyst, a Tech Lead, two Developers, a Quality Assurance Analyst, and a Product Owner. The project was a custom software application built from scratch in about six months.
delta 1.0 agile scrum team
In the team, we all had limited agile experience and a little training. Most of us had some agile-like experiences within other projects, but we never really ran full-on agile. So, we decided we wanted to really learn agile Scrum and chose to take the opportunity on this project to make it happen.
That first project was very successful, and we had a great time.

Delta 2.0 – Repeat Delta 1.0 Success?

Our second project for Delta (Delta 2.0) was a very large project. Only two roles, or rather people, were the same from Delta 1.0: me as Scrum Master, and the Business Analyst. We had a new Tech Lead, two new Business Analysts, two new Quality Assurance Analysts, four Developers internally, four Developers from the client, and a client Product Owner.
delta 2.0 agile scrum team
We were accountable for the deliverable in the budget. It was a custom software application from scratch, and it was a very large project: two years long with a total of 17 people on the team. Again, we could choose our framework: waterfall, agile Scrum, whatever we wanted to do. We chose agile Scrum.
(Note: Pure agile Scrum says we should not have more than seven people on the team.)
We did national rollouts, and we had to get our new Tech Lead up-to-speed with what we had learned in Delta 1.0. Again, this project was very successful.

Some Factors That Don’t Lead Automatically to Success

At that point, people were already asking us why we were so successful, and we were thinking about it. We looked at a lot of common assumptions (below) and eliminated most of them as the key reason for our success.

Type A Personalities

A type A personality can be very successful in agile, but at least one member of our team was not a type A, and we did great.

Similar Senior Level Experience

We were all senior level and had a similar amount of years of experience, but there are many people coming into the technology field that are newer and do well on Scrum teams.

Consultancy Nature

Because we're consultants, do we have this automatic consultancy nature? We thought, "No, that's not it either."

Similar Ages

Age can't be one of the only reasons because people who are younger and old are coming onto the Scrum teams and being very successful.

Ownership of Role

This may have been part of the key to our success, but it seems a little light.

Ceremony Gods

Did we have success because we were Ceremony Gods, and we know how to run all the different events in Scrum? No, because that's more of a process, and there's more to agile Scrum than just running ceremonies. If it were that easy, everybody would be doing it.
When asked why we were so successful, our ultimate answer was: “We don’t know”.

Delta 3.0 – Continuing Greatness

Delta was lucky enough to be able to stay together as a core team and be able to take on future projects. That's not always the case in consulting, but we had enough backlog that we could do that, which just made us stronger and stronger. We had a lot of projects come up, and we did more different configurations. For example, besides the Scrum Master, Business Analysts and Technical Lead, sometimes we'd just have the Business Analyst and the technical lead from Delta take on a small project together. Sometimes myself as a Scrum Master would work with the Tech Lead, and maybe another developer would work without a Business Analyst.
We kept a lot of the core learnings that we had in Delta 1.0 and 2.0, tweaked them as we went about each project, and they were all successful. How many teams can say they had a zero-failure rate? Not many.
Don’t think this was easy. The projects weren't easy. There were babies being born on our project teams. We had people get fired (from the client side and from our project team). We had people getting married. And, unfortunately, we had a death. We had all the normal stressful life situations that come up on any project team. It was not easy...not by one bit.
What was the secret to our success? Ultimately, the communication between your Trifecta of Greatness (Scrum Master, Business Analyst, Tech Lead) and the rest of the team can make or break any agile experience.

Watch the Full Presentation

This blog is an excerpt of a 33-minute presentation on The Trifecta of Greatness: Creating and Capitalizing on a High-Performing Team. To get all the tips right now, watch our free video.
trifecta of greatness



Love our Blogs?

Sign up to get notified of new Skyline posts.


Related Content

Blog Article
How to Drive User Adoption Before, During and After Project Launch
Cory SchmittCory Schmitt  |  
Sep 26, 2019
In Part 1, we talked about some of the factors that can impact adoption before the project even kicks off. In Part 2, we talked about the things that you can do to improve adoption during the project’s Execution. In this last installment, we’ll talk about actions you can take just...
Blog Article
How to Improve User Adoption During Your Project's Execution
Cory SchmittCory Schmitt  |  
Sep 19, 2019
In Part 1, we talked about some of the factors that can impact adoption before the project even kicks off. In Part 2 here, we’ll talk about the things that you can do to improve adoption during the project’s Execution.   Know Your Users “Know Your Users” is a broad...
Blog Article
Pre-Project Components That Can Impact User Adoption
Cory SchmittCory Schmitt  |  
Sep 12, 2019
Does the following situation sound familiar?   You were on a project that rolled out a new application to the organization. You and the team spent many long days (and some nights) building the new application. The team worked hard, and you came in on-time and on-budget. As part of the...
Blog Article
Using Human Hard-Wiring to Create a Strong Agile Experience
Rachel RieckRachel Rieck  |  
Aug 22, 2019
If you have experience on agile teams and are looking to tweak a few things or try something different, then this Trifecta of Greatness blog series is right for you. For more background on the strategies and tactics our Solutions Consulting Director learned from a pivotal agile journey, be sure...
Blog Article
How to Use Prototyping to Model and Analyze BI Requirements
Rachael WilterdinkRachael Wilterdink  |  
Aug 15, 2019
If you’re involved in eliciting, modeling, analyzing, or consuming requirements for Business Intelligence projects, this post is for you. This is the tenth and final technique in our blog series on 10 Techniques for Business Analysts (BAs) to model and analyze Business Intelligence (BI...