The lab is an educational initiative at Coveros, focusing on agile engineering practices. It is led by Byron Katz, an experienced developer and agile expert.
When a new developer is starting out, they require strong guidance - years of mentoring and refinement. The best software practices are found through many trials and tribulations, and several years can be saved in a developer's education if guidance is provided. Here is a quote from a forum for experienced developers:
MC_Hemsy: If unit tests are expected part of software development, how come I haven't seen any at work? Is unit testing still rare even today?
lkh23o874249plhkjhdl: Unit tests are standard in most teams with decent software engineering cultures. But the reality is that decent engineering cultures are absolutely not the norm in the industry at large.
MC_Hemsy: Lucky you. I wish I had known in all of my first years of working that adding unit tests should not be a question. I went so far long without knowing it that I thought for years that this was the norm. Imagine you were born and raised in a dark cave your entire life. You wouldn't know what sunlight is. That's how I was with unit tests at one point.
Unit testing is just one of many engineering practices learned on-the-job.
To gain the knowledge for agile consulting, staff need explicit and thorough training in proper practices while creating real software in an agile team. Without this training, we must rely on new staff to already have it. It is exceedingly unlikely that our staff will accidentally become properly educated on best practices while consulting.
These reasons are what gives purpose to The Lab. We can create the ideal environment to experience unusual practices that exist only in agile. Guided by an experienced teacher, we practice agile engineering patterns in a highly disciplined way.
Practically speaking, it means we develop sophisticated software using advanced practices like paired test-driven development. We use a modern programming language, Kotlin, which is excellent for multiple programming paradigms (object-oriented, functional, etc.). It makes entire classes of bugs, like null-pointer exceptions, less possible. Kotlin also has effortless access to the entire Java ecosystem, so any library developed for Java over the last decades is easily included. (The code is at https://github.com/7ep/r3z)
We also strive to incorporate the software design process into the day-to-day development process. In contrast, the commonplace industry approach is to dedicate a role to software architecture. We merge this responsibility into the ordinary development process to empower the team to seek innovation.
We embrace the learning and innovation that only happens when failure is allowable.
By the way, there are different kinds of failure. Small failures are a necessity to success. Big failures kill the project. By avoiding all failures, companies invite the catastrophic variety.
We embrace simplicity. Systems that are built as simply as possible from the ground up are far likelier to succeed. Given the implications of Gall's law, every new layer of functionality is added as simply as possible into the working software. Our product is a success every step of the way:
A complex system that works is invariably found to have evolved from a simple system that worked. A complex system designed from scratch never works and cannot be patched up to make it work. You have to start over with a working simple system.
-- John Gall
Experience attests to the validity of this statement. One often hears about the complexity of a system as a point of pride. But admiring complexity is an immaturity; complexity slows us down and causes bugs. Practitioners must be ever vigilant for encroaching complexity to chase it down and squash it. Surprising as it may seem, simplicity is much harder than complexity, but very worthwhile:
“How long does it take you to prepare one of your speeches?” asked a friend of President Wilson not long ago.
“That depends on the length of the speech,” answered the President. “If it is a ten-minute speech it takes me all of two weeks to prepare it; if it is a half-hour speech it takes me a week; if I can talk as long as I want to it requires no preparation at all. I am ready now.”
and...
Simple ain't easy.
-- Thelonious Monk
We are also dedicated to creating a psychologically safe environment where people feel safe to ask any question and suggest any course of action.
That said, as with any group of people invested in an idea, there will occasionally be conflict. This environment will challenge us to become better at managing disagreement and to be better leaders.
Handling disagreement properly in an agile team is a ripe area of study. Without a clear resolution policy, disagreements can kill agile, even on a team of highly experienced practitioners. Since we want to simplify our educational prerogative, and because the group follows practices that will often feel at odds with common sense, the teacher is the authority in this initiative.
The only way to see the light at the end of the tunnel is to endure the discomfort of spending sufficient time practicing non-intuitive behaviors until the reason for them becomes apparent.
An interestingly apt metaphor for the agile approach is to consider it a foreign language. Many agile "experts" are really speaking their original non-agile language with an agile accent. Just how it is easier to speak English with a French accent and insist we are speaking French, it is easier to change titles and add new ceremonies and insist we are following agile.
it is critically important to empower team members, however. The teacher must create an environment where, as much as feasible, the participants are encouraged to show leadership and initiative. By the teacher monopolizing power on the team, all others are a "dev team member", working as equals. The team members conduct themselves with high mutual respect, empowerment, and trust. The students in the group may not authoritatively state how the team must act.
In fact, the lab is not an agile environment. It is an educational deep-immersion laboratory that promotes many of the ideas behind agile in a highly disciplined way. This is to build a sufficient expertise across the company so that agile becomes practicable in our consulting approach.
A consulting company needs an internal project so employees can keep their skills razor sharp. In consulting, it is easy to become blunted on the hard surface of our clients' cultures. By the whetstone of an internal project, we maintain an internal culture that aspires to a higher level.
This will help our clients and company succeed outstandingly.
If you want to build a ship, don't drum up people to collect wood and don't assign them tasks and work, but rather teach them to long for the endless immensity of the sea.
-- Antoine de Saint-Exupery