Consider this a parable of sorts for those building products. I’ll leave it up to the reader to determine its meaning.
Carl is a senior in high school and has a D in Algebra II heading into the last semester. He wants to bring his grade up to a B so that he can qualify for college scholarships. Quizzes and tests make up 80% of a student’s grade. The other 20% consists of completing homework (15%) and classroom work (5%). Carl’s Algebra II teacher, Mr. Smith, insists that Carl catch up on all his missing classroom work first, even though most of that work will not help on upcoming quizzes and tests. Mr. Smith works with his student to create a rather large yet well-defined backlog of all the classroom work Carl needs to catch up on so they can track his progress together. Carl diligently works on burning down that backlog. He finally catches up on the classroom work near the end of the school year. Mr. Smith pats him on the back. Carl’s final Algebra II grade is a D+.
The Agile Manifesto turns 16 this year. Scrum turns 22 years old. The grandfather of Agile and Scrum – Lean Manufacturing – has been around much longer, nearly 70 years with the advent of the Toyota Production System (TPS). Put in that perspective, Agile project management is not the new kid on the project management block anymore. Odds are good that an organization has adopted (or is trying to adopt) some form of Agile project management in 2017. Not only has Agile established itself as a viable project management framework for technology projects over the past twenty plus years, but the technology used on those projects and the business environment is constantly evolving, and sometimes even changing in revolutionary ways. And so the question must be asked, what does Agile project management mean and look like in 2017?
Before examining the details of what Agile project management means and looks like today, it’s important to get a baseline of what it is in general. Wikipedia does a good job of summarizing:
Agile management, or agile process management, or simply agile refers to an iterative, incremental method of managing the design and build activities of engineering, information technology and other business areas that aim to provide new product or service development in a highly flexible and interactive manner; an example is its application in Scrum, an original form of agile software development. It requires capable individuals from the relevant business, openness to consistent customer input, and management openness to non-hierarchical forms of leadership. https://en.wikipedia.org/wiki/Agile_management
While it might be tempting to jump into a rundown of the latest trends in Agile project management in regards to new frameworks, tools, and concepts; it’s important to see how Agile has evolved in relation to its values and principles. The Agile Manifesto serves as our guide. In its simplest form, the manifesto is expressed in the following value statements:
Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan
That is, while there is value in the items on the right, we value the items on the left more.
Supporting these values are twelve Agile principles, which this article will examine within the context of what they mean and look like in 2017.
Agile Principle One
Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
When major software releases were measured in years, delivering valuable software every month via an Agile framework like Scrum was considered a crowning achievement. Fast forward to today where the internet is ubiquitous, as are powerful computers in our pockets. Continuous delivery takes on a meaning all its own, with the goal being that when new features and functionality are done, they’re ready to be delivered. It’s up to the business to decide when to release, not dictated by technical gatekeepers. In practice this can look like Etsy, where continuous delivery is put on steroids and becomes continuous deployment; meaning every successful build through the delivery pipeline is released into production immediately. This approach can mean new releases go out 50 times a day! It can also look more conservative, yet nonetheless impressive, like the HP LaserJet Firmware division’s move to continuous delivery that resulted in overall development costs reduced by ~40%, programs under development increased by ~140%, and development costs per program dropping by 78%.
Agile Principle Two
Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.
Welcoming changing requirements has become more important in an ever faster marketplace where the hottest product today is tomorrow’s Blackberry phone. Even when businesses have a laser like focus on planning, customer’s needs and wants can seemingly change overnight. This need for near instant change of direction doesn’t mean a lack of planning, but rather the discipline to plan early and often; adapting to the feedback customers are providing. Roadmaps are still necessary, as we all need maps to understand where we are, what the terrain around us is, and where we’re headed. The path we take to get to the destination may (and likely will) change, but we still use the map to get there. A constantly groomed product backlog that aligns with the roadmap is a critical element of Agile project and product management in 2017. The backlog is like the turn-by-turn directions to the roadmap’s line drawn across the landscape. Both need to adjust to an ever changing environment.
Agile Principle Three
Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
Much like the first principle, the time to deliver working software should be getting shorter, not longer. The only way this is possible is to have the right level of technical automation (testing, builds, deployment, etc.) combined with tight collaboration across the various roles required to build and deliver working software. There is also a need to breakdown features into small enough pieces that can be delivered frequently. There is a high level of discipline and skill required in order to cut problems into smaller deliverable slices, both from both a technical and business standpoint.
Agile Principle Four
Business people and developers must work together daily throughout the project.
This principle can be construed as one only for startups, where the image of a small team working out of someone’s garage building the next big thing is romanticized. There is a common misperception that enterprises have drastically different needs and therefore can’t have business people collaborating daily with developers. Due to the need for delivering faster, tighter collaboration between business people and software development team members is greater in 2017 than it’s ever been before. In fact, the lines between business people and developers is blurring evermore, as the technology becomes more prevalent, business people feel the pressure to become more technically literate, and developers realize there is a difference between “coding” and “software engineering,” which means developing with the business in mind, not only the technical problem at hand.
Agile Principle Five
Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
It may be easy to dismiss principle five as common sense. Of course you want motivated individuals who have what they need to get the job done. However, there was a trend in the 2000’s to outsource anything tech related in mass. This often resulted in contractual relationships where individuals were seen as not much more than “headcount” or “resources” to be shuffled on a spreadsheet to make the numbers work better for one side or the other. Project teams, whether in-house or outsourced, need to be made up of people who are motivated, aligned, and trusted to meet the goals of delivering valuable software quickly and consistently. Smart organizations in 2017 understand the importance of people and the need to provide them with a healthy environment that motivates them and engenders a high level of trust in order to deliver valuable solutions for customers. It doesn’t matter if these people are sitting in the same building together or halfway around the world working under a contract – the same principle applies.
Agile Principle Six
The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
With more organizations employing remote workers and teams spread out across the globe, this principle is being put to the test more and more as time goes on. The days of hiring for one specific location so everyone can collaborate in the same physical space are dwindling. The advances of technology and the need for businesses to hire the best people regardless of their location translates to the need to work effectively in a distributed fashion. Organizations that take a “remote first” approach to the way they operate stand the best chance of making this work, where the tools and culture are in place to support working across multiple locations. And even though the “7% rule” (where it’s said that only 7% of communication is conveyed in the actual words said) has been debunked, these same organizations will also recognize the importance of spending time in person, and provide resources to allow project teams to gather in the same physical space in order to encourage team building that cannot occur any other way.
Agile Principle Seven
Working software is the primary measure of progress.
Gone are the days of measuring the individual phases of the software development lifecycle (SDLC) as a meaningful form of conveying progress. Working software takes precedence because working software can be used by people, and that means people can provide feedback on how valuable they find the software. The growing adoption of minimum viable products (MVP) in even large organizations only makes working software as a measure of progress that much more relevant.
Agile Principle Eight
Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
The only way to continuously deliver a product is if the approach is sustainable. This doesn’t only apply to technical decisions but how projects are managed; including how teams are formed and developed over time. Project management that places too much overhead (in the guise of being more disciplined) on individuals will not promote a sustainable development model. An example of this is the organization adopting Agile coming from a strict waterfall approach. What was once deemed necessary may no longer be so, but, due to cultural influences, may be enforced just as strongly as before regardless of its effectiveness. On the other side of the pendulum swing, project management that maintains little discipline will also not provide a sustainable model of development, as people will burnout trying to make up for a lack of consistency in how the project is managed. Examples of too little discipline can be found in organizations where there is a culture of celebrating cowboy heroics and never ending workdays.
Agile Principle Nine
Continuous attention to technical excellence and good design enhances agility.
The world of tech and software is not getting simpler in 2017. The rapid change of pace in both technology and business requires agility, and the only way to become more agile is through a continued focus on sound technical design. IoT, big data, artificial intelligence, machine learning, microservices, apps measured in the millions upon millions of active users, etc. are all technologies that are currently hot and adding to the capabilities as well as complexity of products. As mentioned earlier, HP LaserJet Firmware is a good example of an organization that refocused its attention on technical excellence and design in order to enhance their agility. The legacy platform they were building on made it difficult to move at the speed the business required. New product rollouts and features were delayed due to a technical foundation that made it impossible to respond in a timely manner. By putting in place the design, technology, and automation to deliver continuously, HP LaserJet Firmware became more capable of meeting customers’ demands.
Agile Principle Ten
Simplicity–the art of maximizing the amount of work not done–is essential.
As the quote attributed to Einstein goes, “Everything should be made as simple as possible, but not simpler.” The technology landscape is becoming ever more complex. The possibilities are endless and so are the temptations to create solutions that are unwieldy and untenable long term. For every shiny new technology that comes along promising to make your product better, faster, smarter, etc. there is a potential hidden tax in the form of additional complexity. The challenge is just as the principle states: maximize the amount of work not done. Reaching the proper balance of simplicity and technical excellence is an ongoing pursuit.
Agile Principle Eleven
The best architectures, requirements, and designs emerge from self-organizing teams.
There are a number of frameworks and philosophies catching on in popularity around scaling Agile as we start into 2017. Scaled Agile Framework (SAFe) and Large Scale Scrum (LeSS) are two of the most common frameworks organizations turn to when they want to implement Agile enterprise wide. These frameworks try to address some of the perceived gaps in Agile implementations like Scrum, XP, and even more Lean inspired practices like Kanban or Scrumban. These frameworks for scaling Agile aren’t inherently good or bad, but there is a risk that they override principle eleven by implementing such a rigid structure that self-organizing teams are a near impossibility. The question remains whether this principle is true or organizations are finding a more well defined structure brings about the best architectures, requirements, and designs.
Agile Principle Twelve
At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
The Lean Startup movement has popularized the slogan and concept of “fail fast.” The idea is that you build and test in smaller increments so that you can fail faster, thus learning lessons faster as well. Much like Thomas Edison’s famous quote implies, “I have not failed. I’ve just found 10,000 ways that won’t work.” This principle of reflecting at regular intervals coincides perfectly with a culture of failing fast. Some organizations will mistake a fail fast approach as one where failure happens early and often but little to no reflection is required. While this may seem obvious, failing early and often with little to no reflection only leads to chasing the same problems without applying lessons learned.
Even though Agile is no longer new and a hot trend, the principles still hold up today. The tactics for how to apply the principles has changed as technology and business have demanded, but the underlying principles remain the same.
Agile and Lean are old news. Everyone uses and abuses the lexicons. Have a short daily meeting? Call it a daily Scrum. Trying to deliver something in a relatively short period of time? Call it a Sprint or iteration. Have a board with post-it notes in swim lanes? Kanban at your service. Writing some tests? Call it TDD. Attempt to improve a process? Continuous improvement! Use a CI server to run a job here or there? Tell the world you’re doing continuous integration. Code on production? Continuous deployment! Meanwhile, people who list experience with Agile and Lean on their resumes more often than not talk about how painful and all around chaotic it all was. The underlying reason for this bad aftertaste is most often due to the adoption of practices without an understanding of the principles behind them.
The temptation is to read an article, watch a short video, attend a conference session and latch onto a particular Agile or Lean practice without the fuller context. This is especially popular in tech where many (most?) of us have a natural tendency to chase after shiny new objects. Instead of a collection of tools that serve their purpose within a greater context, we latch onto the hammer and start pounding everything in sight. A team struggling on a project decides to try a daily standup because they like that part of Scrum. They don’t realize the nuances behind a daily Scrum. They don’t grasp the commitment demanded by Scrum as a whole, and how the daily Scrum helps enforce that commitment. A standup is easy; building teams dedicated to consistently delivering something tangible in a short period of time is not. Every ceremony within Scrum is there because the principles drive it. Adopt one ceremony out of context and the result is less than satisfying – far short of transformative. Ditto for Lean. The practices are easy to grasp and implement poorly without knowing the “why” behind them.
Wrestling with and forming an understanding of the principles behind Agile/Lean requires perseverance. There are no shortcuts. Trial and error is expected, but not without wrestling with the reason why we’re trying to implement a practice in the first place. Racing from one good idea to the next requires little discipline. Little is learned when a practice is implemented without a grasp of the underlying principles. The failed practice is tossed out and a new one takes its place, awaiting a similar fate. The only way out of this rat race is learning why a particular framework, practice, methodology is the way it is and then identifying and carefully evaluating the problems we’re trying to solve and how the two align (or don’t.) There are no shortcuts. No silver bullets. No buzzwords to save the day.