Toast your Inbox.
Join the mailing list for notification of new features.
The Industries
Lawsuits
Development History
Since before the age of computers it has been important to have a process, and work the checklist. Different systems assign unique owners and influences, but in the end - the work only gets done when someone does it. Assign as much hierarchy and delegation as you'd like - some shmo has to do the work. Think pyramids, truly dedicated workers heavily motivated and committed proud of their craft often trump the best carrot-and-stick middle managers.Software Development
Enter the world of complex system and software development. Even the Niagara-falls of waterfall analysis comes with a cost.Look for reinforcement of the pyramid concept in the first Crass and Serious movie - a green triangle describing Cheep, Fast, Good: Pick two. This classic pyramid fails to address technical debt. Implying with enough money you can have all good things fast. Review NASA and their early efforts to put all code modules on 1 page each for easier human review and system simplification and THEN duplicate major systems for redundancy. I'd argue they had enough money, but narrowly met their objectives and goals before 1970. Truly good systems take time and simplification, something more resources and snappier-slappier whips fail to address; simplification of architecture.
As truly great leaders have uttered 'if it were not for the last minute, nothing would get done'. Deadlines help system engineers focus and cut through the fat blob of market share and feature creep. Don't want for those around you to simplify your systems or impose deadlines. Ask how to simplify, call fewer meetings, find fewer teammate, and push to production sooner then later.
Many great systems have stumbled into their identity through simplification; look at dropbox's early hand drawn icons (that saved some time), or google voice's human uttered tones. These engineers knew where to spend their resources and succeeded in reducing technical debt by focusing on the truly hard things, not the shiny.
Inner Domain Development
Average Sofware, Dev, Ops, Physical and Robotic Engineering, and Machine learning share a common thread - point a finger. Always direct focus outside of your domain and team for blame while retaining the credit for any advancements for yourself. I think Henry Ford did it best as he pursued not an average system, but an Excellent system by focusing not on blame, credit, carrot, stick or stock - but success. Success in setting a valuable and marketing changing product aside and consciously choosing NOT to lipstick the pig. How many colours did he offer? One. Was this because paint advancements did not warrant acceptable adhesion of the day? Likely. Was he smart enough to know that and decide to not make something of lesser value by being all things to all customers? Absolutely. Grab your history books, they are about to repeat themselves.
Skip from the market crash of the developed market in 1929 to the FANG stocks of the recent market surge. Beyond mental mind-share of the market, ask what industries are truly changing systems around you. Do you want a tastier product faster with less investment on your Part? Do we have an app for that? Do you need any of that?
Development Deflection
The proceeding mental exercise of system simplification results in deflection for truly inferior teams. If you can't beat them, join them. Join them at the bottom of blame and your 5 year plan. Techniques you'll observe in the wild of such teams includes; numerous meetings where little is acknowledged or accomplished. Time consuming review processing to focus on stratifying the landscape of whom did more, or deserves more. A focus on being busy as more important then doing something correctly, or in a manner that can be extended. Seeking vendor lock-in as a mechanic for passing the buck.
Development Market Correction
Whether your are just starting a new system, or extending an existing one, it is important to identify the scope of what success would constitute. Often in complex systems this can only be determined by the slight head-nod of the executives when they see what they like. In other more open methodologies, exhausting every key-value in the decision matrix weighing the contrasting snot out of every system will suffice. It's important to identify origin and how historic, prehistoric and vapour-ware systems within your domain have been gauged to be successful. Truly successful systems have divined this status by outlasting the competitors in a landscape of perception concluding them to be not more fit, but more robust. The best systems seek to be too simple to failure. Those are hard to find, and even more difficult to improve upon. Many landscapes seek hearts and minds (often by offering a discount to the early adopter under the pretext of their evangelism). This fails to address the fit-for-consumption of even a most basic sniff test by an intended audience. The vacuum of higher education cradle-to-grave analysis often leaves the air so thin that architects know more then their end users, and engineer a proper solution to a mis-identified problem. The market corrects these positions by seeking the next shiny solution with a failure to analyze their costs. Take for example the recent washed-up whale on an Oregon (USA) beach that when identified as a community nuisance, was voted to be exploded after the local water fowl were observed pecking at it. Post explosion, the real work was still left to be done and the market demanded to push the carcass into the ocean. Don't be the next team that invests in an explosion to be left to do the original work post party-time.
Popular Development Systems
1. Kanban
2. Agile
3. Waterfall
4. Scrum
5. Extreme Programming
6. RAD Rapid Application Development Methodology
7. Spiral
Let's explore these options in further detail and cherry pick the best attributes. It's your system. Don't limit yourself to just one good idea. These have applications beyond software developement and overlap into physical production systems and not-so-common sense.
KANBAN
We all like a good 3x5” index card or postnut note in this new digital age. A throwback to simplified and more consistent times. This system is for such affections. Seeking to minimize the cost of production, and increase produced value for the customer. Incrementally increase the rate of output while minimizing and reducing errors until the production process settles into it’s maximum profitability and volume. Seek efficient, consistent, documented, processes that have a reproducible and predictable delivery time.
The Basics
There are 5 primary stages to maximizing a Kanban system:
1. Map, Visualize and understand your existing workflow and methods.
2. Implement Work-in-Process (WIP) limits.
3. State policies are explicit without exception.
4. Track and Supervise product flow and movement.
5. Maximize and fine-tune iterations of improvement by interacting with hard data.
1. Visualize the workflow.
Map existing processes to generate and deliver product to the customer. Add a column for each step that adds value or improvement to a unit of work. In other systems, you may remember these as swimlanes. Document every step from origination to end customer and final delivery. Add additional columns to help document the flow of product through the process including wait, review, and QC Stages. These ideas are meant to be organic and flexible. Improve where you can, solidify and streamline where the flow is rigid or can be automated.
2. Apply Work In Process (WIP) limitations.
WIP constraints are to only allow a controllable and small number of work units to be in any given state ( column ) at a time. There are not hard Column cumulative limits - so this will be specific to your product. Consideration should be given to setting limits to the number of people whom can do work in a step. Work and units cannot move into the next step until there is capacity for it. This results in a process where the customer pulls work units through by generating demand' and serves to minimize WIP and stale inventory. This embraces the philosophy that doing something until it is done, and focusing on one thing at a time is efficient.
3. Make Policies explicit and without exception.
Asses required classes of service to different work units. Classes can include “Standard” (FIFO), “Expedite”, and “Fixed Date” classes. Others may suit your system. Some classes can skip to top priority with the premise that if everything is FIFO, a high cost-of-downtime unit can get stalled cued behind a low cost unit just because it was made available later. An unanticipated unit can cause other prepared work to stop, while it is processed. Demand can be separated into classes, while some units may contain additional lead times. This generates a unit flow that is more consistent and easier to manage, with capacity for increased throughput. Business and sales predictability is often more valuable then a reduced leadtime. Higher throughput is less valuable if it is inconsistent or not able to be reproduced. Some consideration should be afforded to designing a system that is not continuously maxed out such that urgent work or new work that exceeds average capacity can meet a fixed delivery date if escalated. Some systems work well with an 80/20 distribution of capacity. This can smooth production, and allow for on-demand and high-priority units to quickly navigate production.
4. Track and Supervise product flow and movement.
Focus and tune for speed and quality together. The unit of measurement to signify this is "cycle time": AKA , throughput. Cycle time is calculated by average time for a unit of work to move through the system. Throughput is the number of units that move through the system in a given time period. Some managers find a Cumulative Flow Diagram (CFD) is the best visualization but other managers have found a Control Chart more effective. Both are valuable.
5. Maximize and fine-tune iterations of improvement by interacting with hard data.
As you fine-tune the system, document your theory as to how a change will improve the system and then document your observations. Use observation and intentional change to drive your improvements. Allow your changes to run there course where you can before drawing hard conclusions. Make the change, and allow the team to use the board in that configuration for a period of time.
As to the mechanics of documenting the units of work, remember you cannot model another story 'columned process' until your first system is complete and shipped. IF WIP and Tracking are congested, seek to simplify to a shorter story. The overall objective is continuous delivery and many have found success by not overloading their senior operators and engineers but choosing instead to allow them to float to hot areas of production and put out fires with expertise and efficiency.
Overall, Kanban is an strong tool managing a process and incrementally improving throughput objectively. It rewards all of the core best practices of agile, like cross-functional teams, rapid feedback, and continuous integration and deployment. For a modern software or production team, the Kanban methodology can grow to be a welcome teammate.