An Agile World

As the business world continues its shift towards an increasingly digital presence, companies are working diligently in the department of change management to find the structure that best fits their business needs. In many companies today, the technology side of the business is still very separate from the revenue and strategy components. However, as time progresses and this digital drive continues, I believe businesses will soon come to learn the value of the methodologies used in technology development and how these methodologies could actually benefit their revenue and strategy focused counterparts.

What is Agile?

Agile is a software development strategy that utilizes cross-functional teams in collaboration with key stake holders to iteratively design, implement, and adapt technologies flexibly to meet business demands. Now that’s a fully loaded definition so let’s break it down based on the SCRUM agile development methodology. In SCRUM there are three types of contributors: the product owner, the scrum master, and the development team.

The product owner is the key stakeholder from the business side who has an idea of exactly what the business needs in terms of technology. The product owner works closely with the scrum master to make sure that their desired functionalities are implemented in a timely fashion.

The scrum master is coordinator of every person on the project. They keep track of who on the development team is working on what, and focuses on helping the various teams communicate between each other. Scrum masters report the project’s status directly to the product owner, making them the development lead, directly responsible for the success of the project

The development teams are the worker ants in the grand scheme of things. They are broken up into teams based on competencies. For example, one team could be focused on the design of an application’s front end, while another team may be focused on actually implementing the functionality of the design team’s features. However, there can be even more development teams depending on the complexity of the project, making the scrum master’s role a critical one.

The development process begins with the product owner creating a vision for what they want their end product to accomplish both in functionality and design. The scrum master then works with the teams to break down the product owner’s vision into “user stories”, which are chunks of work which can be easily accomplished in a short period of time called a “sprint” ranging in length from 5-10 days. Every day, the scrum master leads a daily stand up call in which the members of the development teams give updates on the progress of the user stories they are working on during each sprint. At the end of the sprint, an update to the project is then pushed out to the product owner for review and approval. This process is continually repeated until all of the user stories are completed and the product owner’s vision is complete.

The Agile Business Case

Agile development methodologies have enormous potential for success in a regular business setting outside of technology development. Agile solves a lot of problems present in a regular business setting like diffusion of responsibility, missed deadlines, poor communication, and accountability.

The current hierarchical managerial system present in today’s businesses seems to have many loopholes that some have learned to exploit too well. Different departments blame on another for holding them back from completing a milestone. Managers invest resources out of alignment with the company’s needs, unchecked unless investigated by higher ups. Expectations of colleagues and different departments often does not equal reality on the delivery date. Worst of all, when a project fails or falls behind, it’s often difficult to figure out who went wrong, where, and when, meaning no learning can be done to improve performance on future initiatives.

Agile methodologies solve all of these problems by proposing a new organizational structure with communication and participation at its core. The scrum master keeps track of all resources tasked to an initiative regardless of department, effectively destroying organizational silos. Daily stand up calls enable higher ups to keep tabs on the progress of the project and prevent deviations, ensuring that expectations become a reality by keeping individuals in check. Sprints enable managers and product owners to actively track the velocity of their initiative based on the completion of short term tasks their contributions towards to the success of the long term goal. Sprints also enable bottle necks to be identified early on, allowing appropriate resources to be reallocated to keep things on track.

Final Thoughts

After witnessing firsthand the well-oiled execution machine agile methodologies create in the technology sphere, I believe undoubtedly these methodologies can achieve the same great success in a normal business capacity through increased communication and accountability combined with short-term goals. Agile methodologies are great for breaking the information and execution silos that impede businesses today from accomplishing long term goals in an organized fashion. Agile holds the key to organizational success in the future of business, not just technology.

What are your thoughts? How could you see agile being used in your workplace?

7 comments

  1. So glad you wrote about this! I’ve being seeing “Agile” a lot lately, especially on job postings, and I’d been wanting to learn more about it. I think it’s interesting that a lot of companies see experience with Agile as its own special skill, and are starting to look for candidates that have it; it seems to me like this a sign that your prediction is starting come to true. I hope educational institutions catch on quickly too, it would be great to learn this strategy in a classroom setting if companies are going to increasingly integrate it.

  2. Great post! It seems like scrum is becoming one of those buzzwords that everybody uses and nobody fully understands – thanks for breaking it down so cleanly!

    Of the companies I’ve studied in CSOM, I think the best example of full agile integration into general business processes comes from Spotify’s organizational matrix. While Spotify doesn’t explicitly label its structure as scrum-based, the cross-functionality and border-spanning that it encourages is pulled right from the scrum development methodologies. Spotify arranges its human capital into several basic, buildable/movable units – the most basic is the autonomous squad, which consists of 12 individuals assigned to the same business unit/goal. Squads are then combined into tribes, which have 3 independent tribe leaders (essentially scrum masters); squads are joined together as alliances, which have another layer of cross-functional and cross-reporting leadership built on top (effectively the product owners). To reduce siloing, Spotify has built borderless collaborative teams within the matrix – chapters, which bring together individuals with the same skills working in different functional areas, and guilds, which span different skills and function areas across tribes. While it may seem overly complex, Spotify’s non-hierarchical approach to team structuring has enabled it to achieve agility at scale.

  3. Great post! I had heard of Agile through Operations courses before, but this breakdown painted a great picture of what it’s all about (I also never fully understood what “scrum” was all about, so thank you for making that clear!). I appreciated how you looked into how Agile could be applied to a business setting, and not just in the context of technology development, which made it more relatable (to me at least). As you concluded, it does seem like these methodologies could work well in a normal business capacity. In my experience, communication and accountability among different departments or teams is key when you are all working towards the same goal.

  4. This is such an informative post and so often you hear companies talking about becoming more agile in their software development. The concept makes sense and the way that you’ve broken it down helps to understand all the parties involved in this type of methodology. I think one of the biggest difficulties I’ve heard with agile is the inability for certain features or changes to be implemented in a timely manner because of some misunderstandings between the Product manager/owner and the development team. I think often times, customers who may be expecting certain designs might not get the correct end result due to this communication. I agree with you that it should be breaking down silos and is an instrumental methodology to developing and improving technology over time across all organizations.

  5. This was a fantastic post and is such a beneficial read for anyone who has yet to enter the working world. I’m Scrum Master certified (one of the most useless certifications possible, in my opinion) and I’ve used the agile methodology at every company I’ve worked at since I graduated from college. All of these have been software development positions, so the agile methodology is incredibly fitting and beneficial.
    However, my experience has been that any time people follow the agile framework ‘by the book’ they are almost always setting themselves up to fail. Just like the work in an agile environment, the framework itself has to be flexible and iterative. It has to be adapted to the strengths, weaknesses, and goals of a team. One team may require a little more structure as their product is more mature while another team, focused on speed-to-market, may need less structure in order to move more quickly.

  6. Agile is great in theory but it might become tricky to implement in practice. A lot of the difficulty is in changing the way people work and if they buy-in to the new process. It’s almost as if it were some sort of Agile/tech fallacy, and that what really matters were the people (someone should write a book like that)

  7. Great post Connor! I really appreciated a deeper dive into Agile and what it has to offer. I have worked on agile teams for most of my, admittedly young career, as a business analyst, product owner, and scrum master. For software development, this methodology seems like the perfect departure from a “waterfall” methodology and creates a finished product much closer to client’s idea of what they really want saving time and money for everyone involved. The concept of daily standups is really cool so everyone is on the same page. It also allows for transparency in what everyone is doing and when roadblocks are met, gives a chance for people to help out and give solutions that the owner of that task might not be able to see at that moment. The whole idea is very collaborative and allows for consistent input from both team members and outside stakeholders. I’ve always been really interested in how this type of methodology could be applied to other industries outside of tech. It’s certainly a departure from traditional workplace practice, but even increasing communication between workers, managers, and stakeholders on a more regular basis seems like a practice that would benefit all parties. I really enjoyed the post, great job!

Leave a Reply

Please log in using one of these methods to post your comment:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: