Every single one of us, as individuals, families, groups of friends, businesses big and small, all have a myriad of things we would like to do or need to accomplish. On a personal level, it can be something as small as a grocery list or a list of chores, a to-do list for maintenance items around the house, or new experiences we want to try, places we would like to visit. But since we all live in a real world with real problems and constraints, we need to make choices on what needs to be done first, or at all, and what can, or must, wait.
My children need to decide if they want to ride their bikes in the driveway or go take a walk on the nature trail in the nearby park. My point is that we all experience the difficulties and challenges of project management, albeit on a small scale, in one way or another, every single day.
As more decisions need to be made, and with increased complexity, choices quickly become even more complicated. Sharp Notions is a small business with multiple customers with quite different requirements. We are limited by the number of employees we have, and what each employee can realistically do and can realistically do well. We need a system in place with which we can safeguard our commitments to our customers while keeping cost and workload under control. Have you interacted with someone who has been working a few 100-hour weeks? Not fun. Not fun for him/her, not fun for you. It is also important to note that it actually negatively affects productivity and wrecks morale.
There are many ways to manage this balance, but the key is finding a way that works for you. At Sharp Notions, we use an Agile/Scrum system.
What Is Agile Project Management?
The Agile Project Management is a set of ideas and practices that define an iterative process in which a project is defined, organized, and worked on. The key bit that sets it apart from other project management styles is that it is focused on getting the customer involved in the process at regular and short intervals. This also allows for a rapid and flexible response to changes. A timeframe for “checking in” with customers is usually from a week to two weeks.
The reason for this, and the main issue that Agile tries to address is to allow the customer to introduce changes earlier in the process, rather than waiting until closer to the end of a project. Changes that are added later on in the project cost more time to process and develop. And, as the saying goes, time is money. Not to mention, it upsets people to have to rework things.
So, how does this happen? What exactly sets Agile apart from all the rest? As I said before, in addition to understanding what the customer wants up front, we also want to get the customer involved more frequently, rather than waiting until we are toward the end of the project. We want to get any changes introduced as soon as we can. This is done by showing the customer the progress we have made for the project often.
With Agile, you no longer dread changes. In fact, customer feedback is one of the driving forces that allow the team to deliver a product that the customer is going to be happy with. There are no surprises for the customers because they have been along for the ride the whole time. And there are also no surprises for the team because they have been receiving regular feedback. Frequently, it is also beneficial for the customer to be shown smaller pieces of the project so that it is quicker and easier to review and digest. On the other side of the coin, receiving feedback in small chunks like this helps to keep the feedback more accurate and more focused, which makes life easier for all parties involved.
Agile also emphasizes the feedback loop. This is where changes, updates or feedback are passed along quickly and accurately in both directions. We strive to keep a close connection with our customers. Some customers are easier to reach than others, but I would like to think that we do a good job with keeping open channels of communications.
In order to allow for the customer to see this progress, there needs to be a framework in place in order to accomplish this. This is where Scrum comes in.
What is Scrum?
Scrum was developed for small groups of people who break up their work into small tasks that are to be completed within short timeframes. In our case, the timeframe is a week (Sprint).
Scrum works well for us at Sharp Notions. We are a small outfit, and members of the web development team are literally within shouting-distance. We are familiar with each other and work closely together. Asking for advice and suggestions is easily accomplished face-to-face by stopping by someone’s desk or calling an impromptu meeting in the conference room. The terms “communication” and “collaboration” seem to be frequently used loosely and get thrown around a lot, but it’s truly what we practice at Sharp Notions.
As the Project Manager, I act as the Product Owner in the Scrum. I communicate with our customers, take note of what their requirements are, and represent them at our stand-ups and sprint meetings. I also keep track of the tasks in the “backlog” and prioritize them based on importance and dependencies.
An example of importance is if we have a customer who is launching a new campaign and has a drop-dead due date. Naturally, the work for this customer would take priority over a customer who is really in no rush. Some of the other customers in the queue may not like it, but almost all of them are understanding individuals, and I am sure ALL of them would like us to take a similar view if it were their campaign on the line. This doesn’t mean that they get neglected, but rather that we will need to find a way to make up the time.
“Backlog” is not quite as bad as it sounds. It is not a long list of stuff we have missed in the last Sprint. It just means that there is more that needs to be done for the next sprint, and the next sprint until the project is wrapped up. And even then, there are always updates, maintenance items, changes.
The development team I work with is a great bunch of people. They each have their own area of expertise or sometimes, even just preferences and thus, each developer almost always voluntarily steps up to take on certain tasks. The Scrum Master leads the scrum, helps determine how to tackle any individual issues, and ensures that the team delivers product goals and deliverables.
In conclusion, I think this well works for us. Do we get it? Yeah, we understand how it works and strive towards applying it truthfully. Do we see positive results? Yup, most of the time at least. Is there room for improvement? Absolutely.
Helpful Links: