Category: Complexity

Stories and thoughts about inherent complexity

Posted on

The Rudiments of Asset Management

There are two topics herein; the first is on reusability with Microsoft™ – powerpint in particular, and the second on initiating a reusable asset program.

In one of my recent “previous lives”, there was a pressing need to produce reusable intellectual capital (IC) to permit our consulting and coaching practice to grow. The shame of it was, we just couldn’t do it. Because of time constraints (gotta be productive!! gotta be chargeable!!) we were unable to effectively codify what we learned so that subsequent practitioners could build on that learning. We also tended to put everything into PowerPoint™ [1]. (I call it powerpint, I hope that doesn’t get me in trouble with Microsoft trademark enforcement!) 

As it transpires, it appears to be very difficult to develop effective reuse patterns for powerpint; we didn’t find a way. The elements of reuse are single slides or small groups of slides, and the elements of configuration management are larger and essentially indivisible groups of slides called decks. This impedance mismatch makes a simple reuse task boringly and tediously difficult. (And it’s much more difficult when the only “asset repository” your organization makes available is email – s-m-h.) I’ve heard there is a composition manager available to pull the current versions of single and small collections of slides into “the next deck” but I’ve never been in an organization that uses this composition manager, if it even exists. I suppose it would be possible to code it up in Visual Basic™, but I’ve not seen that done. 

A conclusion is, yes, graphics are important, but use them effectively and if you are building lots of pictures, consider changing your paradigm from glossy powerpint to meaningful semantics with a genuine model-building application whose diagrams are views into the underlying, all-important semantic model. When I was at IBM, our original go-to for this was Rational Rose; later it was Rational Software Architect. I’ve not found a free UML modeling tool that will do this job with any clarity but all the ones you pay for probably will do it. Unfortunately, this results in the need for a considerable investment in training time and tools. I’ll consider this aspect more carefully another time. Meanwhile …

Developing Reusable IC while Engaged

The best way to develop reusable capital is for its immediate use in the context of one’s current consulting/coaching engagement. One is on the ground, executing, and realizes the need for something, for the benefit of the client. Sometimes it’s a new way of doing business. Sometimes it is an artifact or collection thereof that can be used to facilitate some processes. Usually, it’s both, actually. You build what you need, you try it out and experiment with the client or customer, you refine it based on that experience, but not too much to avoid gold-plating[2], and then you submit it to the asset repository. And there it sits, waiting for the next need.

The key to its eventual excellence is its reuse, and the first criterion for that is someone who needs it actually finds it in the repository – we’ll get to that in a minute. Effective reuse does not always look like, “Oh, here! This is perfect! This is exactly what I need!” This is often called pulling the asset off the shelf. It’s rare, but it’s nice when it happens because you’ve found something that will save you work. More often though, effective reuse looks like this: “This might work. I’ll make some refinements to suit my client’s situation and then give it a try.” Once it’s been refined and used, it is reviewed and possibly refined again – but once again not too much to avoid gold-plating2 – and placed back into the asset repository as an update or new version for the next consultant/coach to use.

Note that now, this asset is useful in two different engagement contexts. When a third context arises, it is likely to be better fit-for-purpose and require less work to get it to the point where it is usable in that new context. (It is important to ensure that you don’t break it for purposes of previous contexts to which it has already been applied.) In the fourth context, it’ll be even better. It might never be reusable just by pulling it off the shelf and starting it up. Some small amount of configuration or customization might be required every single time it is used. But it is better every time due to the continuous improvement applied to it, and due to the time and especially thought savings associated with its reuse.

Finding the Asset

I learned the above Build-while-Executing pattern for building and maintaining quality reusable engagement assets while I was at IBM. Most of what I learned came from the gentleman who led the small staff of, well, I’ll call them librarians, who made the asset repository sing; his name is Darrel Rader. Believe me, I consider the role name librarian a compliment. If I recall correctly, our consulting staff was about 500 worldwide and his staff numbered maybe 5. Maintaining the collection of reusable assets in a suitable repository – indeed a repository designed and developed by a team at IBM Rational led by another mentor Grant Larsen, for expressly this purpose – was hard work. This investment paid off extremely well. Hundreds of engagement assets were pioneered and then refined in engagement after engagement, and it served to save consultants lots of time and improved engagement quality significantly as time passed. I can only hope that the repository still exists and is maintained within IBM. I’m afraid I don’t know.

Darrel spent an impressive amount of time on Search and Find. It turns out, for Darrel and his crew, the assets were the easy part: the consultants built them on their own and were happy to do so! On submission his crew would review an asset, possibly suggest minor improvements, and then categorize, package and tag the asset within the tool, called Rational Asset Manager (RAM). This was really important, because if it was poorly packaged it would be hard to reuse, and if it was poorly tagged, no one would ever find it.

Packaging

Packaging proved to be extremely important in order to avoid duplication of artifacts. It is worth pausing here to provide a few definitions:

Artifact: a document, for example a powerpint deck, a word document, a spreadsheet, a text file, a model file. A single thing. If a group of files belonged together tightly, then it might be a zip file containing those in that group. But an artifact is a single thing. An artifact can be a reference, that is perhaps a URL or some other reference which points to the physical file located in some other repository like Jive™ or Sharepoint™ or git™. And finally, an artifact should be (or become soon) a formal member of one or more assets. Artifacts can be tagged.

Asset: a governed and audited collection of related artifacts with a declared purpose. We endow the asset with a lifecycle to promote an asset-based form of governance, that is we make decisions on how the asset can/should be used by reviewing the quality of the asset when or after work is done on the asset (not just on whether the work is “done”). We enable this by endowing the asset with a lifecycle (state machine) – probably derived from its type, and a state within that lifecycle. As mentioned above, an artifact might be found in more than one asset; as such, it should be equally usable when sought by practitioners looking to use any asset which references that artifact. Assets must be tagged and categorized; one must be able to find them when they are a possible contributor to the solution to a consulting/coaching issue.

The flexibility implied by the above packaging implies that there is work to maintain the packaging. A category hierarchy must exist, but much more importantly, a tagging taxonomy must exist. We found as this capability was being developed at IBM that we quickly lost control of tags. We solved this problem by enforcing that tags be part of a managed tag taxonomy. If you needed a tag that wasn’t in the taxonomy, you went to Darrel’s team, and either they would find you the tag you needed, or they would invent one with your concurrence and place it into the taxonomy, and finally tag your asset with that tag.

Searching and Finding

The taxonomy was the single most important element of the librarians’ efforts making the reusable asset repository useful in the long term. Put succinctly, if you were looking for something, you consulted the taxonomy, chose your search terms, did your search, and behold … assets worthy of your consideration for use/reuse.

Discipline and Evangelism

A most important role of the librarians was evangelism. Encouraging practitioners to build and submit, or find and refine, assets in conjunction with their work never stopped. This would not have worked had the practitioners (coaches and consultants) lacked permission and the resources to build, refine, and share ownership over our reusable assets. For example, if one is continuously “full time” on engagements, asset development rarely occurs. It was also common for the librarians to review a proposed submission and suggest combining it with a previous submission or two to make a refined asset rather than a new asset. It remained difficult to find what you were searching for even with all the effort on tagging. But it was possible and worth the effort.

Summary

The above constitutes the beginnings of a genuine intellectual capital development and leveraging strategy, backed up by an ongoing investment in growing capability, both in tools (repository) and labor (librarians and consultants). The result was a robust reusable asset management program that yielded higher quality consulting and continuous improvement. It also made IBM a joy to work at, because your work was acknowledged and supported. Indeed it was specifically measured by reuse! and rewards acknowledging contributions were possible based on the measurements. Indeed my friends, those were the days. 

[1] with apologies to Microsoft™ because PowerPoint isn’t really a bad product, just a horribly misused one. I do have a friend who says “we are all subject to the vast mediocrity of Microsoft”, but that isn’t quite true, although it does often require organizational buy-in. If we have that, we can rise above it with some effort, and it’s often quite valuable to do so.

[2] Gold-plating, see https://densmore.lindenbaum.us/dysfunction/rock-engineering/

Posted on

Systems, Complexity, Crashes, Oh My

This blog entry is written together with my old IBM buddy Mike Mott, Distinguished Engineer Retired[1]

As my colleagues and friends are aware, I am fond of discovering unbridled and poorly managed complexities that result in bad stuff. I don’t look for such issues that have killed people, though it has happened. But pretty much everything else is fair game, including the YF-22 accident where the test pilot left the prototype airplane via the ejection seat because he suddenly was utterly unable to control the airplane. As it transpires, there was a section of computer code tasked with translating pilot commands into control surface actions where there were eight discrete modes, and the pilot had unwittingly flown into the one of those eight that had never been tested until now. There was a sign error. Up was down, down was up. Close to the ground, there was no time to figure it out. Scratch one really expensive fighter jet. 

A recent, and very public, complexity issue presents itself as a target rich case study for how to avoid doing business with software, and that is the results reporting from the Iowa Caucuses. There are much better approaches to the management of high-tech programs.  There is a huge difference between hacking out an app for a smart phone and building a system to support a caucus.  The app is used in support of a process of vote counting, reporting and summary.  All of the people involved in this process must be properly trained to perform their roles.  The app must be realized in hardware, which requires loading and testing of the app in the production environment.  The networks and servers that realize the results must provide enough capacity to perform the computer tasks within the timelines. Use Case modeling of the end to end system operation is an excellent way to flesh out the preparation work for the caucus and the performance of the precincts on caucus night.  

Surveying websites such as sysml.org from time to time, the trend is good; modern system management technologies are evolving well.  However, reviewing pmi.org, it is still stuck in the past with the same old work breakdown structuring and risk management approaches that we know lead to long feedback loops, poor quality and performance issues.  There is a gap between the technologies available for the system itself, for system development, and for the approach used by program managers to pull it off.

Now, as my buddy Mike writes …

Looking at Iowa from afar, it seems obvious there was a total failure to plan the scenarios, the intended results, the usage models … or maybe anything at all, as though it was just going to work.   I would bet the house, farm, and alley cat that no clear-cut statement of objectives were ever written or socialized. They needed measurable outcomes to shoot for, something like “we shall have the conference results complete within 2 hours of when the doors close to start the caucuses”.  Another bet: not a single Use Case (or Epic, or group of scenarios, or whatever you want to call it) will be found in their statements of need that lays out the entire process of taking votes to result.  And stunningly, it appears that no thought whatever was given to the hardware realization. They left it at “hey, we have an app”. According to Chad Wolf, Acting Secretary of DHS, during an interview Tuesday on Fox and Friends, there was no viable test plan, and it wasn’t for lack of resources, the DNC actually declined an offer to test the system by DHS’s Cybersecurity and Infrastructure Security Agency. It also appears that the folks involved even now don’t understand what happened. All these issues are being spoken of by the DNC as a simple app failure. Indeed, that’s a piece of it, but astute observers know that the larger failure was one of project management and/or product development management.  Success on a crucial, scaled system must consider the people, process, tools, and technology.  But no … they believed an app purchased from Mrs. Clinton’s former campaign manager would ensure the caucus ran well.

Alas, this seems very typical of how government spends our money.  Even after so many lessons, in the form of failed systems, have been rolled out for the world to see. The government lays out huge projects that fail time after time, with billions wasted. Is there no self-reflection or retrospective at all? There doesn’t seem to be. Would it not make some sense to seek assistance from those who have actually delivered on big efforts?  On this point, it is notable that Vivek Kundra, young Ph.D. IT wunderkind, President Obama’s information czar and the first CIO for the federal government, invited major players in the industry to come and explain to him how the government could improve their IT performance. I developed material on the topic for my colleague Dave McQueeney, still at IBM, who pitched the slides to Kundra.  To his credit, Kundra eventually published a 25-point plan to improve the federal government’s IT performance. He leaned more heavily on Agile principles and Agile methodologies than on the architecture quality-driven Model Driven Systems Development (MDSD[2]) process framework we developed at IBM Rational to manage such high-complexity programs. Alas, I understand that IBM just didn’t quite connect with Dr. Kundra.  Today, he is out of government, and the initiatives he started spent around $1 billion – they never die! – but are effectively complete.  

As a number of outlets reported, the testing of the app was limited (ref Slate[3]).  Indeed.  Pulling on this notion of a system – the app was part of the larger process of the caucus.  The caucus leadership had a process to follow.  Was it documented? Was its use rehearsed?  Obviously not.  According to Slate, “The problem with the caucuses is that we don’t run them except in a major national election, so there’s no way to ramp up to it. Imagine going to war with only war games under your belt, without facing an actual battle.”   Although they knew this, the Iowa DNC failed to properly train their people in the use of a new app; ensure that the new app was installed and ready to go; or verify that the system hardware was scaled properly to support the load.  

Ok, Jim here. To summarize, it seems certain that eventually … eventually … the ideas of incremental development yielding short feedback loops, ongoing risk mitigation, more objective and measurable criteria, end-to-end testing of the technology with the processes, and explicit management of system architectures as represented in multiple stakeholder viewpoints will get through to the Project Management field.  It appears to Mike and I that the expected path for that will be via Agile. Indeed, as it evolves, it is adopting many of the tenets of of MDSD. 

[1]  https://www.linkedin.com/in/michael-mott-3590997/

[2]  https://www.academia.edu/9790859/Model-driven_systems_development

[3]  https://slate.com/technology/2020/02/iowa-caucus-app-fail-shadow.html

Posted on

Solving the world’s problems

I had breakfast today with a gentleman I know from the swimming community, Ira. Ira has had a long and varied career in a number of industries, but the one that may have given him the most intercultural experience is banking, where he was stationed in Hong Kong for awhile. His experience in banking gave him a really mature view of capitalism and culture. We had a long conversation about what’s gone wrong in the U.S. of A. – why are companies and our government so short-sighted these days. And of course we came away from breakfast with all the answers, if only someone would listen.

One element I introduced is an enormous cost focus. In environments where the cost side and the benefits side are poorly connected – which is most companies with a traditional management style, unfortunately – the only way most companies measure their people in cost centers is reductions in costs. I sometimes combat this with the idea that if all you want to do is reduce costs, then just send everybody home. The resulting conversation usually centers on the value being provided, and the poor connection cost centers often have to that value they generate.

An anecdote I mentioned is something I learned 45 years ago from my Dad as he got caught up in it. As it transpires, the Nixon Administration made a decision to eliminate government-based research and development arms. There were many such R&D organizations, and with a stroke of his pen Nixon eliminated all of them, except, I believe, those within DOD. My Dad, for example, was employed in R&D at the Department of Transportation, and suddenly he was on the street. Is it appropriate for the government to explicitly spend taxpayer dollars on the long view? It’s hard to say, but we know a couple things, first that most for-profit organizations will not spend, or spend very little, on the long view, and second that a culture often stems from what’s going on at the top. I contend that the elimination of any focus in government on the long-term contributes to the lack of focus in American industry likewise. So my answer is a measured Yes.

Ira encourages balance in the consideration of four collections of stakeholders to a company, any company. I think this applies to (government) as well. They are:

• The shareholder (taxpayer) – looking for business value
• The customer (citizen) – looking for personal value
• The employee – looking to make a contribution
• The enclosing community – looking to enhance, well, community.

Do companies today achieve this balance? We think not. In particular, the employee today is being given extremely short shrift. How long will that last? Ira fears a revolution. No, he doesn’t mean like the American Revolution. He means a sea change in the way organizations and employees interact. Airbnb, Uber and other such organizations may already be hinting at this. If we don’t have any employees …

Many of humanity’s best innovations have come from large groups of teams crafting good business results around a tight vision to which they are justifiably loyal. Agile and Lean motivate this sort of behavior for good reason. Hewlett Packard comes to mind as one of the best of these organizations. And how far has HP fallen since its high? I know several former HP employees who still crow about the loyalty, how hard they worked, the crispness of vision, and the incredible results they achieve. I don’t know how far they’ve fallen – it depends on whether you look at HP, Keysight or Agilent. Oh … I guess that division itself tells the lion’s share of the tale.

Agile’s values (agilemanifesto.org) are germane, particularly the first one in this case as it asks for the fundamental of respect:

• Individuals and interactions over processes and tools
• Working software over comprehensive documentation
• Customer collaboration over contract negotiation
• Responding to change over following a plan

If my experience is any guide, many large companies are having an extremely difficult time adopting Agile. The difficulty is more than “change is hard” , which already makes it pretty darn hard. We all know change is hard. But some companies can’t do it, even though they know it’s important. In any initiative, we have uncertain outcomes (often poorly articulated unfortunately), reasonably well understood (and somehow never inexpensive!) costs, and finally the benefits from those outcomes generally don’t begin to accumulate visibly until a significant amount of the initiative has been implemented. (In a pure Waterfall environment, no benefit accrues at all until the entire effort is complete!) The essential issue too often seems to be we can’t afford to change, because our view is too short-term to articulate the benefits enough to outweigh the costs, or in terms of money so that one can directly compare benefits to costs.

What we realized today over breakfast is that a similar argument seems to be in play regarding cultivating and retaining employee loyalty. We gotta fix that.

Posted on

Phones suck (a rant)

Every conference call I’m on … I really think it is every one … has issues. We can’t hear you. Can the person whose dog is barking go on mute? We’re seeing a screen, but it’s not a screen that appears relevant. Wait, I need a therapeutic reboot. We still can’t see your screen. Can everyone go on mute there’s a lot of background noise. What did you say/ say that again? I didn’t hear anything after holy crap, can you say everything again after holy crap? Ok, I can almost hear you, I’m getting about every fourth packet. I give up, I’m going to hang up and dial in again, I hope that’s better. Or what I just did on a call: silently hang up and fail to dial back in, it just wasn’t worth it.

Individual calls – just two people – are not far behind in quality. They’re just poor quality most of the time. I long for the good old days. Yes, my phone wasn’t in my pocket, but every time you picked up the phone, it worked, and it was high quality. btw I get pretty good service from Skype, of all things, it usually works pretty well. However now that it has been acquired by Microsoft I’m not expecting great things going forward. We’ll get more features and poorer quality.

Collaboration between people in far flung locales requires excellent voice, screen share and video capabilities. We just don’t seem to have that – not even close. I hope one day these facilities improve. Building great things requires seamless collaboration.

Posted on

Rock Engineering, Gold Plating, and Features

I used to have this post somewhere else, but it was inside a “previous life”. It got impressively long (see gold-plating below), and even talked about Beethoven. I’ll start this out small. Maybe I’ll enhance it with  some of those additional stories at some point.

The intent is simply to identify and describe anti-patterns associated with Requirements. Mostly this is for fun, because we don’t do Requirements anymore in Agile (although the lessons within these anti-patterns do have applicability in the Lean/Agile world for sure). Instead, in Agile, we often use the XP constructs user stories and epics, or sometimes just a simple and regular flow of enhancements and other issues. In OO we do use cases and scenarios. In any case we’ve recognized that they’re not really requirements; they are – to quote one of my mentors Walker Royce – desirements. That is, they’re negotiable.

Contents

  • Rock Engineering anti-pattern
  • Gold-Plating anti-pattern
  • Features

Our first anti-pattern is Rock Engineering. It is a form of crafting a solution to a problem that doesn’t exist, or a problem that is poorly understood. It goes like this …

King: “I need a rock. You there, go bring me a rock.”

You: “Yes, Sire, I shall bring you the finest rock in the land.” (and so you go find a rock.)

You: “Sire, I have brought you a rock, here it is, it is the finest rock in the land.” (Present with flourish)

King: “This is not the rock I need. It is too small.”

You: “Yes, Sire, I shall go find you the rock you need, the finest rock in the land.” (and so you go find another rock)

You: “Sire, I have brought you another rock, here it is, it is the finest rock in the land.”

King: “This is not the rock I need. It needs to be brown, and this rock is gray.”

You: “Yes, Sire, I shall …”

Of course, we can go on like this for hours until we accidentally bring the King a rock that he finds suitable, and even then it might not be exactly what he was looking for. What we need to do is elicit some requirements, shorten the time by focusing in on a solution that meets the actual expressed need. In order to do this, one is going to have to ask questions! Of course, if any time one asks the King a question one’s head is removed, that might be a cause of this wasteful behavior we obviously refer to as Rock Engineering.

Gold-Plating

A poor practice accentuated by Waterfall is called gold-plating. It occurs in conjunction with developing some capability that we perceive is needed or has been asked for. We have plenty of time to develop it, because it’s Waterfall and there’s never any urgency early in Waterfall. Let’s be sure we get this right and Wow our customer. So in addition to the bare minimum need we go over the top and really add some bells and whistles.

Yup, this is called gold-plating. Several results can accrue, and only a few are good. Among the not-so-good:

  1. Customer says, wow, that’s really cool, but I don’t need that and I’m not going to pay for that. All I needed was the functionality I asked you for.
  2. In your zeal to build this cool stuff, you injected Mr. Debt. Mr. Technical Debt. It’s buggy. It doesn’t run, or it runs slowly or otherwise unreliably.
  3. You overrun the time budget and/or the dollars budget.
  4. Your supervisor discovers that you’re overrunning the time/dollars budgets.
  5. Customer says, ugh, that’s really awful, that sucks, and I really I don’t need it so I’m not going to pay for that. All I needed was the functionality I asked you for.

One reason for Agile’s focus on values like sustainability, the customer, customer collaboration, short feedback loops and minimum viable product (MVP) is to avoid this anti-pattern.

Features

This one is short but I found it amusing once upon a time.

Definitions:

  • Bug: informal name for a software defect. The name arose because Adm. Hopper was tracking down a defect during some of her early work and found a physical bug in the hardware that was shorting it out and yielding erroneous results. Often depicted graphically as the image of an insect.
  • Feature: a bug that has been lovingly documented and memorialized in the software and its documentation artifacts. Depicted as an insect wearing a tuxedo.