How does Fellowship Technologies manage complex projects?

Posted By: Lance Dacy

Here at Fellowship Technologies and in our Product Development team, we strive to constantly improve how we manage our projects. When it comes to software development, based on our own experience and research, we realized that the Waterfall method would not suite our needs of delivering product as quickly as possible. Based on this conclusion, we began looking at what method would help us best manage our software development process. In early 2008 we decided that the Scrum framework looked like a process that was small and simple to learn, yet constantly delivered increments of quality software. Fast forward just over 2 years and we still believe Scrum is the way to go. By no means are we working exactly the same way as we were 2 years ago, but the general framework of Scrum still proves to work best for us. In this post, I hope to provide you an overview of what Scrum is and how it looks in our company and then in later blog posts we will dive in to the details and provide more practical examples.

We currently operate with two Scrum teams. While they all work on the same prioritized list of “stuff to do”, we have segregated their area of focus in our product. We believe the ideal team size is 5-7 people (2-3 coders, BA, QA, DBA). Team S.H.I.E.L.D. is focused on the ministry aspect of our product. This means any area that deals with events, groups, or ministry related features. Team Prototype is focused on the administrative aspect of our system. They support actions such as giving, email, payment processing, and the features that support the administrative tasks of the church. This focus helps to ensure our teams are not context switching between applications. 

As you can imagine, anytime I mention the name Scrum or Scrum Master, people immediately want to know what I am talking about. I have had a couple of years in my growth with Scrum to help refine my answer which usually involves the “marketing elevator speech” rendition. So, here it goes in less than 25 words:

Q: “What is Scrum”?

A: “Scrum is an empirical and iterative process management framework focused on delivering the highest business value to the customer as early as possible.”

In the context of my answer, I am actually referring to Agile Software Development; however, Scrum can apply to any kind of project. Over the years, people / churches ask me “can I use Scrum for XYZ project?” My answer is usually this: “If you have a project that needs to get done AND it involves people, then you can use Scrum”. Naturally, there are aspects of the framework that only apply to software development, but given Scrum’s empirical nature, strive to make decisions on what serves your team best through experience and current circumstances.

We chose to adopt Scrum to ensure that our software development process revolves around the people and not the other way around. Scrum has inherent benefits in team building, collaboration, and delivering software. We also chose Scrum to help us be more disciplined in our approach to software development. We are required to deliver working software that has value to our customers at the end of each sprint. Sticking with that discipline will ensure that we are only working on the highest priority items. Once they are complete, they should be release ready so that we can focus on the next highest priority items. It is all about the people and disciplined approach that help us meet the market demand sooner.

A Scrum team is made up of a few specific roles. These are the principals in the process that Scrum is very prescriptive about (the nuts and bolts of the process). In this post I will give you a quick overview of the team and then dive deeper into each role in a later post. In my opinion, the common software problem is to build the right system, the right way, and deliver it at the right time. The Scrum roles seem to align perfectly for each point of that problem.

Product Owner (The Right System): This role is basically the keeper of the product backlog (the list of stuff to do). While anyone can add to the product backlog, this role is the only person who ultimately prioritizes the work and should be the expert on the customer’s needs. They are the Agile Customer in that they represent the many voices that steer Product Development, but the team only responds to this one person allowing the team to focus more on the solution than defining the problem.

Scrum Master (The Right Time): This role is responsible for ensuring that the team is fully productive and functional. The team is best served by a person who is a servant leader, coach, facilitator, and/or teacher. The Scrum Master enforces the Scrum framework throughout the organization and is there to educate those who interface with the team (and vice versa). One of the most important jobs this person has is to remove any organizational or team impediments the prevent the self-organizing team from attaining their goals. In addition, the Scrum Master ensures that all information about the project is radiated to the larger organization.

Scrum Team (The Right Way): While the Product Owner and Scrum Master are actually on the Scrum Team, when we refer to the team, we usually are referring to the developers (coders, QA, DBA, business analysts, etc…). The team is there to ensure the solution to the problem is that of quality and sound engineering practices. They are tasked with self-organizing as a team to meet the goals in which they have committed. The leadership of the organization sets the boundary for the team, but then allows the team to do anything within their control to meet their goals.

Remember that Scrum is about continuous improvement. We are never searching for a “perfect” team or process. We simply want a team that strives to do better today than they did yesterday. Scrum is a vehicle that creates an environment and culture to support that process.

About the Author:
Lance Dacy is the Director of Project Management and acting Scrum Master for Fellowship Technologies. He has been with Fellowship Tech since the beginning (2004) and has held numerous roles ranging from SQL developer , Reporting Manager, Director of Customer Services, and since 2008, his current role in Product Development. After our teams choice to use Scrum as our process management framework, Lance founded and continues to co-lead the DFW Scrum User Group to assist the Dallas area in sharing the collective wisdom of the crowds using or trying to use Scrum.

Posted In: News,

Comments:
Scott Lowrie said: on March 27, 2010 at 02:17 PM

Lance,

Great post.  Has it really been two years?

Scott Uforce

Commenting is not available in this channel entry.

Categories:

Previous Posts:


Subscribe to the RSS feed!