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 real-world working sessions, 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 1940’s, building on Eli Whitney’s interchangeable parts (late 1890’s) 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 principals, 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 principals, processes, and practices evolved, adapted, extended, and now being applied in product and service development contexts, and professional services (ex. healthcare).
Regarding agile a favorite description of mine is the following: 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 are NOT agile(see Ahmed Sidky, Riot Games and ICAgile).
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). Originally simply called “just-in-time production”, TPS used kanban to implement “pull” scheduling, in contrast to “push” scheduling.
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 apply pull scheduling concepts to IT related product and service workflows, and this work continues to be developed further, as an alternative (non-prescriptive) path to enterprise agility, by a growing world-wide Lean Kanban community.
The Kanban Method’s four foundational principals and six general 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 guidence that leads organizations and teams toward first stabilzing their product and service development workflows, then toward estalishing a capabiity that produces observable, repeatable, measurable, and predictable delivery of value (flow).
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, resource allocations, project funding, delivery schedules) to continue being performed as 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 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 (eXtream Programming), one of the earliest agile software development methodologies, were developed prior to the Agile Manifesto, during the 80’s and into the 90’s. 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 set of values, principals, 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 expaned well beyond the community that developed it, today the advice is typically to start with the small core of practices (test-drive development, pair programming, refactoring, and simple design), then add other practices as profeciency and learning are developed. A number of the underlying values, principals, practices are transferable beyond the IT and software development contextand can provide signfiicant and similar 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. My 18 clients since then have included several Fortune 500 companies in online e-retailing, 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.”Bennet Vallet (via LinkedIn recommendation)
“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.”Tony Malinowski (via LinkedIn recommedation)
“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…”Leida Bell