Learning to Learn
Today’s rate of change in technology and business amplifies both the benefits and losses that result based on where you or your teams direct product development and service delivery improvement efforts. It is no longer sufficient to drive and direct these efforts with the upfront focus being on efficient workflow processes and technical practice skills. Competitive advantages today are coming more when process and skill improvement efforts are driven and directed by an upfront (value-driven) focus on better understanding (learning) about the quality (fitness) and delivery capacity (flow) of product and services to your clients and customers.
Exploring and Discovering
Evidence shows the businesses thriving and disrupting today’s marketplace are more often those where leaders and their teams are recognizing several key shifts occurring:
- Network structures are replacing hierarchical ones as more effective forms for leading organizations and communicating within them.
- Dissemination of knowledge and learning within organizations now occurs more in an exponential manner rather than linear.
- Collaborative and collective efforts promote diverse competing perspectives where innovations are allowed to (iteratively) emerge, cultivating insights and knowledge from anywhere in the organization, to provide competitive leverage in designing and developing products and services.
Real-world! Hands-on! Experience-based!
The coaching I deliver to help accelerate your team’s own learning capability is based on a foundation of extensive “hands-on” experience utilizing lean and agile principles, processes, practices, and related tools. This includes lean and agile experienced gained not just in a “coaching only role” but also while performing in roles such as software development director, software architect, technical team lead, and developer. This experience is the foundation of my pragmatic and practitioner-based coaching style and approach. And it is complemented by an emphasis on designing, developing, and delivering focused workshops, tuned to address specific real-world pain-points arising from your team’s development “shop-floor.”
Typically, the workshops I design and develop are 2-hour sessions (or less) and delivered in a just-in-time manner, with the learning then immediately applied in follow-up working sessions on your team’s current product and service development efforts, maximizing learning feedback from actual results. When utilizing this delivery form of focused, brief (small-batch), and just-in-time “hands-on” workshops, followed by immediate working sessions (in context where the real-world problems and challenges occur), the learning is more effectively understood, retained, and applied in the future, in contrast to multi-day classroom knowledge sharing type experiences.
Lean and agile principles, processes, and practices
For decades U.S. and western European car manufactures ignored the production methods used by the Japanese car manufacturers. As Toyota demonstrated incremental and continuous sales gains, eventually the U.S. and western European car manufacturers could no longer rationalize their market losses to other causes. The development of the Toyota Production System (TPS) started in the late 1940s, building on Eli Whitney’s interchangeable parts (late 1890s) and Henry Ford’s Model T continuous flow assembly lines (1910). As part of studying the TPS, in 1987 the western term “lean” was coined to refer broadly to the principles, processes, and practices derived from these learnings about the TPS in a manufacturing context (ex. lean manufacturing). However, my use here refers more to what is sometimes called 2nd Generation Lean (ex. lean management, lean thinking); lean principles, processes, and practices evolved, adapted, extended, and now being applied in digital and software product and service development contexts, and professional services (ex. healthcare).
Regarding “What is agile?”, early I found this description to be helpful: “Agile is a “mindset described by four values and twelve principals of the Agile Manifesto (2001), and manifested through an unlimited number of processes, practices, and tools. Implementing processes, practices, and tools, without the agile mindset the values, and principles of the Agile Manifesto is NOT agile” (see Ahmed Sidky, Riot Games and ICAgile).
Combining the above, I see lean as the philosophy for the foundational principles that guide the creation of business agility. That is, the lean philosophy provides insights into how each organization would adapt their processes and practices in ways that are specific to their business domain and unique business context.
The concept of “kanban” (visual signal or signboard used to regulate flow) has been around for some time, gaining greater awareness from the study of the Toyota Production System (TPS). TPS, originally simply called “just-in-time production”, used kanban to implement “pull” scheduling (in contrast to “push” scheduling) as a means to developing a JIT capability.
Pull scheduling seeks to balance the intake of work to the measured capacity of a workflow system and is central to the Kanban Method’s demonstrated ability to create smooth (even) and predictable flow of outputs in the development and delivery of quality (fit for purpose) products and services. David J. Anderson (see book titled “Kanban”, 2010) was one of the earliest (2004) to
The Kanban Method’s three agendas, nine foundational principals, and six general (core) properties/practices do not constitute a specific product or service development framework, process, or methodology. Rather, they provide a minimum of guidance in the way of enabling constraints, and controls to create meaningful and needed focus for organizations and their teams on where to effectively direct evolutionary and continuous process improvement efforts on current product and service development frameworks, processes, and methodologies, while allowing the maximum flexibility on how to implement them in their specific context.
The “Agile Manifesto” arrived (2001) with its initial focus on creating an “agile mindset” in the development of software. About this same time lean management and thinking started expanding beyond its manufacturing roots and emphasis on simple waste elimination tools, into product and service development, and professional services and a shift toward a focus on improving value-creation.
The Kanban Method’s general properties/practices reflect this as well with guidance that leads organizations and teams toward first stabilizing their product and service development workflows, then toward establishing a (flow) capability that produces observable, repeatable, measurable, and predictable delivery of value (Stabilize -> Flow -> Pull -> Improve).
An effective implementation of this general guidance would also require organizations and teams incorporate the use of value-adding related metrics (measurements), such as their customer’s experienced end-to-end product or service delivery time (lead time), their current product/service delivery capacity (product/service delivery flow rate), in addition to related quality metrics (ex. return/cancel rates), and customer satisfaction metrics (right product/service, right time/place, right price/quality).
Agile Planning and Management
While the words “Iterative” and “incremental” are not explicitly stated in the Agile Manifesto, the notion of iterative and incremental development is definitely embodied in the “agile mindset.” Working in an iterative and incremental manner allows organizations and teams to leverage learning from a previous iteration sooner, or even immediately, in a subsequent one, and the ability to respond to external information that only became available recently. However, nothing in the “agile mindset” limits the notion of iterative and incremental to design/development and build/delivery activities and outputs.
While transitions to using iterative and incremental approaches for the design/development and build/delivery activities at the team levels are frequently observed, it is not uncommon for planning and management activities and their deliverables (ex. budgets, capacity allocations, project funding, delivery schedules) to continue being performed as a one-time (single iteration), big-batch (single increment) immutable outputs, never updated in response to learning or new available information. This “mismatch in frequency” often contributes to an inappropriate application of “just-in-case” thinking during the annual planning events, which in turn swells the intake demand, overloading (congesting) and choking the product and services development and delivery capability of many organizations. The result, as the year-end approaches, is often little or poor value delivered and little or no predictable flow to customers.
Addressing this “frequency mismatch” is one of the challenges organizations and teams must address to fully leverage the benefits (increased cycles of learning and value delivery, and greater strategic business agility) of an iterative and incremental approach. Pull scheduling and portfolio-based/probabilistic forecasting (vs project-based/average-based estimates) are some of the tools being effectively used to leverage the higher frequency of learning events and opportunities to respond to new just-in-time information.
The foundations of XP (eXtreme Programming), one of the earliest agile software development methodologies, were developed prior to the Agile Manifesto, during the ’80s and into the ’90s. In essence, its early use and development served as a testing ground for applying an “agile mindset” in developing software, and a number of the values and principals later reflected and captured in the manifesto.
It consists of a small set of values, principles, and practices (originally twelve, now thirteen by some counts). Initially, teams were coached to apply all practices (or it wasn’t XP). As its use expanded well beyond the community that developed it, today the advice is typically to start with the small core of practices (test-driven development, pair programming, refactoring, and simple design), then add other practices as proficiency and learning are developed. However, a number of the underlying values, principles, practices are transferable beyond the IT and software development context and can provide significant and similar “lean thinking like” benefits.
My professional background
Over 30+ years in the IT domain, my roles have included several employed positions such as GIS specialist, numerical analyst, database modeler, computer services group director, LAN administrator, developer, technical team leader, software architect, and director of web services team. While self-employed from 1996 – 2002, I provided custom software development support to 17 clients.
Later in 2002, in a leadership employee role, I began learning about lean and agile, helping our software development teams transition to these new ways of thinking and working. After returning to self-employment in 2009, I’m now focusing on sharing my extensive hands-on experience with applying lean and agile principals, processes, and practices, by providing embedded coaching complimented with developing custom workshops tuned to my client’s most critical, specific, and immediate needs related to their software and IT product and service development efforts.
Since then I’ve provided 20+ clients with numerous 1-day workshops, 2-3-day training classes, and 3-12+ month coaching/consulting enagements, including woking with state governments, and several Fortune 500 companies in online e-commerce, tele-com/cable, financial and insurance services, healthcare supplies, medical devices, and pharmaceuticals.
What clients and colleagues say!
“Based on our experience I can say that Frank is the real thing. His knowledge and expertise of Kanban, metrics and Agile practices, in general, has been invaluable…ability to connect with folks at all levels…willingness to do whatever is needed to make his customer’s successful.”
“I had the pleasure of working with Frank for more than 7 years…on multiple project teams….during our transition from a Traditional Plan-driven development approach to Agile and Lean , Frank was a major influence on the organization, and myself…Frank appreciates when his knowledge and interpretations are challenged, and he utilizes these conversations and differences of opinion, to expand his knowledge, as well as to educate others.”
“I would just like to share what a positive influence Frank Vega has been…his style, how he adapts to different personalities, how he manages to get people thinking differently – I really want his leadership to also know how much we value him on this program. He has made such a positive contribution…”