Allen Holub
Agile Architecture and Transformation
Berkeley, California, United States
Allen Holub (http://holub.com, @allenholub, allen@holub.com) is an internationally recognized software architect and organizational agility consultant. He speaks internationally about these topics and related implementation technology, like microservices, and provides in-house training and consulting in those areas. He excels at building highly effective software organizations and designing and building robust, highly scalable software suitable for agile environments. He's worn every hat from CTO to grunt programmer.
Allen is widely published. His works include 10 books, hundreds of articles in publications ranging from Dr. Dobb’s Journal to IBM DeveloperWorks), and video classes for agilitry.com (Agility with Allen) and for Pluralsight (Swift in Depth, Picturing Architecture, Object-Oriented Design) and O’Reilly (Design Patterns in the Real World).
If you'd like to chat about working with Allen, set up an appointment at https://holub.com/chat.
Area of Expertise
Topics
What is a microservice?
"Micro-services (small self-contained modules, often remote, to which an application delegates work) solve many common problems, from multi-threading to demand-based scaling. They also provide an almost ideal architecture not only for web-based applications, but also for all systems developed using agile principles. Though a micro-service architecture is often associated with distributed applications, they're equally suitable for use systems that will never see a network, and they are very robust in the face of change.
You don't make microservices by breaking up a monolith into little chunks and dub the ""services,"" however. You need to program them in completely different ways than you might be used to.
Building a service is not a simple matter of putting an HTTP-based REST interface in front of a chunk of code. The service interface has to be carefully crafted, and the service itself must be lightweight, decentralized, secure, fault tolerant, transactional, and be vendor and language neutral. This session shows you how to build a service that does all that.
In this session, learn what a microservice is, how it has to be structured and how it communicates with other services and the outside world. You'll also learn about service architectures and how they do (and don't) integrate with various technologies such as Docker."
Visualizing Work
At the center of agile practice is the notion of information radiators. Everybody needs to see where we want to be, where we are, and where we're going, and for planning to be truly continuous, we need that information out where we can see it, not burried in some computer somewhere. Traditional metrics, such as KPIs, don't really work in and Agile world.
Solve this problem using a three-prong approach: physical card walls, effective charts and graphs, and appropriate metrics. This session looks at effective ways to use all three of these tools (and also covers some of the ineffective variants like burn-down charts and velocity as a metric).
War is Peace, Freedom is Slavery, Ignorance is Strength, Scrum is Agile.
More and more, some of the central figures in the Agile world have become convinced that Agile, as implemented, isn't working. Faux-Agile (or Dark Agile) implementation abound, and these not only don't work particularly well, they do many things that fly in the face of the original agile principles.
For example, at the very top of the Agile Manifesto is the statement ""Individuals and interactions over processes and tools,"" but the word ""agile"" has come more and more to mean rigid adherence to specific processes and the tools that support those processes. As Andy Hunt said ""Agile has come to mean do half of Scrum badly and use Jira.
This talk looks at the state of the agile community as it moves away from the basic principles agility, at how we got to that state, and at what we need to do to fix things (or get off on the right foot if you're just starting the journey).
Slack: Doing more by doing less.
Keeping people working at "100% capacity" actually lowers productivity, just as filling in wait times with other work and hiring "rock-star" programmers lowers productivity. In this session, you'll learn why this is the case, and how to maximize productivity by doing less. You'll also learn the basis of the Theory-of-Constraints thinking and other core Lean concepts that apply to software construction. This is an "everything you know is wrong" kind of session, where "common sense" is not doing you any favors.
Practical Micoservices
In this day long class, you’ll learn everything you need to build microservices for the real world. You’ll learn both the nuts-and bolts implementation details and also the Agile Architecture techniques you need to develop effective service APIs and good structure.
Server-side monoliths (single programs that provide all back-end services) just don’t work. They are hard to build, impossible to maintain, difficult to test and deploy, and gradually accrete so much baggage that forward development slows to a crawl. Agile development is impossible over this sort of system.
Microservices – systems of small, co-operating server-side agents – solve these problems, but building a microservice system is not as easy as you might think. They’re nothing like typical web (SOA) services, and getting it wrong is both disastrous and expensive. Many things you think you know about server-side programming are just inappropriate in this context.
This class is a deep dive into practical microservice architecture and implementation. You’ll learn lots of practical details and common pitfalls that can cause you months of delay or even outright failure. You’ll learn everything you need to be successful building platform-independent, vendor and language neutral microservice systems. You’ll learn about optimal microservice architecture and principles, appropriate service-API and UI design, effective interservice communication, and robust failure-handling techniques. Leverage this knowledge to build robust and resilient, secure, platform-independent services with no false starts and rework.
Practical Incremental/Evolutionary Architecture: Design by Coding, Event Storming, Mob Programming
More and more, we need to design systems incrementally as the system evolves rather than in one giant up-front phase, and our designs must still be coherent and able to easily stand up to the stress of changing requirements. We have to design effectively while we're building. These facts are particularly true in the microservice and Agile worlds. This hands-on workshop looks at both theory and three practical techniques: Design by Coding (DbC) is a way to design incrementally literally while you're coding, and doing that in such a way that you get an optimal design and architecture. DbC is an evolutionary approach based on TDD, and is particularly effective in a collaborative environment. We also look at Event storming and DDD, a way to implement complex reactive systems such as choreographed microserivce systems.
This hands-on workshop takes you through the entire process. Starting with user stories and domain analysis, we'll create a system metaphor to ensure architectural coherence, identify key abstractions and bounded contexts, and then construct a system incrementally, coding and designing in parallel. The result is a coherent and highly maintainable system and architecture that can easily accommodate changing requirements. We'll also use (and you'll learn about) mob programming and other contemporary Agile practices that will greatly improve both your effectiveness as a programmer and the quality of your code."
Practical Event Storming and Domain-Driven Design
More and more, event storming has become a critically important tool in the architect's palate. It is a way to simultaneously collaborate with business people to understand the problems that the business has to solve and to develop an architecture for the solution. Along the way, you discover the entities, bounded contexts, and events that are essential for an effective choreographed microservice (or reactive) architecture. This session is an in-depth look at event storming and the underlying concepts (from Domain-Driven design). It includes an extensive hands-on demo of the process. You'll come away from this talk with a solid understanding of how event storming works and how to apply it.
Mob Programming and #NoEstimates: New Trends in Agile Practice
The Agile Manifesto starts with "we are uncovering better ways of developing software," not "we have uncovered." Agile is a fluid and evolving thing, and two of the most exciting practices that we've uncovered in the past few years are Mob Programming and #NoEstimates.
With Mob Programming, "the whole team [literally] works on the same thing, at the same time, in the same space, at the same computer." Mobbing is a startlingly effective way to work, with teams typically accomplishing way more than they do working separately. Mobbing leverages group intelligence and extreme collaboration, to accomplish amazing things. Once you've done it, there's no going back
#NoEstimates is a new way to plan. Rather than guessing (and all estimates, especially story points, are guesses), you use continuous value-based projections and hard measurements. It's a proven technique, much more effective and much less time consuming than traditional or story-point estimation (which is, after all, based on waterfall thinking), and much more valuable to the business.
This session looks at both of these practices. You'll learn what mob programming is, how to be successful at it; at how to create the conditions where mobbing is possible. You'll learn how to plan without traditional estimation in a way that's both more effective and more useful to the business than the traditional approach.
Mob/Ensemble Programming and TDD Workshop
In Mob/Ensemble programming ("mobbing") the entire team works collaboratively at a single computer. It's a remarkably effective way to work in both in-person and remote environments. The program goes together faster and is vastly higher quality than you'll find in an isolated-individual way of working. You don't need PRs or code reviews because the code is reviewed as it's written. Ensemble programming is also much less stressful than traditional Agile collaboration techniques like pair programming. (Pairing is like going on a first date, while mobbing is like a relaxed dinner with friends). It's well-suited for introverts.
Test-driven development is a similarly effective way to work and integrates nicely into an ensemble environment. Think of TDD as a way to design by example. You start with an example of how you expect to use code that you're about to write. (They call it a "test," but it's really more of an executable specification). You then implement the code needed to get the example to work with a series of small iterative steps. TDD yields the simplest, minimal solution, so the resulting code is easy to maintain and change over time.
In this class, you'll learn to use TDD while working in an ensemble. You'll learn:
What is mob/ensemble programming?
Mobbing anti-patterns and how to fix them.
Tools and the environment (mob.sh, timers, remote mobbing).
What is TDD (and related approaches like BDD)?
Inside out vs. outside in. (London vs Chicago styles)
Mocks, spies, and fakes, with and without frameworks.
Doing it (a half-day exercise).
Incremental Architecture. Domain-driven systems that welcome change.
The most effective, lowest cost, lowest risk way to build an effective product is incrementally, one small bit at a time. That thinking applies to everything from product design to architecture. Nonetheless, some still think that a waterfall approach—you must have a product design before you pick an architecture; you must have an architecture before you start coding—is mandatory. It's not. In fact, that approach pretty much guarantees a product that does nothing useful built on top of an overcomplex architecture that slows development and is resistant to change. When agility is required, a big up-front architecture slows you down to the point that even trivial changes are insanely difficult.
In this hands-on workshop, you'll learn how to develop a coherent architecture incrementally as the product definition also evolves in small increments.
You'll learn how to build around a domain-focused metaphor that allows for incremental changes while maintaining coherence throughout. You'll learn a complete process for designing incrementally, starting with user stories and ending up with code. You'll come away with a solid understanding of how to build incremental-friendly architectures (and products).
You'll learn:
* The inspect and adapt cycle.
* The MVP
* The Architecture/Product-Design fit (they are the same thing)
* Using the domain for architectural coherence.
* User Stories (are not what you think)
* Architectural TDD
* Design by Coding and Declarative APIs
* Domain-Focused approaches (including Domain-Driven Design)
* Event Storming for creating choreographed systems.
* Incrementally friendly architectural pattern
Getting Buy-In: Overcoming Larman's Law
Larman's Law (https://t.ly/fNGz_) states "Organizations are implicitly optimized to avoid changing the status quo…" The 3rd law is particularly relevant: 'Any change initiative will be derided as “purist”, “theoretical”, “revolutionary”, "religion", and “needing pragmatic customization for local concerns” — which deflects from addressing weaknesses and manager/specialist status quo.'
To use innovative approaches like no-estimation or mob/ensemble programming, you need to overcome that resistance.
Devs, however, almost always go about that the wrong way. Senior management is rarely interested in the mechanics of what you're doing. They're interested in the bottom line, in how the new approaches change the way the business is managed, in whether the inevitable disruption is worth it.
In this session, you'll learn how to convince the “suits” (and your clients) that innovation is a good thing. You'll learn how to create a business case for innovation that overcomes the resistance of Larman's Law.
#NoFirehoses: Getting the work under control
In many companies, new work is a chaotic firehose of demands coming from all sides. Everything is highest-priority must-be-done-yestderday. You have a "critical" backlog so deep it will take years to complete, but the firehose of new work makes sure that you'll never work on anything in that backlog. Work is pushed directly onto the devs by Product or upper management with no regard to what can actually be accomplished.
In this session, you'll learn how to fix all that. You'll learn how to get a smooth and predictable flow of work that gets the moist valuable stuff into user/customer hands as quickly as possible and eliminates the typical conflict between Product and Dev.
From Stories to Code: Creating Software Products with Agility.
Agility (not "Agile") is essential in modern software development. We need to build products that people actually want with minimal effort, and we need to easily adapt to customer needs as they arise. By building around the user's story (not ours) we guarantee that our products actually do what our customers want. We create high-quality software that easily accommodates change and we get it into our customers hands sooner.
In this practical workshop you'll learn how to create user-focused products with agility. You'll learn what stories are, how to capture them, how to plan around them, and most importantly, how to turn them into code. This workshop is about the practical steps of creating software, not about meetings and ceremonies and the other ineffective nonsense that that words like "Agile" bring to mind.
You'll learn how to:
* build a culture of agility.
* create organizational structures that support agility.
* manage and plan around story-based development
* estimate (or not).
You'll learn
* what User's Stories actually are.
* how to define the problem we're solving.
* how to capture (not "write") stories.
* how to refine and size stories into bite-sized chunks.
* how to build a change-friendly domain-focused architecture.
* how to write the code with agility, translating directly from the stories.
We will not waste time talking about about ineffective canned processes like Scrum, which are the antithesis of agility.
You will come away with a good understanding of how to build great software products as effectively as possible.
Practical Event Storming and Domain-Driven Design (Hands on)
Domain-focused design, where the architecture of a computer system directly models the architecture of the business system it implements—is at the center of contemporary architecture. It's central, not just to microservices, but also to the component and modular structure of all systems designed for incremental growth—even monoliths. These architectures are also central to Agile ways of working because they're easy to change as we learn.
Event storming is a powerful technique for designing those systems (and it's also quite valuable for business analysis).
In this hands-on workshop, you'll learn how to develop effective Domain-Driven architectures by actually doing it. We'll be working on actual problems from your own work, and will go through the entire process from end to end. You'll learn how to create an effective Domain-focused architecture that can easily grow incrementally along with your system.
Included topics are:
What is DDD?
Modeling—computer systems that reflect the real world.
Bounded Contexts, Aggregates, and Entities
Event-driven (choreographed) architectural patterns
Messaging systems
Event Storming (an extended example)
Event Storming (hands-on half-day exercise)
You will come away from this class understanding how DDD architectures work and how to build them.
DbC (Design by Coding): Applying TDD principles to architecture.
Design by Coding (DbC) is a way to develop an architecture incrementally as you code. It builds on Test- and Behavior-Driven-Development techniques, but adds a focus on the 'story' that's central to all agile processes. The process answers the question of how you can build a coherent agile system incrementally, without a formal up-front design process, and addresses a common failing of standard TDD: losing track of the big picture when you focus on incremental improvements. DbC provides a way to both design and develop systems that model the story very closely, resulting in a system that's can handle volatility with ease. The technique is also perfectly suited for building effective and minimal microservice APIs. Since your code is effectively your design artifact, DbC also eliminates the need for a separate design phase in the development process.
We'll do a live demo of the process in class.
Creating Architecture from Patterns
Large systems tend to leverage one of about a dozen common architectural patterns—ways that architectural components are organized and interact. Those patterns run from traditional structured monoliths to modern Microservice-based systems.
In this class, you'll learn how to develop architectures using a patterns approach. We'll discuss how to choose patterns using system characteristics ("ilities"), and we'll look at several common patterns, explaining how the patterns work, their benefits, and their problems. The patterns approach is particularly useful when you're starting a new system for Agile development because it quickly lets you choose a basic structure and actually get to work.
Choreographing Microservices
"This talk covers the ins and outs of choreographed microservice systems in depth, looking at everything from architecture and implementation details to design techniques.
Choreographed microservices talk to each other asynchronously, blindly broadcasting notifications into a service cloud. Those notifications are handled by whatever client services are interested. These systems eliminate many of the problems associated with orchestrated systems (which work more like synchronous function calls) and are typically much faster than orchestrated systems, but they have their own idiosyncrasies and implementation challenges. This practically-focused session explores the inherent problems in orchestrated systems, and then looks at how choreography can solve those problems. Three approaches to choreography: http-based, pub/sub messaging based, and brokerless swarming systems. We’ll introduce appropriate messaging architectures and frameworks and look at several practical examples. Finally, we'll look at Event Storming: one of the best approaches to designing choreographed systems. You'll come away from this session understanding both why you should be using choreography for most high-level APIs and how to design and build these systems.\"
Agility (#NoAgile)
Andy Hunt, one of the signers of the Agile Manifesto, characterized what Agile has become as "do half of Scrum badly and use Jira." In fact, neither Scrum (even if done right) nor Jira has much to do with being agile. It's agility—the ability to welcome change whenever it's needed (even while we're working)—that's important. Agility infuses every aspect of you you develop products, from company culture, to planning, to the way you construct the software. No boiler plate methodology or framework gives you that.
This seminar (and it's a true seminar—a guided discussion in which questions can get answered and we can learn from each other) will explore what Agile is, what it isn't, and how to get from fake Agile-in-name-only to the real thing. There will be a few slides when we discuss process, but mostly, we'll be doing a deep dive into the Agile Manifesto (agilemanifesto.org) and Allen's "Heuristics for Effective Software Development Organisations" (holub.com/heu). We'll cover everything from theory to practical application—what truly agile organizations actually look like.
We'll also look deeply at what goes wrong, at how things like Sprints and backlogs and estimation lead you down the garden path to failure and what to do instead.
#No
#NoEstimates, #NoProjects, #NoBacklogs... More and more, basic practices in the Software-development world are being questioned. Agile processes have become pervasive. Nonetheless, most shops that call themselves Agile are failing to reach the potential they expected because they're following obsolete practices by rote. Story points, for example, are in widespread use, but Ron Jeffries, who invented them, strongly recommends against using them. Other practices like a fixed timebox (Sprint) and even a backlog (#NoBacklogs) are of questionable value.
This highly practical talk looks at the many accepted practices that don't work as well as you thought, and presents practical alternatives that achieve better results.
Allen Holub
Agile Architecture and Transformation
Berkeley, California, United States
Please note that Sessionize is not responsible for the accuracy or validity of the data provided by speakers. If you suspect this profile to be fake or spam, please let us know.
Jump to top