Agile for Business

Everyone likes to call themself a technology company nowadays, and we are now hearing “Agile” being used everywhere. Being agile is a good thing - it means the ability to move quickly and easily. But Agile (capital A) is a method of project management where work is divided into tasks and short phases of work to frequently asses and adapt. For example, instead of writing all the lines of code for a website and launching it, an Agile approach allows the work to be done and deployed in functioning pieces. This allows for getting to market quicker and managing the code more efficiently in cases of issues or improvements needed.

While many companies have adopted this methodology, it is rare that the agility reaches beyond the technology side of the house.

I have worked in fake-Agile environments, I have worked in pseudo-Agile organizations, and I have led teams to successfully switch from waterfall to Agile. In my experience as a product owner, when Agile is properly adopted and implemented, I’ve seen teams become incredibly efficient, fast and even happier due to the smooth collaboration.

Outside of technology, I’ve noticed a shift - people are more aware of the Agile methodology, and definitely respect it, but Agile has not easily translated to other sides of the business that would benefit greatly from it.

How many times have you defined a campaign or a scope of work or a project charter and later (months, or years down the road) the end results ends up being a little bit different? How many times have you had to adjust your strategy due to new information or priorities or obstacles?

You adapt out of necessity, and sometimes the sunny day scenario doesn’t end up happening. You are agile (lowercase a) without even knowing it. But how about being intentional about it? How can Agile be applied to your work to achieve productive collaboration, operational excellence, and quicker go to market timelines?

For a quick history lesson, back in February 2001 a group of experts on Extreme Programming, SCRUM, DSDM, Adaptive Software Development and other relevant areas met in Snowbird, Utah to talk, ski, relax and essentially just hang out, but so much more came from that long weekend. The Agile Manifesto was a result of that trip to the mountains, which has become a part of the foundation for how software development is delivered today.

The principles of the Agile Manifesto can be translated to business to improve quality, output and collaboration on any team.

Principles behind the Agile Manifesto

Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.

Always put the customer first - but, like, seriously. Business objectives are generally customer centric but business first (we gotta make some money, right? I’m looking at you, Finance). Leave some room for customer first thinking - are you looking at customer feedback? What are the exact customer pain points? Where are the areas you can improve? And improve gradually but consistently.

Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.

Allow room for change at every step of the way. Be open to iterating your plan based on facts, performance, testing and the environment. So many times we get set in our ways and want to deliver what we promised, but make sure to have the opportunity to change your plan when given new information.

Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.

Everyone loves getting things done quickly, but let’s focus on the work “working” in this principle. Make sure it works. But don’t be afraid to go to market quickly (with a working product or experience) and then learn and iterate from there. Many projects take a lot of work and therefore time, but how can we rethink our strategies to deliver pieces over time?

Business people and developers must work together daily throughout the project.

Connecting technology and business teams allows both sides to understand each other and the work. By doing so on a consistent basis, business people can better understand the constraints and limitations of the technology, and the technology teams can better understand the business goals they are helping achieve.

I know nobody wants more meetings, but a beautiful thing about Agile is the meetings that do exist are structured and efficient, and include all the right people. Each meeting has a purpose and includes the right stakeholders and subject matter experts needed to ask and answer questions, discuss designs and approach and to make decisions if needed. Imagine going into a meeting knowing that the right people are attending, there is a structure to the time, and it will be productive no matter what. Imagine!

Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.

This is the most challenging but most rewarding principle. Especially among teams that are newly adopting Agile, there are a lot of challenges in navigating change while working closer with teams you previously just handed work off to.

Everyone has their own motivations, but at the end of the day we are all people. Discover what motivates each team member and tie that to the greater goal of the team, but also put them on teams that make sense for them. Team members should feel empowered to speak up when they have a question or idea, and get the help that they need. This may mean asking directly what people need to get something done, or suggesting someone work on a project that aligns with what they are passionate about. All too often, people are afraid of a possible negative perception of asking challenging questions, or needing help that they don’t say anything.

The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.

Here is where I remind us that these principles were written 20+ years ago, and while the remaining principles can still be applied to work today, lets allow room for interpretation here.

I would replace ‘face-to-face conversation’ with ‘direct conversation’. Have more direct conversations around needs, motivation, concerns, questions, feedback, successes to build the right environment for people to thrive.

Working software is the primary measure of progress.

Again - focus on ‘working’. And I think we can all agree that a working product, service, or project is the goal. Having a meeting is not progress. Sending an email is not progress. A working output means you are a step closer to the goal. Think about the tangible things you were able to produce and launch to assess your performance. Yes, I know you had to have 500 meetings and send 10,000 emails but those do not directly lead to a working output.

Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.

The work is rarely ever done - there is always room for improvement or opportunity for the new. Sustainable development to me brings up technical debt - while a lot of software development is about building something new or adding updated features to an existing product, some capacity must be dedicated to technical debt. Technical debt refers to work that improves the foundation of the product to allow for efficiencies and improved quality over time, but doesn’t necessarily lead to new or updated functionality.

What technical debt do you have? What are foundational things that need to be done to help you do your job? What are areas you should invest in now for a more sustainable future? This could translate for some to taking classes or working towards a degree, or outsourcing tasks that take up too much of your time, or creating a powerpoint template you can reuse every time you have to put a deck together. Make sure to allow time to make these key investments that will fundamentally improve the way you work.

Continuous attention to technical excellence and good design enhances agility.

This is where I tip my proverbial hat to all the designers out there. The UX/design of a product can make or brake it. You can put an amazing back end out there but without a good, usable and appealing design, forget it. A design that can account for adaptability is key, as we rarely stick with version 1.0 of anything - since we are always improving .... right?

The same goes for all your work. The way a customer interacts with you or your work, the way your emails or presentations look, are factored in to the perception, adoption and support of your work. Even if you have to ask a favor from a designer friend, or look up some creative templates, it will be worth spending time designing how you want your work to come across visually. Studies show that people remember 80% of what they see - so make it a good memory.

Simplicity--the art of maximizing the amount of work not done--is essential.

In Agile, you simplify a big project or product into smaller pieces to allow for the small but continuous deployment and iteration of the work. When facing a complex issue, simplify it to bite-size pieces. This allows it to not seem so daunting, but also makes you focus on the pieces that really matter.

The best architectures, requirements, and designs emerge from self-organizing teams.

That means not being voluntold do to something! Can we be done with that already?

If teams are able to self-organize, the success of the team is on everyone’s shoulders, not just the manager or team lead. Companies spend so much time trying to hire the right talent - give them the right environment and structure, and trust they will thrive.

At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

This principle sums up Agile very well, basing continuous iterations on learnings and being able to adjust accordingly.

It is so easy to get caught up in all the work and all the meetings and turn on survival mode to just get things done, but how often are you really reflecting on what you’ve done and how you could do it better next time? We are so often thrown into the next thing, we don’t have a moment to recognize and document our learnings to improve. At the very least, this means not leaving feedback for the once a year performance reviews (that are too late in the process anyways). We always have something to learn from our work - whether its learning how to avoid certain mistakes, or learning what worked. Make sure to take a moment, or even schedule 30 minutes every month to write down what you learned and how you are going to apply that going forward. Maybe something from this article makes that list!