Skip to content


Announcing the PAS Workshop: Double Your Professional Impact in 8 Weeks

Scrum Breakfast - 7 hours 22 min ago
I have created a video about my new workshop on the Personal Agility System: Double your professional impact in 8 weeks.

The online workshop starts next week. You can learn all about it here, and you'll find a special 2 for 1 offer towards the end...

You can sign up and get full information at!
Categories: Blogs

Agile Movement's parallels to Lincoln's Gettysburg Address

Agile Complexification Inverter - Mon, 04/24/2017 - 23:36
What parallels are there between Lincoln's Gettysburg Address and the state of the Agile movement's union?

Lincoln was a primary figure at the dedication of Soldiers' National Cemetery, in Gettysburg. He did not wish to upstage the keynote speaker, Edward Everett, and so summarized in 2 minutes the principle of human equality as defined by the Declaration of Independence and the Civil War.  Do you remember, the keynote speech?  Few people do.

Lincoln's Gettysburg Address:
Four score and seven years ago our fathers brought forth on this continent, a new nation, conceived in Liberty, and dedicated to the proposition that all men are created equal. Now we are engaged in a great civil war, testing whether that nation, or any nation so conceived and so dedicated, can long endure. We are met on a great battle-field of that war. We have come to dedicate a portion of that field, as a final resting place for those who here gave their lives that that nation might live. It is altogether fitting and proper that we should do this. But, in a larger sense, we can not dedicate—we can not consecrate—we can not hallow—this ground. The brave men, living and dead, who struggled here, have consecrated it, far above our poor power to add or detract. The world will little note, nor long remember what we say here, but it can never forget what they did here. It is for us the living, rather, to be dedicated here to the unfinished work which they who fought here have thus far so nobly advanced. It is rather for us to be here dedicated to the great task remaining before us—that from these honored dead we take increased devotion to that cause for which they gave the last full measure of devotion—that we here highly resolve that these dead shall not have died in vain—that this nation, under God, shall have a new birth of freedom—and that government of the people, by the people, for the people, shall not perish from the earth. - - U.S. President Abraham Lincoln
I heard an NPR story about a person that give their grandkids twenty dollars to recite the Address.  It sounded like a wonderful way to engage kids in history and the founding reasons of the existence of this nation.  I'm assuming that it would take the children some time to memorize the short speech and in so doing they would have questions, about what the words meant.  How many of your colleagues know what unit of quantity a score represents?  Do you know what happened four-score and seven years before 1863?

The foundational document of this new nation is the Declaration of Independence - signed in the summer of 1776 by a group of wealth white men.  They are now described as our founding fathers, yet some were quite young at the time (Hamilton, 21; Jefferson, 33; Washington, 44).  These free thinking people (and some were women - they just didn't sign the document) were called radicals by their government and traders by their neighbors.

Does any of this sound like a fractal of the Agile Manifesto and the movement that was started back in the 1990s with lightweight frameworks for organizing software product creation.  The desire to increase the good aspects and there by overcome the poor habits (appreciative inquiry or extreme programming - is there a difference?).

Is there a revisionist movement some 15-20 years beyond the 2001 manifesto creation?  Yes, there appears to be a constant yearning for the next wave, the next wagon to hitch your cart onto.

Are there amendments that need to be added to the manifesto much like the Bill of Rights?  Or is that a fringe movement on the periphery?

Modern agile  defining four guiding principles:

  • Make people awesome
  • Make safety a prerequisite
  • Experiment and learn rapidly
  • Deliver value continuously

Alistair Cockburn observer his communication style in beginner and advanced classes, he said: "[I] found that when I was encouraging getting back to the center/heart/spirit of agile, I kept emphasizing these four things, and drew them in a diamond:"

Could the newest technique Mob Programming be anything more than an incremental addition to eXtreme Programming (XP)?  Some 30 years in the making.

Categories: Blogs

Change Artist Super Powers: Empathy

Esther Derby - Mon, 04/24/2017 - 18:33

Some people seem to think that empathy has no place at work…that work requires a hard-nose, logic, and checking your emotions at the door. But, in periods of change, emotions—which are always present, whether we choose to acknowledge them or not—surge to the surface. Ignoring the emotional impact of change doesn’t make it go away. Rather, attempts to depress or devalue people’s response to change may amplify emotions.

Empathy is the ability to recognize and vicariously identify someone else’s experience and emotions. Empathy enables you to understand someone else’s point of view, the challenges posed by the change, what they value, and what they stand to lose by changing.

Empathizing doesn’t mean you have to feel the same thing, think the same way, make the other person feel better, or fix the situation so everyone is happy. Demonstrating empathy means you listen, acknowledge, and accept feelings and points of view as legitimate. Empathy is fundamentally about respect.

Three kinds of empathy play a part in change.

Emotional empathy, understanding another’s emotions and feelings. This is what usually comes to mind first when people hear the term. Emotions are a normal part of change—from excitement, to grief, puzzlement, loss of confidence, and anger. Too often, people who “drive” change dismiss these responses and urge people “just get on with it.”

Cognitive empathy means understanding someone else’s patterns of thought and how he makes sense of his world and events. Understanding how others think about things may help you frame a new idea in a way that meshes with their views. That also helps you—you’ll know more about the obstacles and issues you are likely to encounter.

Point-of-View empathy combines a bit of both of these, and it allows you to say genuinely, “I can see how it looks that way to you.” Once you extend that courtesy to someone, he is more likely to want to see how the situation looks to you.

Empathy provides information that helps with change in at least two ways:

You can refine your ideas about the change based on local information, which people are more likely to share when you make an effort to listen and connect with them.

People are more likely to listen to you when they feel listened-to.

The more you listen, the more you learn about the needs and values of the people facing a change. And that is the key: People rarely change because someone has a bright new idea. They change to save something they value. But you won’t learn that unless you empathize.

© Esther for esther derby associates, inc., 2017. | Permalink | No comment | Add to
Post tags:

Feed enhanced by Better Feed from Ozh

Categories: Blogs

Info Radiation vs Info Refrigeration - a metaphor

Agile Complexification Inverter - Mon, 04/24/2017 - 17:09
Is a metaphor a form of lightweight model?

"All models are wrong, some models are useful."
-- George Box
The metaphor of information radiation is quite well know to many in the software industry.  Did you ask why?  Maybe because much of our work is very hidden from view, until we run the program and the computer interprets the code to produce some desired outcome.  Even that outcome may be obscured from view, and we must produce reports upon the data that the program produced.  So in a world where smoke and mirrors are common, one antidote to the common problem of not knowing where one is along the path toward product completion, a visualization is a powerful tool.  

Generally speaking the information radiator has similar properties to the old fashion building heat radiator that used a steam media source to heat heavy iron and radiate the heat from the iron into the room.  It feels great to be standing next to a radiator when you've just come in from the cold.

What is the refrigeration process - what's required to cool some air?  Currently we use the 200 year old Carnot cycle to produce the cooling effect that your summers are known for.  I doubt that my home of Dallas Texas would be the Mecca of IT if not for Mr. Nicolas Carnot and his research into what would become air-conditions environments.  A comfortable 70 degrees indoors while the Texas sun is 95 in the shade.

Pressure-Volume diagram of Carnot cycle
I will leave the internal working of the AC unit to your study (I did it back in college - fascinating stuff).

When we put information is some systems we encode or compress it in such a way that the storage is efficient.  Think of a data base, significant work is done upon the data to store it.

When we pull it out of those systems we also must now do work to make the data into information, and then do more work to make the information understandable by the people that have little knowledge of where the data came from, the purpose of storing the data and the context from which that data/info may have resulted.  Someone will interpret that context, information and purpose and try to convey all this in a summary of the meaning behind larger data sets that the important people reviewing the information have time for.  This expansion of the information and subsequent summarization or generalization takes energy from the system as a whole.

pondering the connections - AC to info refrigeration metaphor....  what do you see in this metaphor?

is there a useful model to play with?

Categories: Blogs

SAFe® 4.0 Release Train Engineer course now available!

Agile Product Owner - Mon, 04/24/2017 - 15:39
The RTE has been a key role in SAFe since version 1.0

The concept of the Agile Release Train (ART)  originated a decade ago, and the role for the Release Train Engineer (RTE) became evident in version 1.0 of the Framework.

As ARTs have grown their ability to continuously deliver value, the RTE has evolved into a critical role as servant leader and coach for the program, and the value streams they support.

Being an effective RTE requires an exceptional range of skills, and is a career path for many servant leaders. However, until now, there has been no formal training for RTEs working in a SAFe enterprise, and the demand—as seen in job sites like LinkedIn,, and—has been skyrocketing. That’s why we are excited to announce our newest course offering: SAFe 4.0 Release Train Engineer Course with RTE Certification.

This advanced three-day interactive class offers attendees an in-depth understanding of the role and responsibilities of an RTE. Through active learning, attendees will learn how to facilitate and enable end-to-end value delivery through ARTs and value streams. They will also learn how to build high-performing ARTs by becoming a true servant leader and coach, and how to plan and execute a Program Increment (PI) planning event, which we all know is the primary enabler of alignment throughout all levels of a SAFe organization.

View prerequisites and the full course description here.

Visit the list of public RTE classes here.

If you know an RTE, or someone aspiring to be one, be sure to spread the word. This is an empowering course, and the feedback from the alpha and beta classes has been inspiring.

“The RTE class provided a great opportunity to network with other RTEs and facilitate real life learning and takeaways. The content is rich as well as thought provoking, and the exercises are equally dynamic and engaging.”

Desirée Cuniberti, RTE, Bloomberg LP

An enormous amount of sweat, thought, and effort went into developing this course and the exam that supports it. Many thanks to all who contributed, including our exam SMEs Eric Myers, Mark Byers, Sue Shreve, David Daughenbaugh, Catherine Turley, Kathy Marshak, Henk Mooijweer, Bas Willemsen, Cecile Auret, Chris Wagter, Jason Butler, Doug Less, Ron Alvey, Robert Ramirez-Dahlberg, Shane Harrison, Sean Baggett (and others far too humble to have their names listed…) and the entire Framework team: Dean, Inbar, and Richard, as well as the Learning and Certification team: Susan Farago, Chuck Ferguson, and Jeff Long.

Cheers and Be SAFe,
—Jennifer Fawcett, SAFe Fellow and Carl Starendal, SPC and Course SMEs

Categories: Blogs

How To Learn ES vNext Without Jeopardizing Existing Work

Derick Bailey - new ThoughtStream - Mon, 04/24/2017 - 15:00

Around a year ago, I wrote a blog post lamenting the high cost of entry for using ES6 features like generators, modules, etc. Since then, the world of JavaScript runtime environments has progressed significantly.

Most (if not all) of the features that were once difficult to use without pre-compilers are now available to the general population with updated browsers, and to back-end developers with new versions of Node.js. The state of JavaScript has improved significantly!

But the problem of new features hasn’t gone away. It’s only moved.

Now instead of wondering how I can work with generators, I’m looking for opportunity to work with async functions and other ES2017 (and beyond) features.

There’s an underlying problem that we have, as JavaScript developers, when it comes to new language versions and features. Most languages require us to install the specific version in whatever environment we are running our application.

But JavaScript is different – at least on the front end of things.

Instead of developers and production engineers installing the latest JavaScript features, we’re waiting for web browsers to catch up to the features. Not only that, but we’re waiting for the general population of people that use our web sites to update their browsers so we can safely use those features.

Sure, we can install new versions of Node.js on our server and run new code in the back-end. But even that can be dangerous.

I mean, when was the last time you heard about a great new language feature or syntax change in JavaScript, and thought to yourself,

“That’s great! I’ll just install the latest, unstable Node.js release, update my Babel.js version and plugins, and download an experimental browser versions that might support this syntax if I use command-line flags when starting it!”

If you’re like me and millions of other developers, this isn’t even a remote possibility. It’s just not going to happen.


Because you have existing projects that need tried-and-true, stable, well-tested and supported versions of all these things. And the risk of installing new, unstable and experimental versions of Node, Babel or any other runtime, and having it break your actual work is far too great.

It’s enough to make a developer want to forget about learning new JavaScript features… to just wait until they become “old” features. Which is unfortunate – because when I see the future of JavaScript, I see code that I desperately want to write, now.

Fortunately, there is a solution to this problem. It is possible to learn new JavaScript features – to take advantage of async functions and other improvements that can greatly reduce the amount of code you have to write. And it can be done safely.

On May 2nd, I’ll be presenting a live WatchMeCode session all about this problem and solution.

The ES7 and Beyond with Docker webinar will give you everything you need to learn the latest JavaScript features without once putting your current projects in danger from new runtime libraries, or other software updates.

Es7 and beyond vsl

And don’t worry if you’ve never used Docker – with the solution that I have, you won’t need any prior Docker experience to take advantage of the latest JavaScript features.

Learn more about this session and register today, at WatchMeCode!

The post How To Learn ES vNext Without Jeopardizing Existing Work appeared first on

Categories: Blogs

Book Review:: Agile Noir by Lancer Kind

Agile Complexification Inverter - Mon, 04/24/2017 - 14:38

 Agile Noir by Lancer Kind    and I'm envisioning a 1956 black and white film Kartar is the metaphor of his project.

First, allow me to layout some ground rules and a touch of the backstory...

I'm not a professional book reviewer, nor paid in anyway to read.  But if I could get that gig... I'd be a happy camper.  I've never written a book, but I've hacked out some code, a few articles, some of which might be considered book reviews.  I've worked in the Agile industry for more than a decade (but who's counting), and so - I may be a little close to the topic to have proper literary impartial bias.  In fact let me just go ahead and be explicit - I've done this, been there, got the t-shirt; I shit you not - this shit is for real!

Agile Noir by Lancer Kind
Now the ground rules...  I think this review will be written ... what's the word... while I'm reading, at the same time, without much delay in the reading - writing situ.... iteratively... oh I give up...

So don't be surprised - dear reader - if I just drop off in the middle...
                       ... maybe check back every week until I finish
March 22,
I've studied the cover... quite a nice graphic - to bad the whole novel isn't a graphic novel; oh - maybe it would be too bloody,  I could see Agile Noir becoming a Tarantino film.  As I sat looking at my book to-do stack... I skipped a few levels down the stack and pulled out Lancer Kind's 2016 Agile Noir.  I have read some of his previous comics titled Scrum Noir (vol 1, 2, 3).  So maybe I know what to expect - should be a fun romp in the fast lane with lots of inside the industry puns, innuendo and metaphors.

Well the damn dedication just reeks of an Agile Coach - Servant Leader (puke, barf.... moving on).

The High Cost of Schedule Slip
Now you may not find the situation Kartar finds himself in funny...  allow me to add some overtones of irony....  I'm going to go out on a racist limb and suggest that Kartar is an Indian.  That he is working in the heart of the Indian nation (Los Wages, NV), perhaps on a job for an Italian crime boss.  And none of these circumstances have anything to do with one of the world of science's biggest failures - Columbus's discover of the New World - which the thought was India, and named it's inhabitants there by creating the confusion we will have to deal with evermore.  Now Columbus was of course searching for a way to reduce the schedule required for shipping spices.

Kartar appears to be very emerged in planning and the art/science/pesdo-truth of planning and predicting the future of projects.  And he may be a master with the Gantt chart (which is footnoted on page 18).

This is all ringing just too true ... and I'm envisioning it in the style of a 1956 black and white film...

Kartar is the metaphor of his project... it seems that it's not quite on schedule... he's late to a just announced meeting with some superior and is driving at break neck speed on loose sand in the Vegas out skirts creating over bumps and ditches in his car with the accelerator pinned to the floor - because some people in a van might be trying to kill him.  Happens ALL - THE - TIME.

April 4th
Finished chapter 1.  That Bastard.  He killed off our hero Kartar.  oh - OPPS - SPOILERS!
I truly don't know if I should throw the book in the garbage bin or keep reading... going to bed.

April 6th
OK - that was quite the trick, Chapter 2, Rowing over a better Waterfall is a twist... but now it's getting interesting and our hero is back, yet I fear not quite in control of his project.

April 10th
The chapter Death by Documentation is just that... a death march, I almost quit.  The chapter is worth skipping if you have ever been on one of these classic projects - then you already know enough to thumb to page 89 and restart.  However if your not in IT or project management work of any type (Record Scratch: then how in the heck did you find my blog - and why are you reading this book?) you might enjoy the chapter as it will explain how all of your companies IT project fall behind schedule and never deliver what you want.  Read it - little bells of enlightenment will chime in your head.

The introduction of the IT Mechanic is quite fun.  He's almost a stalker... yeah, he's definitely a PM stalker.  This character is going to be fun.  He's reminding me of someone I've met... and someone from my youthful days of reading Carlos Castaneda.  The character's name is "J" could it stand for Jaun (as in don Jaun Matus)?  He's got an interesting calling card with no numbers or email addresses.  I'd recommend he try Moo - best printing house in the business.  J has some psyc skills and quite a few trick up his sleeves (he is living in the land of Penn & Teller after all).

I really enjoyed this chapter, but then almost any thing would be great after that death slog of documentation hell.

April 12th 
Sprinting is the right word for the next chapter... it's a dash by Usain Bolt.  In Sprinting with a Bollywood Autobot Kartar learns to write user stories and mix drinks of analysis, design, requirement, and development.  He attempts to negotiate on delivery with the owner and in the end crosses the third rail of the PMI tracks in a Lovers quarrel.  Oh - damn, that's not at all what happens.  But it's a lot of fun and went by really fast.  Don't know if we can sustain this pace for the rest of the book.

April 19th
Scrumming in a Waterfall - nice visual, great chapter.  I'm pulling for Kartar, he's doing all the right behaviors, making mistakes and learning each step of the way.  One day he's going to land this project in the success column of management's spreadsheet.  It appears that's how interested the big boss is in the project (affectionally called "Winner").  It's right when Kartar is about got the dirty little secret of Scrum figured out in this iteration that the Lovers, Sis & Lex show up and we cycle under the pressure of the waterfall, tumbling and gasping for air.  

How do you explain water to a fish?  I'm thinking that Kartar is learning all kinds of things in this iteration.  He's gotten lesson at the firing range, upgrade his tiny pistol to an arsenal that Fiona Glenanne (Burn Notice) would be proud of - maybe she'd invite Kartar to show her his car trunk.

But by the end of this chapter - we are back in the rabbit hole with Alice and late, we're late, for an important date.

April 23rd
I've come to understand something about "new new product development" in the software world... it requires great Product Vision and this chapter illustrates a wonderful secret of the process.  This is a wonderful view of the typical company move to the Agile mindset.  Place yourself in Kartar's view and you may believe you have the system figured out.  But is there something missing?  All the teams are scrumming and getting along, produce working software.  It's a happy time on the project.  I'm left wondering what could possibly happen next (hint its not near enough to the end of the book).

Table of Contents:
  1. The High Cost of Schedule Slip
  2. Rowing over a better Waterfall
  3. Death by Documentation
  4. The IT Mechanic
  5. Sprinting with a Bollywood Autobot
  6. Scrumming in a Waterfall
  7. Product Vision
  8. Sustainable Pace
  9. Liberation and Libations
  10. Agile Development is about having FUN!
  11. Why Let Your Framework Limit You?

See Also:
Scrum Noir - several volumes of graphic novel about scrum masters and the projects they encounter - also by Lancer Kind
I will have a Double Expresso - Amazon review of Scrum Noir.
Categories: Blogs

How Agile is creating a new Horizon for HR

A collaboration by Amy Jackson and Mario MoreiraGone are the days of certainty.  In order to stay competitive companies must constantly innovate, adapt to changing market conditions, and deliver value to their customers faster than ever before.  As a result, many organizations are embracing Agile principles and practices, which are highly collaborative, iterative and focused on delivering maximum value to customers. As Agile adapts organizations, so must Human Resources (HR) adapt.  HR is poised to become leaders in the Agile transformation.  From an organizational change perspective, HR can facilitate and improve organizational agility by crafting programs that improve collaboration, ownership, adaptability, speed, and customer focus.  This can include:
  • Continuous Learning –determine the appropriate Agile learning path for your teams.  For those just starting out, introduce the Agile Values and Principles and make parallels to the culture and behaviors your organization values. 
  • Adapting Leadership - rethink the role of the manager.  Consider moving from a command and control approach to servant leader/ coach.  Leaders should focus on coaching and removing impediments.
  • Empowering Teams – teams that are given clear direction and outcomes should be empowered to determine how they will work to achieve their outcome.  This autonomy will drive higher levels of creativity and engagement, and if done right, deliver maximum value to customers.
  • Adapting Performance Feedback – consider moving away from “traditional” annual reviews to more frequent feedback and faster feedback loops.  Individuals and teams can adapt more quickly and apply learnings to improve work.  Provide tools and techniques that empower employees to take ownership of their development.
  • Rewarding Agile Behaviors – evaluate programs to ensure they reward the behaviors and mindset you value.  In an agile environment, teams work collaboratively, consider rewards that promote teamwork and collaboration, or recognition for continuous learning, and rewards for delivering value to customers.  A one size fits all approach may not be appropriate.
  • Reshaping Talent Acquisition– hire for culture fit and mindset and make this a priority.   Working in an agile environment is not for everyone. 
In addition to focusing on programs that drive agility, HR as an organization should embrace new ways of working that reinforce the Agile Values and Principles.  First, educate yourself and don’t be afraid to experiment and try new ways of working within your HR team.  For example, if you’re considering the idea of Self-Organizing teams, consider experimenting within your team.  You will become more knowledgeable and better equipped with first-hand experience to help guide, coach and facilitate the organization in their journey to become agile. 
As you think about adapting your programs, consider using Open Space Technology.  Open Space is a great way to gather feedback, ideas and insights from your employees that can inform how you design programs for your teams.  This approach promotes collaboration.If you plan to change or modify one of your existing programs, consider breaking this work into small increments to avoid delivering a “big bang” fully baked program which may not meet the needs of your customer.  If you plan to move away from “traditional” performance management in favor of real-time continuous feedback consider starting with one team, educate them on the value of real-time feedback and then train them on how to give and receive feedback.  Gather their feedback and iterate as needed and then begin to scale the program.In addition, start connecting to customer value.  Consider creating a compelling purpose that is focused on customer value.  Strive to keep the (external) customer front and center by linking your programs to the value they will bring to the customer. Empower your employees to make decisions that are customer centric – this shift may mean that you change how you compensate or incentivize your employees by moving away from performance metrics that are internally focused in favor of rewarding behavior and actions that delight the customer. Strategic HR organizations have expertise in helping companies achieve objectives through focus on organizational culture and high-performing teams.  Given this capability there is a natural role for HR to play in an Agile culture.  HR has an opportunity to become Agile coaches and change agents.  Embrace and ready yourself for change. This may be the new horizon for HR.-----------------Learn more about Amy Jackson at: Moreira writes more about Agile and HR in his book "The Agile Enterprise" in Chapter 21 "Reinventing HR for Agile"
Categories: Blogs

Design Your Competition's Support Department

Agile Complexification Inverter - Fri, 04/21/2017 - 21:46
You are presented with a common business problem.  One technique that has always helped me to define the problem space is to invert the problem, take it to an extreme to explore the continuum of your domain.  Let's imagine that we want to redesign our software support department at MegaSoft Corporation.  Applying our inversion principle we will leave our MegaSoft support as is, and instead we will design the competitors support group. It's going to stink, people are going to hate to even call them, their people will be arrogant techies with no human compassion - they will actually hire with those skills required.  Let's pause and give this company a name...  TechHard sounds great.

Who's time is most valuable?  At TechHard the support engineers time is very valuable, so we will have process that time how long a support tech. is on the call with a customer so that our process gurus can optimize for the use of this most valuable resource.  A typical call from a director or VP in our internal support operation should be logged by an administrative receptionist (maybe even automated system) and then the support techs time can be queued up with return call tickets.  We will return the VPs call when it is convenient for our tech.  The tech can validate that the VP is authorized to access the system, and will confirm that they are still experiencing the problem by walking through a standard checklist.  Being efficiently minded the tech may skip over some simple question like power plug, on/off, reset/reboot, logout/in again if they feel the user is competent.

Answering the basic question of who's time is most valuable via the design of the competition's process is enlightening.  Which is it?  The support person's time - or the customer's time.

How are support systems designed?  Has anyone ever heard of a company that used Design Thinking or High-Tech Anthropology to create a customer centered support group?

Is this Conway's Law at work - are we truly designing the support function of our products/services - or are we just reacting?

Give me an example of great design for support:  Nest Thermostat and Fire Alarm Installation
Have you installed a Nest product?  Their installation and configuration process is well designed.  I don't know about their support department - but my expectations are set very high, if I have a problem.

History will repeat
In the 1980s universities started teaching about design for manufacturing (robots would make the parts).

Are you designing your business departments for it's function?

Speaking of support tools - your going to want a great issue tracking system.  Why not look to a market leader that has all the features your people can put on a check list?  Let's buy Jira - or should we look at the competition's product?

See Also:

Cable Internet provider Frontier's support group struggles with the corporate infrastructure that can not resolve customer problems.

Categories: Blogs

Dialogue on Prerequisites for Collaboration

Agile Complexification Inverter - Fri, 04/21/2017 - 19:10
IDEO-University 'From Ideas to Action' Lesson 1.

Join the dialogue on G+ Agile+ group.

Dialogue on Collaboration on Facebook (PDF)

Collaboration starts with who we are and our story - not the technology or the data
"The Future of Work Is Social Collaboration from Inside Out, where people connect around the why of work from who they really are as individuals in community.
They collaborate in generative conversations and co-create what’s next, i.e. their unique Contribution of value to society – what we might call Social Good.
They collaborate by taking the time to appreciate and align each other’s unique, hard wired, natural strengths, creating new levels of authentic and trusting relationships to take the Social Journey."Jeremy Scrivens Director at The Emotional Economy at Work

What does dialogue mean... what does it contribute to collaboration? Here's what the inventor of the internet Al Gore had to say about this:

Audie Cornish speaks with former Vice President Al Gore about the new edition of his book, The Assault On Reason.

Well, others have noted a free press is the immune system 
of representative democracy. And as I wrote 10 years ago, American democracy is in grave danger from the changes in the environment in which ideas either live and spread or wither and die. I think that the trends that I wrote about 10 years ago have continued and worsened, and the hoped-for remedies that can come from online discourse have been slow to mature. I remain optimistic that ultimately free speech and a free press where individuals have access to the dialogue will have a self-correcting quality. -- Al Gore
Excerpt from NPR interview with Al Gore by Audie Cornish March 14, 2017. Heard on All Things Considered.

See Also:

Mob Programming by Woody Zuill

If Your Team Agrees on Everything, Working Together Is Pointless by Liane Davey - HBR

[View the story "Dialogue on Prerequisites for Collaboration" on Storify]
Categories: Blogs

Waggle Dance -or- Standup Meeting

Agile Complexification Inverter - Thu, 04/20/2017 - 14:34
Bees do a dance that bee keeper refer to as the Waggle dance...

It is with great pleasure that you can watch and using the power of science have this dance translated into English.

Bee Dance (Waggle Dance) by Bienentanz GmbH
What does this have to do with Scrum?  The power of a metaphor was well known to the creators of Extreme Programming (XP) - so much so, that it is one of only 12 "rules" that those really smart people decided to enshrine into their process.  It is also the most likely rule to not be mentioned in any survey of software development practices.  Unless you happen to be chatting with Eric Evens, and he may agree that he's captured the underlying principle in Domain-Driven Design, the Ubiquitous Language pattern.

Have you ever observed a great scrum team using a classic tool of many innovative company environments - the physical visual management board (Scrum Task Board). The generic behavior for a small group of people (say around 7 plus/minus 2) is for the group to discover that a form of dance where the speaker moves to the board and manipulates objects on the board as they speak gives everyone else the context of what story they are working upon and what task they are telling us they have completed. Then they exit stage left - so to speak. And the next dancer approaches from stage right, to repeat the dance segment. Generally speaking one circuit of this group is a complete dance for the day. The team is then in sync with all there team mates, and may have negotiated last minute changes to their daily plan, as the dance proceeded. In my observation of this dance great teams complete this ritual in about 15 minutes. They appear to need to perform this dance early in the morning to have productive days. And groups that practice this dance ritual well, out perform groups that are much larger and groups that don't dance.

So going all honey bee meta for a moment...  Let's use our meta-cognition ability to think about the patterns.  We love to pattern recognize - our brain is well designed for that (one of the primary reasons a physical visualization of work is so much more productive as a accelerator of happiness than virtualization of the same work items).

When do we use great metaphors - in design great NEW experiences for people that are reluctant to change.  And to communicate the desired behaviors, the exciting new benefits to adopting something new.  I'm thinking of the 1984 introduction of the Graphical User Interface by the Apple pirate team that produced the GUI, the Mouse, the Pointer, the DropDown Menu, etc.

Can you see a pattern in this... a pattern that relates to people changing systems, behaviors, disrupting the status quo?  It is resonating in my neurons, I'm having a heck of a time translating these neuron firing waves of intuitions, into the motor cortex to make my stupid fingers pound out the purposefully retarding movements on a QWERTY keyboard to communicate with you over Space-Time.  If only we could dance!

See Also:

The Waggle Dance of the Honeybee by Georgia Tech College of Computing
How can honeybees communicate the locations of new food sources? Austrian biologist, Karl Von Frisch, devised an experiment to find out! By pairing the direction of the sun with the flow of gravity, honeybees are able to explain the distant locations of food by dancing. "The Waggle Dance of the Honeybee" details the design of Von Frisch's famous experiment and explains the precise grammar of the honeybees dance language with high quality visualizations.
This video is a design documentary, developed by scientists at Georgia Tech's College of Computing in order to better understand and share with others, the complex behaviors that can arise in social insects. Their goal at the Multi-Agent Robotics and Systems (MARS) Laboratory is to harness new computer vision techniques to accelerate biologists' research in animal behavior. This behavioral research is then used, in turn, to design better systems of autonomous robots.

I was just reminded of @davidakoontz's wonderful metaphor for the daily #Scrum: waggle dance :)

— Tobias Mayer (@tobiasmayer) April 7, 2017

Categories: Blogs

The Joy (and Pain) of Leaving

Illustrated Agile - Len Lagestee - Wed, 04/19/2017 - 21:12

An Agile Coach Says Farewell

This day always comes and it always will. But it never gets any easier.

In the post “An Exit Strategy for the Agile Coach,” I discuss the journey from the time a coach arrives until the time has come for them to go. Well, this coach is experiencing the later as my time in the trenches with those I most recently served has ended.

Leaving never comes as a surprise in my line of work and you would think I would start getting used to it. But since I haven’t gotten used to it and I would rather not spend the money on therapy, I’ll do the next best thing…write about it.

So I’ve spent the past few weeks capturing my thoughts about what makes these opportunities so special and one word keeps bubbling up…relationships.

While producing better, faster, or more valuable outcomes is always something to strive for, what will often be remembered is the relationships formed and the bonds created. Creating an environment where a collection of unique and diverse humans connect and thrive will always be complicated. Guiding those relationships to innovate and build something together, even more so.

From the moment we arrive until the moment we leave, intentionally focusing on the behaviors we bring to our new relationships provides the opportunity for our bonds to strengthen. Those bonds form the foundation for designing and shaping our new work culture.

Attempting to create a new work culture without these bonds usually results in temporary improvements or a few quick wins but meaningful, long-lasting change will be elusive as we never talk about the things that really need talking about.

To help build those bonds (and they will come in handy later), here are a few of those behaviors I always need to focus on when I arrive:

Energy. Many relationships launch with energy and purpose. This is often because of the “newness” of our experience together. The trick is to not only keep this energy going but to intensify it when things get rough. When things do get tough and without strong bonds of relationship, whatever energy remains typically turns negative.

When organizations have lost their energy (or energy has turned negative), it requires a few braves souls to lead the way by bringing a new level of vibrancy. Honestly, this doesn’t take much usually…it could be as simple just smiling a little more and to start saying good morning to each other.

Mostly though, it’s just a little sacrificial energy that is required at first by subtly shifting focus from what we need to what others need. This small, but never easy shift, signals we are serious about changing and we are in this for the long haul.

Energy brings momentum to relationships.

Openness. Purposeful energy will always meet resistance. In fact, if you’re not meeting resistance, change isn’t happening. To build a sustaining movement strong enough to overcome this resistance, we need to know the resistance. Knowing our resistance requires people to be vocal about their experiences and brave enough to share what they know and who they are.

Change initiatives fail, I believe, for one reason. Lack of bravery. Any reduction of bravery (openness) by any one person shrinks the ability to build on our initial energy and smash through our resistance by just that much.

Openness brings bravery to relationships.

Listening. Creating an environment of openness is meaningless unless we listen to what others are opening up about. People lose bravery because their voice has been, or is being, silenced.

Each day there is a vacuum of silence waiting to be filled. It often feels as if we are in a race to fill this vacuum with our own words as quickly as we can (he writes while looking in the mirror).

Bravery requires space for the “unbrave” to become brave. Silence creates this space and provides an invitation for people to step-in when they otherwise wouldn’t. If you are already brave, maybe a season of silence would be appropriate for you to allow space for others to become bigger.

Listening provides the space for growth in our relationships.

Growth. The expansion of radical thinking, fresh ideas and personal bravery can only happen if openness (not afraid to share) and listening (not afraid to receive) are fully present.

And when this happens, magic ensues. The strengths of each individual blends together to create something any one person would ever believe was possible.

Would you like to test if the opportunity for growth is present? Continuously ask yourself and others this question, “Do others have more confidence (feel braver)?” If the answer is yes, a little smile just crept on your face when you read the question. You’ve felt and experienced what a growing confidence environment feels like. If the answer is no, check your energy, check your openness, and check your amount of listening. One or all is missing.

Growth creates something magical from our relationships.

Community. There is beauty in a reality when we could be ourselves and express true feelings. We laugh. We cry. We talk. We debate. We celebrate. We grieve. We know about each other’s life outside of work. Some days we may not really like each other but we know we need each other. This is real-life. This is community.

Organizations don’t need another framework and they don’t need to “scale” the one they have. They need the collective ability to sense when that nasty old resistance is reappearing and collectively and instinctually overwhelm and destroy it. This happens through the strength of community…can’t wait to share more in the next post and podcast.

Community multiplies our relationships.

As this current chapter closes and a new one begins, my feelings are bittersweet. While there is pain in knowing we won’t get to experience everyday life together there is much more joy. This joy comes from knowing we had this time together in the first place and we truly experienced life together. All the highs and all the lows. Perfect.

I mentioned in the “8 Ways to Measure Your Impact as an Agile Coach,” there is no way of really knowing if this was a “successful” coaching experience. Only time will tell if the seeds planted will take root.

But I do know this…

We will always have our community . I can’t wait to see what the future holds for each of you. I appreciate you all.

Becoming a Catalyst - Scrum Master Edition

The post The Joy (and Pain) of Leaving appeared first on Illustrated Agile.

Categories: Blogs

With ES7 And Beyond, Do You Need To Know ES6 Generators?

Derick Bailey - new ThoughtStream - Wed, 04/19/2017 - 13:00

A few years ago, JavaScript introduced the idea of generators to the language. It’s a tool that was absolutely needed in the JavaScript world, and I was very happy to see it added, even if I didn’t like the name at the time.

But now, after a few years of seeing generators in the wild and using them in my code, it’s time to answer the big question.

Do you need to learn generators?

Before I get to the big secret … two secrets, really … it’s important to understand what generators are which informs why they are so important.

What Is A Generator?

The .NET world has called them “iterators” for 12 years. But I think JavaScript was following Python’s lead with “generators”. You could also call them “coroutines”, which may be the fundamental concept on which generators and iterators are built.

Ok, enough computer science lessons… what is a generator, really?

A generator will halt execution of a function for an indefinite period of time when you call “yield” from inside a function.

The code that invoked the generator can then control exactly when the generator resumes… if at all.

And since you can return a value every time execution halts (you “yield” a value from the function), you can effectively have multiple return values from a single generator.

That’s the real magic of a generator – halting function execution and yielding values – and this why generators are so incredibly important, too.

But a generator isn’t just one thing.

There’s 2 Parts To A Generator

There’s the generator function, and the generator iterator (I’ll just call that an iterator from here on out).

A generator function is defined with an * (asterisk) near the function keyword or name. This function is responsible for “yield”-ing control of its execution – with a yielded value if needed – to the iterator.

An iterator is created by invoking the generator function.

Once you have an iterator, you can … you guessed it, iterate over the values that the generator function yields.

The result of an iterator’s “.next()” call has multiple properties to tell you whether or not the iterator is completed, provide the value that was yielded, etc.

But the real power in this is when calling “;” the function will continue executing from where it left off, pausing at the next yield statement.

This means you can execute a method partway, pause it by yielding control to the code that made the function call, and then later decide if you want to continue executing the generator or not.

For more detail on this, I’ll list some great resources for what generators can do, below.

Right now, though, you should know about the real value and power of generators: how they make async functions a possibility.

Secret #1: Async Functions Use Generators

The truth is, async functions wouldn’t exist without generators. They are built on top of the same core functionality in the JavaScript runtime engine and internally, may even use generators directly (I’m not 100% sure of that, but I wouldn’t be surprised).

In fact, with generators and promises alone, you can create async/await functionality on your own.

It’s true! I’ve written the code, myself. I’ve seen others write it. And there’s a very popular library called co (as in coroutines) that will do it for you.

Compare that to the same async function calls using the syntax you saw yesterday.

With only a few minor syntax changes, co has written the same level of abstraction in calling asynchronous methods that look synchronous. It even uses promises under the hood to make this work, like async functions.

Clearly there was influence from this ingenuity in co, that influenced the final specification of async/await.

Secret #2: You Don’t Need To Learn Generators

Async functions are built on the same underlying technology as generators. They encapsulate generators into what co provided for you, as a formal syntax instead of a 3rd party library.

But do you need to learn generators?


Make no mistake. You absolutely need generators.

Without them, async functions wouldn’t work. But you do not need to learn how to use them, directly.

They’re complex, compared to the way you’ve been working. They aren’t just a new way to write iteration and asynchronous code. But they represent a fundamental shift in how code is executed, and the API to manage that is not how a developer building line-of-business applications wants to think.

Sure, there are some use cases where generators can do really cool things. I’ll show you those in the resources below. But your code will not suffer one iota if you don’t learn how to use generators, directly.

Let the library and framework developers deal with generators to optimize the way things work. You can just sit back and focus on the awesomeness that is async functions, and forget out generators.

One Use Case For Generators

Ok, there is one case where I would say you do need generators.

If you want to support semi-modern browsers or Node.js v4 / v6 with async/await functionality…

And if you can’t guarantee the absolute latest versions of these will be used… Node v7.6+, MS Edge 15, Chrome 57, etc…

Then generators are your go-to option with the co library, to create the async function syntax you want.

Other than that, you’re not missing much if you decide to not learn generators.

So I say skip it.

Just wait for async/await to be readily available and spend your time learning promises instead (you absolutely need promises to effectively work with async functions).

Generator Resources

In spite of my advice that you don’t need to learn generators, there are some fun things you can do with them if you can completely wrap your head around them.

It took me a long time to do that.

But here are the resources I used to get my head into a place where generators made sense.

And some of my own blog posts on fun things I’ve done with generators.

The post With ES7 And Beyond, Do You Need To Know ES6 Generators? appeared first on

Categories: Blogs

Can we have a dialogue about Estimation and the behaviors it drives?

Agile Complexification Inverter - Tue, 04/18/2017 - 23:02

Some topic are taboo - not safe to discuss.  I've never appreciated that concept.  Those taboo topics are my favorite topics to discuss.

Taboo Topics (ordered by fear of conversation)
  • Gender - Sexual preferences - non-standard practices
  • Religion as truth, my religion vs your wrong religion
  • Politics - the correct way to govern a group the results in my opportunity
  • Pay for services rendered - why my gender is paid more than yours
  • counting - off by one errors and how to mask them; we're # 1
  • estimates - how wrong your estimate was and why I'm missing my commitment
  • prioritization - ordering methods
  • laziness - the art of not doing work
I've recently been embroiled in a "dialogue" about the twitter topic of #NoEstimates.  I would write a summary of the topic but cannot do better that this one:

Estimates? We Don’t Need No Stinking Estimates! by Scott Rosenberg
"How a hashtag (#NoEstimates) lit the nerdy world of project management aflame — or at least got it mildly worked up."

A nice summary of the dust-up.  Imagine if the tag would have been #LeanEstimates?

There are two sides to this debate - at least two sides.  But I like that the taboo topic was raised and has questioned assumptions.  I think the think that drives a topic toward the taboo is this questioning of assumptions.  The saluter of scared cows (where does that term even come from?).

So what behaviors does the process or estimating drive:

  • a list
  • TBD
  • someone misplaced the list...

"Unable to estimate accurately, the manager can know with certainty neither what resources to commit to an effort nor, in retrospect, how well these resources were used.  The lack of a firm foundation for these two judgements can reduce programming management to a random process in that positive control is next to impossible. This situation often results in the budget overruns and schedule slippages that are all too common." -- J.A FarquharDoes a Scrum process framework and the Agile mindset resolve Farquhar's concerns that the manager may have without accurate estimates - via empirical measurement and relative estimation techniques?

I'm not sure that the Twitter-verse is capable of holding the dialogue.  My experience was not very fruitful nor enlightening.  I've been accused by a manager at work of being "anti-management" I've asked, but got no direct answer, what that term meant, and why he believed or thought this label to be useful.  I've wondered if it was because of this type of conversation.  I also asked these fellows, but didn't resolve my query with the rhetoric of the conversation.
@vishalsomal it's an anti-management movement started by Woody, where SWDev wants to run the show @PeterKretzman @henebb— Glen B. Alleman (@galleman) March 5, 2017... deleted ... a lot of tweets about actions from years ago when when the #NoEstimates twitter conversation was beginning - some relating to a blog post being edited or complete deleted.  Something I find quite acceptable (and do quite frequently myself).
@henebb @PeterKretzman @galleman @duarte_vasco So if he deleted a piece you appear to object to maybe you made a point and he heard your view.— David A. Koontz (@davidakoontz) April 13, 2017
@henebb @PeterKretzman @galleman @duarte_vasco is it admirable to be the accuser but not reach out to talk,
to label one hyper-defensive when they are trying to understand? pondering— David A. Koontz (@davidakoontz) April 13, 2017
@PeterKretzman @davidakoontz @henebb @duarte_vasco David, U do realize W and V and now N blocked any questions about the credibility of #NE.
There is NO conversation about NE just broadcast— Glen B. Alleman (@galleman) April 14, 2017
@galleman @PeterKretzman @henebb @duarte_vasco 3 people do not make the sum total of people discussing this topic.— David A. Koontz (@davidakoontz) April 14, 2017
@davidakoontz @galleman @PeterKretzman @duarte_vasco Of course not. No one is claiming that either. But they are the main champs. Traveling the world, spreading the message.— Henrik Ebbeskog (@henebb) April 14, 2017
@galleman @PeterKretzman @henebb @duarte_vasco So I reject your conclusion; and substitute #NE or #noestimates with #LeanEstimates— David A. Koontz (@davidakoontz) April 14, 2017
The conversation went on from there...  I'm reminded of Adam on MythBusters.

@henebb @galleman @duarte_vasco I don't know if this anti-management you speak of. Tell me more as I don't see connection to NE or as we call it now #LeanEstimation— David A. Koontz (@davidakoontz) April 13, 2017 ... and there is some link to Anti-Management because one is willing to discuss better options or worse options than estimation...
@henebb Here's an anti-management tweet (one of many) from the NE founder. @davidakoontz @galleman @duarte_vasco— Peter Kretzman (@PeterKretzman) April 13, 2017
@PeterKretzman @henebb @galleman @duarte_vasco Is it the answers or the questions you object to as being anti-management?— David A. Koontz (@davidakoontz) April 13, 2017
@PeterKretzman @henebb @galleman @duarte_vasco ... 2/2 because I'm willing to engage in dialogue about #NoEstimates in public? Is anti-management contagious? #LeanEstimates— David A. Koontz (@davidakoontz) April 13, 2017 There appears to be large amounts of animosity amongst the principle people that were having this dialogue - nope that word is not the best word, here... try debate... twitter shouting match...
@henebb @PeterKretzman @galleman @duarte_vasco well that certainly didn't happen, thanks to your vigilance; have you asked him if that was his intent?— David A. Koontz (@davidakoontz) April 13, 2017
@davidakoontz @henebb @galleman @duarte_vasco Point: Woody won't talk with critics.
Second point: you're a little too fixated on this one example of anti-mgmt. As I said, there are many.— Peter Kretzman (@PeterKretzman) April 13, 2017
@PeterKretzman @henebb @galleman @duarte_vasco So you didn't ask Woody about the issue?
Is it just you he will not talk to, because I've chatted with him a lot.— David A. Koontz (@davidakoontz) April 13, 2017
@henebb @PeterKretzman @galleman @duarte_vasco I like that analogy... estimate are addictive - but not that powery - what is your object to the analogy?— David A. Koontz (@davidakoontz) April 13, 2017
@henebb @PeterKretzman @galleman @duarte_vasco brushing teeth is not addictive; it's nothing like heroin addiction I'm told.— David A. Koontz (@davidakoontz) April 13, 2017
@davidakoontz @PeterKretzman @galleman @duarte_vasco ...Yeah, and seeing healthy estimating as "addiction process" reveals that you despise estimates.— Henrik Ebbeskog (@henebb) April 13, 2017
@henebb @PeterKretzman @galleman @duarte_vasco wow - how did you jump to that conclusion?
"despise estimates" not many of the team members I work with would support your conclusion— David A. Koontz (@davidakoontz) April 13, 2017
@henebb @PeterKretzman @galleman @duarte_vasco ah... do we need to review the concept of analogy - I liked the analogy, I find it useful; I think that's different than what your stating— David A. Koontz (@davidakoontz) April 13, 2017
@henebb @PeterKretzman @galleman @duarte_vasco that's not where I would apply the nature of addiction in the analogy. Yet I can see how you could get there.— David A. Koontz (@davidakoontz) April 14, 2017 How might the analogy of estimation is like addiction be a useful analogy?
@galleman @PeterKretzman @henebb @duarte_vasco That's not consistent with my conversation and experiences with @WoodyZuill (your good with logic - am I within the set of anyone?)— David A. Koontz (@davidakoontz) April 13, 2017
@PeterKretzman @henebb @galleman @duarte_vasco I'm just guessing but I bet there was a period when he was willing to converse with you all.
pondering ... my experience extrapolated ...— David A. Koontz (@davidakoontz) April 13, 2017

See Also:

Impact of Schedule Estimation on Software Project Behavior
by Tarek K. Abdel-Hamid, SRI International Stuart E. Madnick, Massachusetts Institute of Technology
A Preliminary Inquiry into the Software Estimation Process by J.A. Farquhar, 1970
Categories: Blogs

Domain Command Patterns - Validation

Jimmy Bogard - Tue, 04/18/2017 - 21:36

I don't normally like to debate domain modeling patterns (your project won't succeed or fail because of what you pick), I do still like to have a catalog of available patterns to me. And one thing that comes up often are "how should I model commands?":

In general, apps I build follow CQRS, where I split my application architecture into distinct commands and queries. However, no two applications are identical in terms of how they've applied CQRS. There always seem to be some variations here and there.

My applications also tend to have explicit objects for external "requests", which are the types bound to the HTTP request variables. This might be a form POST, or it might be a JSON POST, but in either case, there's a request object.

The real question is - how does that request object finally affect my domain model?

Request to Domain

Before I get into different patterns, I like to make sure I understand the problem I'm trying to solve. In the above picture, from the external request perspective, I need a few questions answered:

  • Was my request accepted or rejected?
  • If rejected, why?
  • If accepted, what happened?

In real life, there aren't fire-and-forget requests, you want some sort of acknowledgement. I'll keep this in mind when looking at my options.

Validation Types

First up is to consider validation. I tend to look at validation with at least a couple different levels:

  • Request validation
  • Domain validation

Think of request validation as "have I filled out the form correctly". These are easily translatable to client-side validation rules. If it were 100 years ago, this would be a desk clerk just making sure you've filled in all the boxes appropriately. This sort of validation you can immediately return to the client and does not require any sort of domain-specific knowledge.

A next-level validation is domain validation, or as I've often seen referred, "business rule validation". This is more of a system state validation, "can I affect the change to my system based on the current state of my system". I might be checking the state of a single entity, a group of entities, an entire collection of entities, or the entire system. The key here is I'm not checking the request against itself, but against the system state.

While you can mix request validation and domain validation together, it's not always pretty. Validation frameworks don't mix the two together well, and these days I generally recommend against using validation frameworks for domain validation. I've done it a lot in the past and the results...just aren't great.

As a side note, I avoid as much as possible any kind of validation that changes the state of the system and THEN validates. My validation should take place before I attempt to change state, not after. This means no validation attributes on entities, for example.

Validation concerns

Next, I need to concern myself with how validation errors bubble up. For request validation, that's rather simple. I can immediately return 400 Bad Request and a descriptive body of what exactly is off with the request. Typically, request validation happens in the UI layer of my application - built in with the MVC framework I'm using. Request validation doesn't really affect the design of my domain validation.

Domain Validation

Now that we've split our validation concerns into request validation and domain validation, I need to decide how I want to validate the domain side, and how that information will bubble up. Remember - it's important to know not only that my request has failed, but why it failed.

In the domain side, understanding the design of the why is important. Can I have one reason, or multiple reasons for failure? Does the reason need to include contextual data? Do I need to connect a failure reason to a particular input, or is the contextual data in the reason enough?

Next, how are the failures surfaced? When I pass the request (or command) to the domain, how does it tell me this command is not valid? Does it just return back a failure, or does it use some indirect means, like an exception?

public void DoSomething(SomethingRequest request) {  
    if (stateInvalid) {
        throw new DomainValidationException(reason);


public bool DoSomething(SomethingRequest request) {  
    if (stateInvalid) {
        return false;
    return true;

In either case, I have some method that is responsible for affecting change. Where this method lives we can look at in the next post, but it's somewhere. I've gotten past the request-level validation and now need domain-level validation - can I affect this change based on the current state of the system? Two ways I can surface this back out - directly via a return value, or indirectly via an exception.

Exceptional domain validation

At first glance, it might seem that using exceptions are a bad choice for surfacing validation. Exceptions should be exceptional, and not part of a normal operation. But exceptions would let me adhere to the CQS principle, where methods either perform an action, or return data, but not both.

Personally, I'm not that hung up on CQS for these outer portions of my application, which is more of OOP concern. Maybe if I'm trying to follow OOP to the letter it would be important. But I'm far more concerned with clean code than OOP.

If I expect the exceptional case to be frequent, that is, the user frequently tries to do something that my domain validation disallows, then this wouldn't be a good choice. I shouldn't use exceptions just to get around the CQS guideline.

However, I do try to design my UX so that the user cannot get themselves in an invalid state. Even validations - my UX should guide the user so that they don't put in invalid data. The HTML5 placeholder attribute or explanatory text helps there.

But what about domain state? This is a bit more complex - but ideally, if a user isn't allowed to perform a state change, for whatever reason, then they are not presented with an option to do so! This can be communicated either with a disabled link/button, or simply removing the button/link altogether. In the case of REST, we just wouldn't return links and forms that were not valid state transitions.

If we're up-front designing our UX to not allow the user to try to get themselves in a bad state, then exceptions would truly be exceptional, and then it's OK to use them I believe.

Returning success/failure

If we don't want to use exceptions, but directly return the success/failure of our operation, then at this point we need to decide:

  • Can I have one or multiple reasons for failure?
  • Do I need contextual information in my message?
  • Do I need to correlate my message to input fields?

I don't really have a go to answer for any of these, it's really depended on the nature of the application. But if I just needed a single reason, then I can have a very simple CommandResult:

public class CommandResult  
   private CommandResult() { }

   private CommandResult(string failureReason)
       FailureReason = failureReason;

   public string FailureReason { get; }
   public bool IsSuccess => string.IsNullOrEmpty(FailureReason);

   public static CommandResult Success { get; } = new CommandResult();

   public static CommandResult Fail(string reason)
       return new CommandResult(reason);

   public static implicit operator bool(CommandResult result)
       return result.IsSuccess;

In the above example, we just allow a single failure reason. And for simplicity's sake, an implicit operator to bool so that we can do things like:

public IActionResult DoSomething(SomethingRequest request) {  
    CommandResult result = service.DoSomething(request);
    return result ? Ok() : BadRequest(result.FailureReason);

We can of course make our CommandResult as complex as we need be to represent the result of our command, but I like to start simple.

Between these two options, which should you use? I've gone back and forth between the two and they both have benefits and drawbacks. At some point it becomes what your team is more comfortable with and what best fits their preferences.

With request and command validation, let's next turn to handling the command itself inside our domain.

Categories: Blogs

What United Can Teach Us About Building Systems

Notes from a Tool User - Mark Levison - Tue, 04/18/2017 - 13:35

//], via Wikimedia Commons

United Airlines, by Altair78, CC BY-SA 2.0

In April 2017, United Airlines made global headlines when they forcibly removed one passenger (David Dao) who had already boarded the flight, to accommodate crew flying to another destination. The flight staff called the airport police and Dao was hurt as he was dragged off the plane, suffering a concussion, loss of teeth and other injuries.

In the same week, another United passenger flying from Hawaii to Los Angeles was forced off a plane despite having paid full fare for a first class ticket. “That’s when they told me they needed the seat for somebody more important who came at the last minute,” Geoff Fearns said. “They said they have a priority list and this other person was higher on the list than me. They said they’d put me in cuffs if they had to.”

Neither of these cases should have ever happened. In both cases, crew on the ground and then customer service handled the situation badly. However, I don’t think that the real issue is the airline staff.

There are at least three major issues at play:

  1. Working at 100% of Capacity
  2. Too many conflicting rules
  3. Culture
Working at 100% of Capacity

David Dao was removed from his flight because four crew showed up after the passengers had already boarded. The crew were required in Kentucky the next day, and their absence would have delayed several hundred passengers on other flights. United offered up to $800 to get people to leave the flight, and then when that didn’t work, they simply selected four passengers at random to be removed.

There are two significant problems here:

  • Stochastic Queueing, by David Levinson. CC BY-SA 3.0

    By attempting to have every flight 100% full, there is no capacity to respond to small things going wrong in the system. E.g. extra people showing up at the last minute and creating a shortage of seats. This shows up time and time again, when utilization of capacity in a system exceeds a certain point and the system becomes fragile or breaks completely. In highways and road systems, it happens at around 65-70% of the designed capacity of the road.

  • By having only enough crew in each city to survive that day’s flights, United is again running at 100% capacity with respect to crew. There is additional risk in that a small problem in Chicago would escalate and become a big problem in Kentucky 24 hours later.

The issue in both cases is the attempt to squeeze every last dollar out of a situation. When we design organizations or systems (e.g. highways, hospitals, airlines) we need to build in enough slack to deal elegantly with small problems.

United could avoid this problem in the future. On all flights to key destinations, set aside 3-4 seats for deadheading crew, and offer these seats to standby passengers only when it can be guaranteed no crew will show up. Another alternative would be to establish backup crews in each city the airline services – the challenge there would be ensuring the backup crews have sufficient cross-skilling to deal with the variety of aircraft that United fly from that airport.

When we’re building teams for knowledge work (e.g. Software Development, Marketing, etc.) that slack time can be used for learning and growing skill.

More on Capacity and Slack:

Too Many Conflicting Rules

The more rules that a system has, the more unanticipated effects, and the less freedom the people doing the work have to make sensible decisions. Between the two incidents, we can see that United has some complicated rules about what it actually means to have bought a fare on the airline:

  • more important First Class passengers trump other First Class passengers
  • disabled people, children travelling alone and high status passengers trump deadheading crew
  • deadheading crew[1] have priority over Economy passengers
  • United Ground Staff are authorized to offer $400 and then $800 to get passengers to disembark, and cannot deviate from that

This list of United’s policies is, of course, incomplete as it’s just gleaned from news reports following the incident. The complete list is undoubtedly much longer.

With all these rules in place, the ground staff didn’t have enough room to explore other options. Perhaps if they had offered $1000 out of the gate, they would have got volunteers more quickly. Strangely, having to offer $400 – an insultingly low sum for many travellers – made it less likely that people would accept any subsequent offer.

As we learned in Simplicity, when we design systems with complicated rules, they will break down. When we build systems with simple heuristics, people have more capacity to make better decisions in their current situation. In most cases, they use the heuristic as expected, and only occasionally do they break it where local circumstance justifies.

[1] Deadheading crew – flight staff who aren’t working on the flight but are instead flying to the destination in a passenger seat, to work a flight from there. Culture

Under the control of Jeff Smisek, United went from an airline with some customer focus to one totally focused on costs and the bottom line. Companies that focus on reduction of cost might do well in the stock market for a few quarters. They do well because profits increase, but in the long run the focus on trying to save pennies hurts because it leaves an organization that has no flexibility.

Build an organization that is focused on delighting the customer, and give the team real decision-making capacity. Then even if we’ve made mistakes, those people still have the ability to identify a problem as it happens and make the situation right.

By all accounts Oscar Munoz, United’s CEO, is attempting to turn the culture around. He has only been CEO for 20 months, which is not enough time to make a significant impact on a company employing nearly 90,000 people.

The real question: is Munoz attempting to make significant changes to affect the culture, or will the cost focus of his predecessor live on?

Culture References at United:
Categories: Blogs

You Need ES2017’s Async Functions. Here’s Why …

Derick Bailey - new ThoughtStream - Tue, 04/18/2017 - 13:00

If you’ve ever written code like this, you know the pain that is asynchronous workflow in JavaScript.

Nested function after nested function. Multiple redundant (but probably necessary) checks for errors.

It’s enough to make you want to quit JavaScript… and this is a simple example!

Now imagine how great it would be if your code could look like this.

Soooo much easier to read… as if the code were entirely synchronous! I’ll take that any day, over the first example.

Using Async Functions

With async functions, that second code sample is incredibly close to what you can do. It only takes a few additional keywords to mark these function calls as async, and you’re golden.

Did you notice the difference, here?

With the addition of “async” to the outer function definition, you can now use the “await” keyword to call your other async functions.

By doing this, the JavaScript runtime will now invoke the async functions in a manner that allows you to wait for a response without using a callback. The code is still asynchronous where it needs to be, and synchronous where it can be.

This code does the same thing, has the same behavior from a functionality perspective. But visually, this code is significantly easier to read and understand.

The question now, is how do you create the async functions that save so much extra code and cruft, allowing you to write such simple workflow?

Writing Async Functions

If you’ve ever used a JavaScript Promise, then you already know how to create an async function.

Look at how the “createEmployee” function might be written, for example.

This code immediately creates and returns a promise. Once the work to create the employee is done, it then checks for some level of success and resolves the promise with the employee object. If there was a problem, it rejects the promise.

The only difference between this function and any other function where you might have returned a promise, is the use of the “async” keyword in the function definition.

But it’s this one keyword that solves the nested async problem that JavaScript has suffered with, forever.

Async With Flexibility

Beyond the simplicity of reading and understanding this code, there is one more giant benefit that needs to be stated.

With the use of promises in the the async functions, you have options for how you handle them. You are not required to “await” the result. You can still use the promise that is returned.

This code is just as valid as the previous code.

Yes, this code still calls the same async createEmployee function. But we’re able to take advantage of the promises that are returned when we want to.

And if you look back at the 3rd code sample above, you might remember that I was calling async functions but ultimately using a callback to return the result. Yet again, we see more flexibility.

Reevaluating My Stance On Promises

In the past, I’ve made some pretty strong statements about how I never look to promises as my first level of async code. I’m seriously reconsidering my position.

If the use of promises allows me to write such easily readable code, then I’m in.

Of course, now the challenge is getting support for this in the majority of browsers, as I’m not about to drop a ton of terrible pre-compiler hacks and 3rd party libraries into a browser to make this work for the web.

Node.js on the other hand? Well, it’s only a matter of time before v8.0 is stable for release.

For now, though, I’ll play with v7.6+ in a Docker container and get myself prepared for the new gold standard in asynchronous JavaScript.

The post You Need ES2017’s Async Functions. Here’s Why … appeared first on

Categories: Blogs

Leadership re-envisioned in the 21st Century

Agile Complexification Inverter - Mon, 04/17/2017 - 22:38
Is there a new form of leadership being envisioned in the 21st Century?  Is there someone challenging the traditional form of organizational structure?

Leading Wisely - a pod cast with Ricardo Semler.
Leading Wisely
"Join organizational changemaker Ricardo Semler in conversation with leaders challenging assumptions and changing how we live and work."
S1E01: Killing the Dinosaur Business Model (Part 1) with Basecamp’s Jason Fried & DHH

S1E02: Killing the Dinosaur Business Model (Part 2) with Basecamp’s Jason Fried & DHH
S1E03: Reinventing Organizations with Frederic Laloux

S1E04: Self-organization with Zappos' Tony Hsieh
S1E05: Busting Innovation Myths with David Burkus

S1E06: Merit and Self-Management with Jurgen Appelo

S1E07: Letting Values Inform Organizational Structure with Jos de Blok

S1E08: Corporate Liberation with Isaac Getz

S1E09: The Police & Self-Management with Erwin van Waeleghem

S1E10: Season Finale: The Common Denominator with Rich Sheridan of Joy Inc.

A ran across this series of 10 talks because I'm a fan of Joy, Inc. author and leader of Menlo innovations, Richard Sheridan.  I saw a tweet about his talk and found a bucket of goodness.
The Common Denominator with Rich Sheridan of Joy Inc.

Richard Sheridan on podcast Leading WiselySee Also:A Review of Leadership ModelsExamples of 21st C. CompaniesSafety - the perquisite for Leadership
A Leadership Paradox

Book List:
Maverick!: The Success Story Behind the World's Most Unusual Workplace by Ricardo SemlerJoy, Inc : How We Built a Workplace People Love by Richard SheridanReWork: Change the Way You Work Forever by David Heinemeier Hansson and Jason Fried
Reinventing Organizations: A Guide to Creating Organizations Inspired by the Next Stage in Human Consciousness by Frederic Laloux
Categories: Blogs

Certified Agile Leadership course in San Diego April 25-27

Agile Game Development - Mon, 04/17/2017 - 15:01
The key to successful agile adoption and growth lies not only with developers, but studio leadership as well. We all know that cross-discipline teams iterating on features creates a benefit, but to achieve the far greater (and rarer) reward of developer engagement and motivated productivity, you need deeper cultural change.  This requires a shift in the mindset of leadership.
The Certified Agile Leadership (CAL) course provides this shift.  It distills the experience and wisdom of decades of experience applying agile successfully and leads to true leadership transformation.  In taking the course, I personally found that not only were my leadership approaches transformed, but it altered how I engaged with family, friends and my own life.
I will be joining the CAL course being taught by my friend and occasional co-trainer Peter Green In San Diego on April 25th through the 27th.  Please join us!
Categories: Blogs