Not really sure how, but I started developing software with agile in my thirties.  I’d manage my team early in the morning, then practice law all day.  The first version of the app I made was pure junk.  You really have to understand code and software and how to make it if you want to manage a team well.  So I learned coding, and scrum, agile development principles to actually make stuff that most people take for granted and never think about using it.  That’s some well made software if the experience is expected and requires no thought.

To get to that point takes a lot of polish, lots of building, measuring and evaluating what you learned.  It forms a never ending cycle that feeds back in on itself.  Processes are refined and changed.  New dependancies, basically a skill set, may be needed for additional functionality.  Old ways of doing things need to be refactored, or revised, into more cohesive arguments (which are actually a thing in code). Paying close attention to the method (also a thing in code) used to accomplish certain goals can lead to new best practices.

Maintaining a good code base is a lot like maintaining a good law practice.  Neither are ever done and can quickly become overly complex if not tended to diligently.  These things may even be a dreaded concept known as non-deterministic polynomial time complete (NP-C).  Certain practices have been developed over the past several decades to assist in delivering a high quality project on a reasonable deadline.  But it started from managing another complex process, the assembly line.

After World War II, W. Edwards Deming brought his techniques in quality control in standardization, documentation and continual improvement to Japan’s redevelopment efforts.  Taiichi Ohno at Toyota used his own minimalistic processes to save costs and blended Deming’s elements to propel the carmaker to some of the highest quality rankings in the world.  The result is called agile, or scrum, or kanban, or Just in Time (JIT) processes which are still used in the browser you are reading this on.

In code projects, you want to break up the build into clear components that do specific things so that the whole can more easily be compiled.  This is the exact same in the legal practice where time is the unit and litigation, or documentation, the deliverable.  You break down the whole into its pieces and itemize them and attend them them individually.  The project is built as simply and quickly as possible so that it may be tested.  Then the feedback returns improvements on the methods used for delivery.  The changes to the process result in greater user satisfaction because of ease of use, greater functionality and less waste or more efficiency.   The product continues toward a more perfect version of itself through iterations of newer and newer versions.

This should be employed in your law practice for the rest of its term for one very good reason.  The legal product you ship next year will always be of a higher quality than the code you ship this year. If you employ systems to organize the product that must be shipped and document the methods used in delivering that product, this data can be reviewed.  That data also provides insight as to ways to deliver a higher quality product.

Your clients will thank you for always raising the bar of the quality of the legal product you deliver.  Plus, you can sell the value throughout the years and know that the rising hourly fee is more than worth it because of the enhanced quality.  Lots of buyers of legal product may only look at the hourly, but they should look at the processes in place by the legal service provider to know that next year they will be buying a higher quality product than what they are purchasing this year.

If your business is filled with tech and requires agile corporate immigration solutions, you can drop in on my side project for optimizing the work visa application process and data management.  Work Visas.  Or just drop me a line and let me know what your company is about.

Email Me