It’s the real time story of my attempt to (use these concepts) to improve my small web design business and enjoy it more.
It’s also a spin-off of a series on the WP Builds podcast called WP Business Bootcamp where “we (that's Nathan the host and myself) are relearning everything we know about building WordPress sites and running a web design business from start to finish.”
“Agile ” is the principal theme of this blog and refers to the agile approach to managing projects. Many consider this the new norm, as it is used by a great range of industries, including governments and banks.
It’s a concept that originally came from software developers and has a strong foothold in IT and software companies like Google and Microsoft.
The missing something
I'm starting this blog because I couldn’t find anything specific to freelancers and small agencies on how to implement agile. I found this surprising, as the only website to win the prestigious design of year award (gov.uk) was created using an agile approach.
The approach itself is a reaction to the failure of traditional methods to deliver value to the customer in a more dynamic (software led) world.
The problems I frequently see in web design groups today are the same as those written about in books and academic papers in the late 1990’s which culminated in the writing of the Agile Manifesto in 2001.
The solutions I see offered to web designers today invariably seem to be ones which further reinforce the traditional model and so it continues. It is what made it difficult for me to get started.
The Web design Industry today
What I see is clients who don’t trust web designers. That's not new. In fact it made me reluctant to go in to the industry, but increasingly with page builders they can and will try to DIY it.
I see burned out and cynical designers who want to get out of the business.
Some do it by teaching others what they did. Others take courses on selling services and decide to only work with top paying clients.
(for many, that’s another issue as they need the skills to deliver the value they sell. Or they riskily hope they can buy the solutions off the shelf and get away with it).
Some, me included, have worked quicker with clients, given them exactly what they ask for. Getting out before the client realises they could have done more to realise their business aims (for example: no keyword or user testing research was done).
Here, I am going to be presenting an agile approach as an alternative. Another tool in the box. It will not be the answer to everything. I will not be setting myself up as a guru with all the answers!
I will, instead, be trying my best to apply the values in a pragmatic way to everything from finding clients to maintaining their sites.
I started to change
Over recent years I naturally shifted to agile working out of necessity without understanding the movement.
I now work more iteratively and closely with clients. Usually aiming first for a minimal viable website. Then we “circle back” with what was learned and add more in another sprint of work.
Unlike the traditional model (where projects are scoped) we assume we can’t fully know what is wanted until we start.
“Agile” itself is a mindset (or philosophy) not a methodology.
17 influential software developers put together a manifesto with 4 values and 12 principles. They, purposefully, did not say how to apply them. I expand on the 4 values in another post but here they are:
- Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan
If we need a framework to apply agile, there are several such as Scrum (the most used), Kanban and Extreme Programming (XP). Will refer to these as we progress.
But, we’ll also avoid getting fixated on what they suggest. Agile is an adjective, not a noun. It's no longer agile if we are blindly following rules, not failing and learning from it. It takes courage!
The KISS design Principle
KISS is another concept that's been echoed over the centuries and is very much connected to agile. The stupid part relates to how things break and what's available to repair them.
It really says if there are two options, always go with the simplest. This approach is at the very foundations of the Web.
It’s why Tim Bernard Lee and the W3C believe HTML should not be a programming language.
I’ve listed some related concepts to KISS that will influence this blog.
The Blog Name
The name of this blog is a play on words. We can read the domain as simpler evolutions. A nod to my ongoing business remodelling.
“Revolution” too has a double meaning:
Many see the agile movement as a necessary revolution in working practices, similarly to how technology forced the industrial revolution.
We probably need to be more aware of it in the related web design industry.
“Revolutions” describes the short cycles of iterative work done with agile working methods
Perhaps pushing this too far, we'll also be “flipping” some commonly held views on their head. Revolving them 180 degrees.
What to Expect
The content will be wide ranging and aims to be as succinct as possible.
I will be researching design and UX tips. I will be looking at simple tools of our trade. Much at the beginning will be on applying agile processes to our web design businesses. This takes some explaining as it is typically the opposite to what is taught in courses, but it is incredibly powerful.
I hope that if this finds an audience I will be able to some interviews and chat with others who build clients sites. Typically the people who are readily available have products to sell or their own media platform. Generally, they are not still "in the trenches" and ideally I would like address this inbalance.
The blog itself will be an agile project. I will learn from doing and it will change according to need.
I would love to see you in our Facebook group where we can discuss more. Also, please consider joining my mailing list. This is where I may share other resources that might not be worth a video. I'm not entirely sure yet, but I won't abuse your trust.
Join the REVOLUTIONS!
It's a web design Facebook group focussed on Agile and KISS principles to make client projects rewarding for all.
It's a newsletter!
The KISS principle is attributed to Kelly Johnson. He believed jet aircrafts should be repairable by an average mechanic under combat conditions with basic tools. "Stupid" relates to how things break and what's available to repair them. The term is often used in software development.
It's an idea that has been echoed over the centuries:
- "Life is really simple, but we insist on making it complicated" ~ Confucius
- "Nature is pleased with simplicity. And nature is no dummy" ~ Isaac Newton
- "Make things as simple as possible, but not simpler" ~ Albert Einstein
Related to KISS
Don't make me think
A book about web usability which highlights the importance of visual hierarchies, conventions, reducing noise and brevity. It's the UX version of KISS. It reminds us to start with the users needs and work backwards. In a similar vein is the “Grunt Test" from StoryBrand.
Design based on the philosophy that less is more. The idea is by removing things we can add value.
If It Ain't Broke, Don't Fix It
Don't meddle with things that are functioning adequately. There is also something known as the second-system effect which describes the tendency for small, elegant systems to be succeeded by over-engineered, bloated ones because of inflated expectations and overconfidence.
The Rule of least Power
The rule of least power is extension of the KISS Principle made specific to web technology. The idea is you use the least powerful technology that can solve your problem. For example HTML is intentionally designed not to be a full programming language.
The Pereto Principle is often know as the 80/20 rule and can be applied to many systems. For example, Microsoft noted that by fixing the top 20% of the most-reported bugs, 80% of the related errors and crashes in a given system would be eliminated. WordPress's Philosophy has an 80-20 rule that says it's core should include features that 80% or more of the end-users would use.
Minimal Viable Product
A product or service that has just enough features to put it to use. Start simple and add as needed. Related (and overlapping) processes for teams are: Design thinking (identifying or empathising with problems) Lean (avoiding over/under engineering and bottlenecks) and Agile (iterative design).
Keeping everything grounded is Pragmatism. A logical way of thinking about problems that is based on dealing with specific situations instead of ideas and theories.