Rethinking Agile
Note: This is one chapter from a free+ mini-book I’ve written called Rethinking Agile.
We tend to think about systems from top-to-bottom when in reality it is best to work the other way around.
Agile Ambassadors
I will loosely define Agile teams as teams consisting of a compilation of product people and software engineers working to release features for a product in order to satisfy customers by solving their problems. Agile, technically speaking, is an approach to software development that can be applied to any sort of team, regardless if it is primarily focused on releasing features–what I call a feature-focused team or product-focused team. However, I am intentionally working from a practical understanding of Agile–which is its narrow application to a feature-focused team.
The product people usually consist of a product manager, UX designer, and technical product manager. Collectively, the product people are responsible for researching what the customers want, creating a roadmap to build features to satisfy those wants, and translating a roadmap of features into projects with tightly defined requirements, designs, and expectations to allow the engineers to implement the said roadmap. Individually, the product manager is the thought leader who is responsible for fusing together a happy medium between the wants of the customer and the financial goals of the company; the UX designer is the brains behind translating abstract product visions into a tangible prototype; and finally, the technical product manager is responsible for ensuring the developers set out and accomplish the asks of the product team.
The software engineers, on the other hand, work collectively to turn tangible prototypes into actual features that customers use. They are the efficient cause for bringing about the consummation of the product manager’s vision. Typically, the engineers are categorized into UI and API developers. The API developers work on building the services that are required to build the UI, and the UI developers, obviously, work on building the UI from those services.
Collectively, the product people consist of ambassadors with specific interests to satisfy the customers and the higher-ups. Individually, the product manager is the ambassador primarily concerned for the interests of the company’s financial strategy–the strategy being the domestic nation and the customers being the foreign nation of this ambassador (so to speak); the UX designer is the ambassador primarily concerned for the interest of the customers, but the financial strategy, the craft of design, and the technical interest of the developers are the foreign nations; and the technical project manager is the ambassador primarily concerned with the interests of the product manager (the financial strategy by proxy) being accomplished by the engineers, and the technical interests of the developers are the foreign nation.
Collectively, the software engineers are ambassadors with special interests to write clean, safe, creative, and inspiring code for their own sake while also satisfying the requests of the product team, with the UI and API developers each managing their respective domains of that said code yet working very closely.
The Strengths of Agile
The strength of the Agile approach is that it recognizes the close collaboration between product people and software engineers and therefore structures teams to make sure those parties have close proximity (since close proximity makes for close collaboration). It recognizes that product people and engineers both collectively and individually act as ambassadors negotiating distinct interests and emphases yet working towards a common goal that is unified with the higher-ups, releasing features to customers. Given a shared goal, the individual ambassadors working towards that shared goal constitute a shared team.
Anyone who has worked on an Agile team can tell you that this team structure is not just theoretical but practical. Communication does actually happen between the product people and the software engineers, and the close proximity is actually useful to improve efficiency. Sounds great.
The Weaknesses of Agile
Agile’s great strength is improving efficiency to collaboration between a product team and software engineers, and ultimately, getting features in the hands of customers. But, its great strength is its weakness. Because Agile improves efficiency (by which we mean short-term efficiency to release features), it has a tendency to demand this same efficiency without the necessary work outside its peripherals.
Not all technologies are visible. For example, the concept of applying a 0–100 percent score to rank one’s ability to take in knowledge and apply it is a type of technology. It has made the process of systematically ranking one’s knowledge a much more efficient process.
However, there is a bite to grading by percentages if we are not careful. That very same efficiency that standardizes grading can create a compulsion for standardized forms of education, focusing too much on the factual instead of the classic question of why? Technologies can produce greater efficiency in human processes, but efficiency is only one factor to consider in our evaluation of technology.
We must also consider the impact technology has on human interactions and whether, in the big picture, in the long haul, it is a net positive. Now, I am not suggesting that we stop using percentages for grading, but I am not opposed to alternatives. At the very least, we must consider if our standardized learning has become too efficient for our own good. The answer to the question may not be to throw the technology away but rather to refine it.
Just like grading by percentages, Agile is a technology, whether we can see it or not. It is a type of technology whereby developers can more efficiently plan, execute, and evaluate the release through smaller phases of development. But again, efficiency shouldn’t cause us to throw away discernment, to think about how technology may be refactored. The consequence of Agile is that it creates a hyperfocus on releasing features–the entire team is structured to sprint towards this goal over and over and over. There is a valid concern as to whether the constant sprinting causes developers to burn out, failing to help them progress in their own interests of building their craft.
More importantly, however, is the concern that Agile’s emphasis on releasing features via sprints creates an atmosphere where anything that gets in the way of efficiently releasing features is against the identity of the team. The catch is that such tunnel vision lacks to understanding that code quality and developer quality are valuable goals to be respected in their own right, and that code quality and developer quality do impact efficiency–just not in the length of time that we frame in our minds. Moreover, building features require other sorts of technical work to keep the pipeline afloat. When that additional technical work is in the peripherals of the developers but not the product, the Agile structure can cause a deadlock.
Read the rest of my mini-book, Rethinking Agile for free+: https://leanpub.com/rethinkingagile
