News & Articles

2 Upcoming PraxisFlow Workshops in Tampa, FL

Introduction to LeanUX and LeanBranding 2-Day Workshop

Date: December 8-9, 2014
Location: Tampa, Florida

Register Now

Bill Beard and Will Evans will hold an immersive user experience workshop that will teach individuals and teams how to use Lean methodology in order to save time, save money and eliminate waste while creating and marketing products customers love.

In this two-day, hands-on workshop, your team will learn cutting-edge strategies and skills used by today’s most effective companies like BankWest, IKEA, Spotify, and TIME, Inc. You’ll learn LeanUX methods for:

– Customer discovery
– Problem framing
– Collaborative design
– Multi-hypothesis testing
– Prototyping
– Solution validation
– Product branding
– Brand strategy
– Marketing
– Analytics

This bootcamp is great for anyone who needs a deep-dive into both Lean Startup and LeanUX and discover how those methods apply to customer development, branding and marketing. Whether your current processes are more like Lean, Agile, Scrum, or Waterfall – you can benefit from this immersive, affordable, two day workshop.

Because of the collaborative, systems based approach, this bootcamp is useful for strategists, designers, creatives, engineers and entrepreneurs. The bootcamp guides participants through the exploration of who the customer is, what problem they have, whether it’s a problem worth solving, and most importantly, how to communicate effectively with customers. The goal is to discover solid hands-on techniques for developing your product and brand. You’ll also learn tactics to make attendees successful when introducing these principles and strategies into their organisation.

Deep Dive into ‘The Phoenix Project’ 2-Day Bootcamp

Date: December 8-9, 2014
Location: Tampa, Florida

Register Now. 

kevin4Have you, like thousands of others read the best selling IT management novel “The Phoenix Project,” and wondered just how you were going to apply the concepts inside your own organization? This deep-dive 2-day bootcamp will allow you to explore some of the core philosophies covered in the book and the thinking, principles, and practices that underlie them. Take a peek behind the pages of the novel and into some of today’s freshest and boldest ideas on how to fundamentally change the trajectory of your IT organization.

Using a combination of lectures, workshop activities, case studies, and team-based breakout discussion groups, Kevin Behr, co-author of The Phoenix Project, will lead you through a 2-day bootcamp meant to prepare you to start to apply the principles and practices inside your organization.

Learn More. 

Lean versus the bandwagon, lean wins


I’ve just finished reading “The Phoenix Project,” by Kim, Behr and Spafford. To be honest, it was on my reading list but had I not picked up a copy at Camp DevOps I don’t know that I would have ever read the book. My main issue with books of this ilk, such as “Who Moved My Cheese” and “The Energy Bus,” is that the story is often contrived for purposes of delivering the learning points. So, I was surprised by how much I was able to relate to the issues in Phoenix giving it an air of reality I was not expecting. 

Phoenix follows the life of a new VP of IT Operations through his early weeks on the job. Plucked from obscurity as the Director of Mid-range Computing after his management chain was seemingly asked to depart the company, Bill’s eyes are opened to a world of heroics and chaos that surrounds him in IT and has had detrimental impact on the company’s financial and competitive performance. For anyone who has logically questioned, “how can that happen?” in their own companies, the authors do a great job of illustrating the paths that lead to the unimaginable outcomes we see every day in our own IT world.

Read more…

On UXDebt: The Nature and Nuance in Product Design


“In the beginner’s mind there are many possibilities, but in the expert’s there are few” – Zen Saying

Recently within the user experience design community, there has been some discussion and questions regarding the term “UX Debt,” especially what it means; under what conditions it arises; and what strategies may be employed to understand and mitigate the risk of acquiring and retiring UX debt during the software development process, mostly within the context of [Agile] or [Lean] teams charged with delivering quality software.

Last week, in a conversation initiated by Jabe Bloom, he brought up the fact that most people were unaware of the original meaning of the term Technical Debt. He went on to explain under what conditions debt arose, and the relationship between technical debt and failure demand. This article is my attempt to synthesize some of the ideas he covered in those conversations and how they might apply to the notion of ux debt. As Jabe would say, “Any violence done here is unintentional and entirely my fault…”

“No one gets angry at a mathematician or a physicist whom he or she doesn’t understand, or at someone who speaks a foreign language, but rather at someone who tampers with your own language.” – Jacques Derrida

I think that for the most part, the generally understood definition of UX debt is only telling part of the story, but I won’t go so far as to say it’s wrong. (I will clarify this later.)  Given its etymological roots in the term Technical Debt, I don’t think that is the fault of those ux practitioners who’ve sought to employ the term “ux debt” in the fashion that is currently gaining some traction.

If we return to the origin of the term, first explicated by Ward Cunningham, we must re-state the definition, because if the agile and lean [communities] don’t have a shared understanding of what the term means, then any derived term suffers a ‘fruit of the poisonous tree’ problem.

It is natural, however, to understand why the definition has drifted since Cunningham chose to employ the metaphor – but I think that metaphors by their nature have a greater semiotic distance between signifier and signified and through natural semantic drift, the word can take on new meanings never intended by the author. This is not to say that some of the new definitions of technical debt are dead wrong – merely that they have become models which, while not true, can at least be useful.

Different ontologies, or systems understood in the context of their underlying causality, require different approaches to epistemology: the way that we know things and thus the way that we make decisions. This apparent simple concept is revolutionary in its nature; most approaches to management science assume a single ontology, namely that of order.

~ Dave Snowden, Strategy in the context of uncertainty.

So how is the term Technical Debt currently used and how does that differ from the way the Cunningham intended when he employed the debt metaphor?

One well-written explication of two types of technical debt comes from Simon Baker in the post, “Inevitable and Avoidable Rework,” in which he states,

“Without really thinking about it until now, I’ve been seeing two types of technical debt. The first is the quick solution implemented with dirty code. I consider this to be irresponsible. That’s not to say I won’t do it, just that if I decide I should do it I make sure the necessary people understand the consequences and that it’s an irresponsible action to take.

The second is a natural byproduct of emergent design andYAGNI (yet) decisions. It’s the debt that surfaces when a system outgrows implementations resulting from previous decisions, which were the right ones to make at the time based on the information available (because they did not compromise quality or the health of the code in any way).”

This is different from the description of two types of technical debt that Steve McConnell writes about in this post on 10x Software Development,

“The first kind of technical debt is the kind that is incurred unintentionally. For example, a design approach just turns out to be error-prone or a junior programmer just writes bad code. This technical debt is the non-strategic result of doing a poor job. The second kind of technical debt is the kind that is incurred intentionally. This commonly occurs when an organization makes a conscious decision to optimize for the present rather than for the future.”

As we can see, there are now three different definitions of technical debt. The first kind of technical debt arises in an ordered domain when the development team or engineer understands the nature of the problem, and presumably understands how to build the software, but through incompetence, or sloppiness, writes bad code which I will label O.1. This is avoidable technical debt that the team accrues with no strategic benefit.

The second type of technical debt also occurs in an ordered domain when the engineer understands the nature of the problem, as well as how to design and build a solution that solves for that problem, but for various strategic reasons, decides to take shortcuts – we can refer to this as O.2 to distinguish it from the former. This can be for a number of reasons, for instance, when there is some uncertainty in the marketplace as to whether the given feature is actually desirable by the target customer, or because of market pressure to release something fast and gain a foothold on the competition, or resource constraints which prevent the team or engineer from building the most elegant solution.

These two mentioned above are what have become the common ways in which most people are using technical debt, and the second definition described above is the one that has insinuated its way into the LeanUX community. This definition isn’t wrong per se, but it only addresses the kinds of ux debt that arise under one set of conditions within one ontology (this is where the reference to Snowden above starts to make sense). To understand, and thus mitigate ux debt requires that we first understand which context we are confronted with, what constraints we have, and what kinds of debt we are incurring.

The third type of debt described above by Baker is the one that very few people are aware of, which is ironic since it is at least the closest to Ward Cunningham’s original definition when he leveraged the debt metaphor which Jabe brought to my attention. [This kind] “is a natural byproduct of emergent design and YAGNI(yet) decisions.” This I have labeled U1. It might be useful at this point to watch Cunningham’s explanation of debt right now before we continue any further.

As you can see, Cunningham was never referring to technical debt as the delta that arises between what the planned design for a product might be and what is actually delivered in an ordered and well-understood domain because of either poor design/engineering or because of choices to cut corners to get software out the door as quickly as possible in the situation where you already know what a good design might be. I think this nuanced difference is key. Cunningham states in this video that,

The explanation I gave to my boss is that [if] we failed to make our program to align with what we then understood to be the proper way to think about our financial objects, then we would continually stumble over that disagreement and that would slow us down which is like paying interest on a loan. With borrowed money you can do something sooner than you might otherwise, but until you pay back that money, you’ll be paying interest. I thought borrowing money was a good idea… i thought that rushing software out the door to get some experience with it was a good idea but that of course you would eventually go back and as you learned things about the software you would repay that loan by refactoring the program to reflect your experience as you acquired it.

He is describing a new domain where you are designing and building a product in an unknown space – where the nature of the problem and the potential solutions are not yet known to you, and only through writing code can you uncover the nature of the problem as well as find out whether a potential solution actually solves for that problem.

Returning to Snowden, this is problem space in the complex domain where you need to probe, sense, respond. There are no best practices in this particular situation, and it absolutely makes sense to take on the debt to gain the learnings so that you can build a better solution that solves the problem. What it also means is that once you are finished building and releasing the software, only then do you have enough of an understanding to see the debt that you have created.

In essence, you have developed a language to understand the domain better, so that you can go back and refactor the application to now reflect your better understanding. It is this example that is most interesting, and also a strategic use of borrowing — but the kind of borrowing that you can’t start paying the interest on until you have released the product. The debt, then, is the delta between your current learnings as to the best way to implement the solution based on new language, and the way that you actually implemented the design.

In exploring this over the past few days, I have come to believe it is worth reflecting upon why Snowden’s Cynefin model is essential to understanding debt, either technical or user experience. The first two definitions above make an implicit assumption that Snowden refers to when he argues:

The dominant ideology in organizations assumes that in any system, there are underlying relationships between cause and effect. These relationships can be discovered or approximated in such a way that the future can be planned on the basis of desired outcomes. Examples include the three-year plan, the commission investigating past failures and scenario planning.

The objective is to control the future on the basis of an understanding of the past. In effect, it is assumed that there is a right answer and a failure to achieve the desired outcome is a failure of analysis, data capture/distribution or execution.

Clearly, then, when you are in an ordered domain – where you can understand the nature of the problem space as well as the ‘right answer’ to solve for it, then failure to achieve could be a result of failure to execute, or in the second type of debt described above, an understanding of the trade-offs between the right answer and a strategic decision to take a shortcut, understanding that interest will need to be paid later in terms of refactoring the code or redesigning the user experience. But this is only one of three possible ontologies. The other two which Snowden introduces are Chaos and Complexity.

The desire for order is understandable and has, historically, been contrasted with chaos as an “either-or” alternative – from the age-old battle of Zeus and the Titans to the acceptance of authoritarian government or the waterfall software development methodology.

Chaos in this sense is seen as the antithesis of order: total and absolute turbulence, without form and substance. The state of order provides structure and predictability and is the object of desire, while the state of chaos is to be avoided. In this context the function of strategy is to reduce the potential exposure to chaos by reducing uncertainty.

But we must also understand that, going back to Cunningham, there are other situations when you are dealing with an unordered ontological context, one in which you don’t understand the relationships between cause and effect, when the solution is emergent by trying various implementations. Snowden describes it best here,

Such (Complex Systems) systems are retrospectively coherent; that is to say that we can see a pattern of causality with the benefits of hindsight. However, future events do not repeat themselves except by accident. The reason for this is that order in complex systems is emergent in nature, arising from the interaction of many agents.

He goes on to explain that ‘emergent order is seen in nature, from crystal formation (Camazine et al 2001) to the flocking behavior of birds,” to the social interactions that happen on Yahoo bulletin boards or the Interaction Design Association. In this case the technical and user experience debt is of a different nature because you have no choice about borrowing . It’s a part of the discovery process, and you don’t even understand the nature or scope of the debt until you have released software into the world and learned from it. This also means that whatever you may have released could in fact solve for the customer problem without necessarily creating any failure demand – it’s simple that the debt represents the delta between what you now know to be the elegant way to implement the solution, or the most usable way to design the user experience, and the way that you actually did.

In closing, I would argue that when trying to understand either technical or ux debt, it is first important to classify the problem space being explored as well as potential solution sets into one of the three ontologies: order, chaos, or complexity. This can then inform your team’s different epistemological approaches to understanding the nature of the debt, and make a more reasoned decision as to how to first choose whether to take it on or not, and if you do choose to take on the debt, what impact that will have on future development efforts as well as the potential interest payments your team will be burdened with. One thing that Jabe makes clear, however, is that in the case of emergent design, debt (ux or technical) must be incurred, but you will not be able to understand what it is, nor will you have an ability to track it, until after you have released the software and learned through usability testing and quantitative analysis.

Wired Magazine Interviews Kevin Behr


An Interview with Phoenix Project Co-Author Kevin Behr

Kevin Behr is obsessed with making improvements. In the last 25 years, he has helped many IT organizations do business better. He is the co-author with Gene Kim and George Spafford of the influential Visible Ops Handbook and more recently The Phoenix Project: A Novel about IT, DevOps, and Helping your Business Win.

Behr’s life mantra of doing things better goes well beyond IT. This active mind is now turning to science for ways to help businesses improve through constant experimentation. Behr hopes to take his work to the next level at the University of South Florida, starting a doctorate on the taxonomy of improvement science. An experimenter at heart, he talks about what it means for DevOps leads to experiment in their organizations, and how PaaS helps those same DevOps leads develop critical thinking skills.

Read Article

PraxisFlow Goes to Edinburgh for #LASCOT14


PraxisFlow goes to Edinburgh for Lean Agile Scotland! Kevin Behr, Jabe Bloom, Will Evans, and Melissa Perri will all be speaking at the upcoming LASCOT14 conference.

“First In Last Out – Devops and its roots in coal mining” – Kevin Behr

Like a child prodigy nearly every technical discipline has taken credit for some roll in developing what we call modern day Devops. Kevin will share what he found as he pursued leads that led him to study work performed by sociologists in coal mines during the WWII era. Learn why Devops is really nothing new and what socio-technical-system patterns you can cultivate to make your efforts and collaboration more effective.

“Decisions and Futures: On Designing Boundaries, Systems, and Distributed Cognition” – Jabe Bloom

Software Design and Engineering remain constrained by mismatched management models and precepts, rooted in antiquated conceptions of physical and mental work. As cycle times accelerate and abstractions encapsulate knowledge, we must begin to reconceive how management can evolve to become more effective and productive, beyond current notions of oversight, control, assessment, and impediment removal.

How is it that we can relate our intentions and actions to an uncertain, rapidly changing set of potential futures? How can we resolve our issues with the problems inherent in expertise and functional alignment, so that we can improve flow of information and value through our businesses?

Jabe Bloom will discuss modelling human systems that produce and consume knowledge, to enable distributed cognition, leading towards better decisions and intentional futures.

Design is a way of ensuring agency in the face of increasing complexity uncertainty and ambiguity -Simon Grand

“Exploration & Exploitation Mindsets in Design-Driven Enterprises” – Will Evans

Most larger organizations are able to scale and survive in the medium and long term by achieving operational excellence in driving out waste and exploiting their existing business model. The mindsets, mental models, and methods for achieving this success at scale make organizational systems fragile and susceptible to disruptive innovation. Even organizations that embrace the value of design to deliver better customer experiences are susceptible to epistemic failure.

What are the required strategic horizons, mindsets, and methods required to balance the exploitation of existing business models in context with exploring new and potentially disruptive value propositions? How can can teams collaborate at the fuzzy front-end of exploration to generate insights and explore the complex domain using design thinking? What are the portfolio concerns for managing both exploitative and exploratory strategies for continued survival and growth? How can balanced teams start where they are and iterate towards more resilient and adaptive structures to continuously improve offerings and deliver value to customers?

“Designing to Learn: Creating Successful MVPs in Agile Teams” – Melissa Perri

Using Minimum Viable Products to validate product ideas before building can save companies months of development time and thousands of dollars. The goal of an MVP is to maximize learning, but many people see an MVP as a mininum feature set. MVPs are not reckless, broken products, but rather a way for you to test your assumptions quickly and cheaply. Teams who implement Minimum Viable Products (MVPs) learn more about customers, waste less time, and deliver usable solutions faster.

In this session, we’ll focus on the fundamentals of creating an effective MVP experiment: defining effective problem and customer hypotheses, listing your assumptions and picking the riskiest one, and determining which experiment to run. We’ll discuss the differences between Lean MVPs and Agile MVPs , and the pros and cons to each.

This talk is geared towards developers, scrum masters, UX designers, and product managers.