Welcome to Bradgile.com! This is a beta version of the site as it decides what it wants to be when it grows up. For now, it is an informational resource composed by Brad Nelson around "Agile" with a capital "A." The information here is a culmination of Brad's experience and studies in Agile Software Development (XP, Scrum, Nexus, SAFe, LeSS, Kanban, Lean, Modern Agile, and DevOps), Product Management, and User Experience. New content will be added, in no particular cadence, and current content is apt to change (as it already has). Also feel free to checkout my articles on LinkedIn for more free information. Thank you for stopping by and please reach out to me via the provided contact and social media links with any questions.
The Agile Mindset
The Agile mindset is a way of thinking and acting, focused heavily on organizational culture. An extension of Lean Principles, the focus of Agile is to deliver value to the customer (as defined by the customer) and continuously improve the ability to deliver that value by eliminating waste and relentlessly learning. Through an iterative and incremental approach, centralized cross-functional teams are able to optimize the flow of value by ensuring the validity of the solution as they go, while maximizing the amount of work not done (eliminating work that does not add value) through constant feedback.
Empiricism
Agile and Lean are founded on empirical process control, or empiricism. Empiricism is the theory that the only knowledge humans can possess is based on experience, with an emphasis on evidence. It is a fundamental part of the scientific method, the core building block of all natural sciences. The scientific method is a process of validating all hypotheses by observation, and is represented as the Deming Cycle (PDCA) in Lean. This means that, although a person may come with professional experience and knowledge, empiricists understand that every company, product, and situation is unique, and therefore will not be satisfied until results can be verified. Through empiricism, agilists know that the most effective way to validate, learn, and innovate is through experimentation with proper attention to the process.
Empiricism requires an emphasis on and diligence around transparency. In order to effectively inspect and adapt processes, tools, products, etc. there needs to be clear and easy access to all available knowledge in relation to the subject of inspection. This is essential, and necessitates disciplined organizational skills, effective communication, emotional maturity and psychological safety. Likewise, transparency, inspection and adaptation are key to identifying and eliminating processes that the customer does not want to pay for - better known as “waste.”
The Three Ways
The easiest way to remember and implement the Agile mindset is by following the “Three Ways.” The Three Ways are the values and philosophies that frame the processes, procedures, and practices of DevOps, as defined by Gene Kim, Kevin Behr, and George Spafford in The Phoenix Project. They are as follows:
- The First Way: Fast Flow emphasizes the performance of the entire system to deliver customer value as quickly and frequently as possible, as opposed to the performance of a specific individual, department, or work.
- The Second Way: Feedback Loops is about shortening how long it takes and amplifying the ability to receive feedback so necessary corrections can be made as needed to improve quality and sustain the fast flow of value.
- The Third Way: Continuous Improvement is about creating a culture dedicated to improving by understanding that learning comes from experimentation, risks, and failures, while mastery is achieved from repetition and practice.
The Eight Deadly Wastes of Agile
Waste: a process that a customer does not want to pay for.
These are the main areas of waste that Agile attempts to eliminate or mitigate (think of them as the 8 deadly sins of agility):
- Incomplete Work: In Agile, there is no partially done work, it is either done or work in process (WIP). Even if work is moved back to the backlog, time, effort, and resources have been invested with no return. Likewise, Kanban teaches us the cost of too much WIP, which can bring the delivery of value to a halt, introduce delays, and ultimately increase development time. Too much work in process also lends to a reduction in code quality due to unaccounted for changes after the item was originally started and the nature of software development, which is complex and requires a developer to have long periods of focus and a comprehensive understanding of the systems being worked in. When a developer is not given this time, they are likely to overlook things or make mistakes.
- Handoffs: The more people that touch an item, the more expensive that item becomes. Optimizing the value stream and team workflow can reduce unnecessary handoffs. Automation can also be leveraged to reduce the need for unique skill sets to be involved by automating easily repeatable steps through the use of standardized work and appropriate tooling. Smaller teams of cross-functional skills are proven to reduce cycle time and work by bringing everyone needed to complete the project to the table. This reduces delays from handoffs between teams and departments, work required to support these handoffs, and rework incurred due to a lack of understanding or delays. Likewise, a holistic approach can be created upfront with a shared understanding of the solution.
- Waiting: Cross-functional, centralized teams reduce external dependencies, and ultimately waiting. When a developer has to wait for an external party, they oftentimes start new work, resulting in context switching and effort spent on a potentially less valuable item. Similarly, when the developer receives the code back, they may have forgotten or mixed up some key context. This can also occur internally, therefore limiting the WIP of both work items and code branching ensures that items are addressed in a timely fashion. Similarly, agilists steer clear of a toll-gated approach, attempting to engage all disciplines when possible, and reduce the cycle-time of phases. The sooner new functionality is tested, the sooner the developer can receive feedback on the quality of the change. This is done via coding practices like continuous integration, smaller work items, automated tools, and limiting WIP. In the same way, new functionality cannot be validated until it is in the hands of the user, and therefore, teams should release to production as frequently as possible. Not only does this validate the perceived value and sooner realizes a return, but it negates technical debt incurred by code becoming obsolete or being impacted by other changes. A team may employ time-boxed iterations and/or continuous delivery practices to combat this.
- Extra Features: The reality is that there are a lot of features in software that are not being used and/or add no value. Supporting unused features that cost hosting resources, require bug fixes and regression testing to deploy new features is a waste. Actively monitoring features allows teams to improve or sunset these features. Similarly, a minimum viable product (MVP) model reduces the chance that these features will reach production in the first place. Employing product thinking and business design not only increases the chances of building the right thing the first time, through research and lower investment validation techniques, but allows organizations to realize more value from those items.
- Unplanned Work: Unplanned work is the silent killer of IT. It is ad hoc in nature and classified as any activity that is not part of the estimated work for a project, product, or feature. This includes any service interruption, failed change, defect, hotfix, patch, or security incident. It is a form of work, meaning it increases WIP, context switches, and delays. The first step to mitigating unplanned work is tracking it. From there teams can reduce defects with a test first mindset that leverages practices for built-in quality, refactoring as you go, and software craftsmanship, which promotes doing things right the first time. Lastly, implementing tools from the DevOps movement to automate testing and deployment reduces delivery time, gives immediate feedback to the developer, and removes the possibility of human error.
- Over Planning: Gathering more requirements than are needed to deliver the feature set at hand introduces waste when those requirements are ultimately changed or deleted. Likewise, building elements and widgets in code for a perceived future use is a waste, as that future may never come to fruition. This can also manifest in unnecessarily complex algorithms used in solving simple problems. Additionally, through empiricism, it is understood that no amount of planning will lead to one-hundred percent certainty. Therefore, limit overhead with a just-in-time (JIT) strategy. JIT is the mindset of doing the right amount of work as it is needed, and nothing more.
- Relearning: Relearning is the repeated learning of the same thing by the same person or multiple people, also referred to as "unnecessary movement." Building a culture where individuals are excited to share their learnings, and providing platforms for them to do so, allows organizational learning. Things that promote this are lunch-and-learns, demos, pair-programming, community of practice, cohorts, etc. Standardizing work by providing the same tools to everyone, creating templates, building libraries for reusable code, and implementing design patterns allows people to easily transition from team to team and product to product, while reducing time to learn or implement similar solutions for the same problem. Lastly, leaning on modern development tools to automate redundant work and processes eliminates the need for people to relearn these steps, new people to learn them in the first place, and the possibility of human error.
- Unused Skills and Talents: Part of a centralized team is decentralizing decision making. Agilists believe that the person most suited to coming up with a solution is the person responsible for developing that solution. Therefore, it is necessary to promote a safe environment where all employees can share their opinions and expertise. This shifts management from a command and control to servant leadership. When a person is empowered and has a clear vision and understanding of the current reality, they will strive to fill the gap between the vision and reality. This also fulfills our understanding of employee motivation, which consists of autonomy, mastery, and purpose, resulting in more engaged employees. Highly engaged employees have higher productivity and higher retention, resulting in higher profitability and lower cost for the organization.
Measure What Matters
As Lord Kelvin famously quoted, “If you can not measure it, you can not improve it,” metrics are the measurement of data related to the work. Examples of this might be how many items were completed in a given time period, how long it took an item to make its way from “aha” to “ka-ching,” and how many defects were reported. Perception often doesn’t match reality and metrics help us create transparency to areas of improvement or progress towards an improvement or deliverable. Oftentimes a snapshot of data is not the most useful, but tracking data lineage allows the ability to see trends and patterns. It also allows us to know when we've achieved our goals. As empiricism is the belief that knowledge is attained through observation, metrics are a source of observation in which we can attain knowledge. The most important thing to remember when collecting data is our inherent biases and the specific purpose for which metric is used.
Visualize Your Work
One of the top tools for creating transparency, communication, and organization is the ability to visually represent the work, ideas, and concepts. "A picture is worth a thousand words" and when dealing with the complexity of software development finding ways to visualize information can be crucial to a shared understanding (and sanity). This is commonly implemented through mapping (value stream, impact, story, etc.), visual boards, and radiators. Mapping tends to be a tool for ideation and refinement, whereas visual boards are typically used to display workflows, the work itself, and any related information. Radiators are used to radiate information, especially those attained by metrics, and may be comprised of tables, charts, and graphs.
Software Craftsmanship
Do you want the brand new iPhone or a brick phone from the 80s? Think of all of the advancements that went into being able to produce the hardware to run your software, from man's beginning of sharpening sticks, to shaping rocks, to smelting metal ore, so on and so forth. As new ways of doing things unlocked more advanced technology for humankind, so has modern development practices for software. Software craftsmanship emphasizes coding as a craft and therefore expects developers to not only create working software, but also well-crafted software. Developers are expected to hone their craft by challenging the way things have always been done and experimenting with new techniques.
