Writing on io9,  Esther Inglis-Arkill asks what it would take to make robots lovable.   The answer she came up with is not to make the robots realistic or lifelike,  but rather to make them “cute”

A couple of the examples she uses include “Boxie”, an experiment of the MIT media lab shown in the video above,  and Paro, a robotic baby seal being used to successfully treat Alzheimer’s patients.

Inglis-Arkill concludes

The difference between Paro and a real pet isn’t just that a real pet may inadvertently hurt its owner. The difference is no one cares if Paro “dies” or is neglected. The difference between a tamagotchi and a cat is, when the tamagotchi dies, people shrug it off and the game gives them another, while even the most hard-up cat shelters will stop giving out cats eventually (don’t ask me how I know). Boxie might guilt you into an interview, but you know that at any time you can easily walk away. Actual, real girlfriends and actual, real babies, demand more time and attention than the most realistic doll in the world. And ELIZA’s biggest asset, even at the height of her appeal, has always been that she is “low-cost.” People don’t just love robots because they’re lifelike, and so can provide and receive affection. People love them because they’re not alive, and deserve no particular care.

The trick, then, isn’t exactly simulating reality to get people to fall in love. People are able to attach themselves to anything. It’s allowing people to experience enough of the pleasures of love – aesthetic appeal, emotional support, and physical comfort – while letting them know that they aren’t on the hook for any responsibility. That will get people willing to fall in love mighty fast.

Do you really love something that you have no responsibility to?  I will leave that question for philosophers smarter than me.  The key question for me is how much cuteness we can actually take.  As they point out in the video, people either loved or hated the robot.   While Boxie might be reasonably successful as something new at MIT, I have trouble imagining him surviving for long in the New York Subway.

Sometimes cute is enjoyable, sometimes annoying.  As you create interfaces, keep in mind that the “right” interface depends on the purpose of what you are building, and what the user really needs.

Agile has been high on my radar recently.

At #BBCcon  a couple of weeks ago, I attended a number of sessions focused on moving organizations from “waterfall” development methodology to agile.   At Dreamforce, I attended another session on Agile.

But pretty much all I had seen in the Agile world was about software development.  This was different.   Extreme Manufacturing is all about bringing the techniques and methods of Agile to hardware and systems design.  In this event we were told to build a car over six sprints.

Here is the frame of the car

We started with groups of components including a frame, an engine 4 wheel assemblies, a body, a steering assembly, a windshield, and a few others.   There was Kanban board up and a “project manager” would write tasks on yellow sticky notes, and put them into categories of either ready or not ready.   Scrum teams of 3-5 would then choose one of the tasks from the ready column, move it into in progress and start working.  The organizers intentionally put some “mistakes” in so that the team(s) would need to work together to solve some problems.   Unfortunately there were some real mistakes in some of the components, most notably that one of the cross pieces on the frame was welded 4 inches too far back, that prevented the car from actually fully coming together.  We ended with something that looked a lot like a car and steered, but the engine wasn’t hooked to the wheels.

Putting the windshield on. This looks a lot like a car, has all the major components, and steers, but the engine isn’t connected to the wheels, so it doesn’t go

Does it work? The jury is still out.  Here is what I see.

• The WikiSpeed Team has clearly had some success with using agile methods.  They built a car  that took 10th place in  the Automotive X Prize competition,  while spending $20,000 and using volunteers working an average of 2 hours per week.  They beat out companies spending millions of dollars.  They have had other successes, such as bringing the development cycle for a new radio down from 18 months to three weeks.
• Architecture, Architecture, Architecture.  In order to  successfully develop hardware in an agile environment, the architecture must be very well thought out.  Ideally there should be no more than 7 major modules, each of one is truly independent.  The example Wikispeed uses is the engine.  They claim that they could take out the gas powered engine, but in an electric, natural gas, or fuel cell engine without having to redesign any other part of the car.
• Test, Test, Test.  As soon as possible have a test of the integration of the subsystems.  Find the errors as quickly as you can.  The earlier an error is found, the lower the cost of fixing it.
• You still need someone with an overview of what is going to happen.  In order for agile or scrum teams to work effectively,  someone has to be really clear on when a task is really “ready” to be begun.  We did several tasks out of order because some teams thought a task was ready, when it really wasn’t
• Communication is crucial.  Especially since we were all working in on the same object.  If a team putting on the front right wheel lifted the car, the team putting on the back wheel was impacted.
• Teamwork is learned.  Teams need to get to know each other to develop a flow.
• Using Agile DOES NOT MEAN that you don’t need to plan or think about requirements.   The requirements may be different than waterfall methods, but they are still important.  In hardware, requirements for the interfaces between systems is crucial

This was an interesting, fun event.  Of course there are some real differences between a learning exercise and real world applications, but I thought that there were some great lessons.  Overall, I think that agile methodologies, applied properly to the right problems can indeed speed and improve hardware and software development.

There was one session today that I really thought was outstanding.  It was simple, yet powerful, and described a method of eliciting requirements that makes real sense.

John Bethke  gave a dynamite presentation on the use of business events as the focal point for business analysis:

An analysis approach based on business events defines the who,
what and when of an enterprise or business unit. You ask: What is the triggering business event? What causes a customer or business  person to do something? Who or what does it? You also want to address work flow state – When does it happen? What business objects are created or consumed? What is happening and why?

There are two really cool parts to this.  First of all, people can understand business events.  A question like “what causes you to start doing that?” will usually result in a pretty detailed answer, AND when you drill just a little, business rules, processes, and requirements fall right out.  Very cool

I learned today that there are 108 sessions in the conference.  Wow!   At times, it was hard to decide which session to select.  Today I attended sessions on Agile, Business Process Management, and Business Rules.

There was a lot of great content through the day, but one theme came up again and again in the agile sessions.

It is a myth that agile projects do not need you to document requirements.  The agile manifesto says

Working software over comprehensive documentation

The key word is comprehensive.  Do the requirements documentation that you need for the project.    Do the analysis you need when you need them.

Oh, and the other thing that surprised me was when one analyst said she actually ditched MS Word and started using a requirements tool to better support an agile project.  Wow – coool

Marty is a funny, engaging, and dynamic speaker.  His book Leadership Land Mines! 8 Management Catastrophes and How to Avoid Them covers 8 of these landmines and he covered 2 in the talk
The one I liked the most was “management by exception” – In short, his advice was “don’t get derailed from big, good ideas because they aren’t perfect. Every idea, no matter how great won’t work 100% of the time. The examples he used were hilarious, and I can’t do them justice, but I want to stress the importance of the idea.

Never, ever, ever let the perfect be the enemy of the good.  Yes. sometimes there is an exception that is a deal breaker, but most of the time, the exception becomes an excuse.

Our job, as business leaders, is to keep making things better for as many people as possible. Don’t get distracted

This is a good, mid sized conference.  There are more than 1,400 attendees, coming from more than 30 countries and 48 states.  (note – still trying to figure out the missing state  – I have met attendees from Hawaii and Idaho, so I am guessing Alaska and Montana)

I understand that until it was called the “Business Rules Conference” until 2010 when IIBA joined in and expanded the scope of the conference.

There are 8 simultaneous breakout sessions following “themes”

• Business Architecture
• Business Portfolio Management
• Leadership
• Business Strategy and Transformation
• Analysis and Design
• Agile
• Techniques
• The Way Forward

Sometimes it is difficult to choose which session to go to, so far all the sessions I have gone to have been interesting and worthwhile.

More to come soon.

Building Business Capabilities runs tomorrow through Friday.  I’ll try to post the highlights after the sessions.

To start, he references Peter Senge’s classic work, The Fifth Discipline: The Art & Practice of The Learning Organization.   Senge states that there are two types of complexity, detail complexity in which there are many variables, and dynamic complexity, “situations where cause and effect are subtle and where the effects over time of interventions are not obvious”.

Learning, according to Martin, begins with mystery, in which we don’t even know which variables are important.  Over time, as learn which variables to study, and begin to understand cause and effect.

…most of the guns deployed in modern knowledge advancement are aimed at narrow problems for which the cause-and-effect relationship is specified with the famous “all other things being equal” proviso. Each narrow knowledge domain develops analytical tool-sets that deepen the narrow knowledge domain. Each narrow domain develops ever more algorithmic knowledge, and those developing the knowledge are extremely confident that they are right because they are so specialized within their own domain. The liver expert is completely confident that he or she is correct even if it is the interaction with another condition that threatens your health most.

Because of this constant narrowing of scope,  Martin contends that we have created a new type of complexity, Inter Domain Complexity

 Every field is segmented into multiple domains, each with deep algorithmic knowledge, specialized tools, and experts in the domain who think they are absolutely right.

But the real world doesn’t fall neatly into different domains.  In the real world, domains interact with each other in subtle and complex ways.  To counter the problem  Martin suggest that a new domain, specifically focused on interdomain knowledge be developed.  m

I believe that the solution to the self-inflicted problem of inter-domain complexity is the development of a meta-domain: the domain of knowledge about how to integrate across knowledge domains. While this might seem on its face to be an esoteric or even unapproachable knowledge domain, it really isn’t either. There are techniques for tackling fully clashing models from different knowledge domains.

We have seen the need for this meta domain in our work with System Engineers and Business Analysts/Architects.

We look forward to learning more about Martin’s work, and the impact he is having

So, it should be no surprise that I was drawn to an article about the Kludgeocracy in America by Steven M Teles in the current National Affairs Magazine.   The article is somewhat more political (although blessedly non-partisan) than I usually like to cover in this blog, but Teles makes some interesting points that have applicability as we engineer processes and build systems to support those processes.

A “kludge” is defined by the Oxford English Dictionary as “an ill-assorted collection of parts assembled to fulfill a particular purpose…a clumsy but temporarily effective solution to a particular fault or problem.” The term comes out of the world of computer programming, where a kludge is an inelegant patch put in place to solve an unexpected problem and designed to be backward-compatible with the rest of an existing system. When you add up enough kludges, you get a very complicated program that has no clear organizing principle, is exceedingly difficult to understand, and is subject to crashes. Any user of Microsoft Windows will immediately grasp the concept.

“Clumsy but temporarily effective” also describes much of American public policy today. To see policy kludges in action, one need look no further than the mind-numbing complexity of the health-care system (which even Obamacare’s champions must admit has only grown more complicated under the new law, even if in their view the system is now also more just), or our byzantine system of funding higher education, or our bewildering federal-state system of governing everything from welfare to education to environmental regulation. America has chosen to govern itself through more indirect and incoherent policy mechanisms than can be found in any comparable country.

Teles points to a combination of the “multiple veto points” as well as the often perverse individual incentives as primary causes of the kludgeocracy, but he also talks to a somewhat schizophrenic personality  in the American electorate.

Americans are ideological conservatives and operational liberals. That is, they want to believe in the myth of small government while demanding that government address public needs and wants regarding everything from poverty and retirement security to environmental protection and social mobility.

The result, according to Teles is a system that hides the true cost of government actions making them more complex than necessary to achieve the goals.  Teles then points to some structural and policy changes, that he claims would alleviate the problem.  His prescriptions are beyond the scope of this blog, but worth a read.

There are a couple of key lessons for analysts, engineers, and business architects.

• Be Clear and Honest About the Goals of Any Change.   This may well be the most important point.  Hidden agendas add complexity without bringing any real benefit.  Watch for them in yourself and in all stakeholders and team members
• Know when it is time to throw away the current process and start over. This is probably the most difficult point.   Today, most of our change and many of our systems are created iteratively and incrementally.  And there is good reason for this.  Lean process improvement and agile development methods have shown their value in a wide range of applications.  Still, it is important to note that by bolting changes onto an existing system, we are building a kludge, and at some point the kludge will need to be reengineered.

For us, the challenge is getting ahead of the changing environment, and to be the one who shape the future, not the ones shaped by it.   In her latest article at BA Times, Kathleen (Kitty) Hass challenges business analysts to become strategic executors of change. 

Hass tells us to think strategically and holistically, and always communicate business value.

It is critical for the BA Practice Lead to think and communicate holistically. In the context of business, holistic thinking takes into account the purpose, values, function, process, and structure of the organization. Holistic thinking forms the basis for everything BA Practice Leads do:

• Examining a complex system
• Developing the business design structure, the business model
• Problem solving
• Forming and executing strategy
• Communicating strategically

The whole article is definitely worth a read.  Kathleen  B. Hass  “Communicating Strategically – It’s Like Stakeholder Management on Steroids