CSC’s Solution Architect Development Program
April 28, 2009
I applied for CSC’s Solution Architect Development Program a few weeks ago – one of five at this site in Cambridge of which I was the only one to make it past the first round. I did my phone interview while I was on vacation at the Bitter End Yacht Club in Virgin Gorda , BVI. I got the notice of my interview when my office called me the day before, and it was a bit tricky making all this happen as I had not taken my laptop with me and had to fill out yet another form before the interview. I asked Muhannad to send the form to my public email on MSN. Fortunately my daughter had brought her laptop, and I was able to persuade her to let me use it in the evening to download the form. The only decent wifi spot was in the bar area where a reggae band was playing, making concentration impossible, but I was able to download the form and work on it in the quieter hotel reception area. I did the interview the next day by cell phone sitting on the upper deck of the reception area, overlooking the bay, mimosa on hand. The folks who interviewed me asked good penetrating questions, to which I felt I gave only mediocre responses, but the point is, that this could probably not have all come together like it did a few years ago. With cell phones, we expect to be directly reachable all the time, and we expect to have computers with common software installed and good Internet access. With the emphasis on reduced emission, and now this latest scourge, the swine flu, we have got to make virtual teams work. I’ve been reading Craig Larman’s book on Agile and Iterative Development and while appreciating all that he has to say on agile development, it remains an assumption by most authors that team members can be collocated. As humans, we rely to a huge degree on non-verbal communication and the sense of camaraderie that working in the same place fosters, but we need to make virtual teaming work.
High Reliability Organizations and Agility
April 29, 2009
I just finished Craig Larman’s book on Agile Development and began reading Managing the Unexpected by Karl Weick and am noting similarities in the way he describes High Reliability Organizations (HRO) and agile methods. One of the challenges we have in software development is to find a workable management style for the development teams. My experience is that, with rare exceptions, BP and IT managers still think of software development as 2167a waterfall, and they are really not that interested in becoming part of the development team. When they do become part of the team, they tend to overreact on the side of organizational inclusiveness, and you end up with more SMEs than you need, and then only for the initial phases of the development effort. (And of course, like any bureaucracy, fail to heed the observation that “availability is not a skill.”)
Perpetual Paranoia
April 30, 2009
Karl Weick talks about mindfulness in his book on HROs. This state of mind is both individual and organizational -– if an organization can be said to have a mind — and is an idea that several other authors describe using different terms. Reason (I think) has called it “perpetual paranoia”. When I was sailing in the BVI last week, my instructor told me much the same thing in the context of avoiding collisions: “The first rule is never to assume that the other guy knows what he’s doing!” Mindfulness, I submit, is something that forms part of expertise. If you know what to expect, and can resist the temptation to be a “yes-man” and look for confirmatory evidence, then you are more likely to notice discrepancies. Looking for movement is one of the things our brain is set up to detect, and a difference from the norm is also a kind of movement, although not in a temporal dimension. Another Karl, Karl Popper, talks about the asymmetry of evidence in proving, versus disproving, a hypothesis. Famously, he talks about how the hypothesis that “all swans are white” cannot be proved by observing white swans, no matter how many white swans you observe, but can be disproved by the observation of a single black swan. This mindfulness, the ability to look for evidence to indicate that the things are not what they should be is, I submit, what regulatory agencies need to embrace; they should drop this silly idea of becoming a proactive organization. Proactive means “Acting in advance to deal with an expected difficulty.” This is a lofty goal and I don’t think it can be achieved. What can be achieved, however, is to improve mindfulness and retain the agility to react more quickly and expertly to deviations from the norm. I may see a deviation but sill not knows what to expect, but have a notion that it’s reducing safety. I don’t need to know how that deviation will play out because there may be other deviations that form part of the safety chain that I haven’t observed. Reacting to such cues may appear to a novice observer as being “proactive” but it isn’t – it’s just that the expert is reacting to cues that are not observable to the novice.
Is SMS a System?
June 30, 2009
The term System in Safety Management System refers to the system of controls applied to the operational processes of a certificate holder, and that produces safety as its output. This system is characterized in the three box model as a protection system, in contrast to the production system that delivers freight and passengers to their intended destinations, and the oversight system exercised by FAA. The use of the term system to describe such an assembly of processes and controls is somewhat of a stretch. To the extent that such an assembly can be called a system, it is an open system, using the terminology described by Gerald Weinberg in the standard textbook on the topic “An Introduction to General Systems Thinking.” There are multiple factors that affect safety that are not under the controls of Flight Standards and the Certificate Holder such as the environment (Canadian Geese, to mention a recent example), Technology (until recently, we did not know how to inert aviation fuel), and economics (certificate holders have to be able to stay in business). Furthermore, the output of an SMS is safety. But safety is not directly observable. To the extent that it is observable, it is as the absence of undesired outcomes. Thus it is difficult to determine whether the system is working, since the absence of events may be due to other causes than the ones under AFS and certificate holder’s control.
Brave New World
July 1, 2009
All this week Miranda, my 15 year old daughter, has been riding in with me on the commuter rail from South Acton Station to North Station in Boston, from where we take the Green Line to Government Center and the Blue Line to the Aquarium. For the first time this morning, I got off at the Porter Square stop to go to work in Kendall Square, leaving her to navigate the rest of the journey to her job as a CIT at the New England Aquarium summer camp program. It often strikes me when I ride public transportation, what a diverse set of people are in this world. Today, for example, there were buskers both at the Porter Square stop and the Harvard Square stop playing the cello – students on summer break from one of the colleges, gaining a little public exposure? Sitting on the train in front of me was a 60ish Asian gentleman with short cropped graying hair, dressed in a military jacket bearing a stars and stripes pin and a “Free Tibet” button. He held what might have been a spear, or at least some kind of stick, wrapped in an off-white fabric, and was telling beads on loop of string while softly chanting. A monk at a local temple? Next to him sat a nondescript student exploring his new iTouch – totally unremarkable these days – but what would we have made of this gadget a few years back?
Miranda has been texting me at each jump in her journey telling me where she is. There’ll be a time when I won’t be around. I wonder what she’ll see on her journeys?
There Once Was a Note
July 16, 2009
Like most people, I’ve often wondered what heaven is like – or rather, I wonder what other people think heaven is like. As a child, I suppose I believed that you’d be reunited with people who’d died, but of course, since all the people I knew who’d died seemed to be about the same age (old) I didn’t worry about what stage of life they’d be at. So what is heaven like? Are you reunited with all the people that you’ve loved or just the virtuous ones? What about pets? What about places that you loved and that have been replaced by housing developments and shopping malls?
My mother died this week, and I’m reminded of one of my favorite “old timey” songs that I first heard sung by Mike Seeger.
I am a poor wayfaring stranger
Traveling through this world of woe
But there’s no sorrow, toil, or danger
In that bright world to which I go.
I’m going there to see my mother
I’m going there no more to roam
I’m only going over Jordan
I’m only going over home.
My mother, in the last few years, was not the mother I remembered growing up with. She had developed Frontotemporal Lobe Dementia and no longer had interest in people. She recognized us, her children, but no longer had the same personality. I don’t know if she remembered who she used to be or was aware of what she had lost. Perhaps she did but no longer cared.
Last night I lay awake remembering scenes from our life growing up. Holding baby Katy, my younger sister. Cooking leg of lamb for Sunday dinner. Smoking a cigarette in the front seat of the car on our summer vacation in France. She was intensely interested in people and had a knack for spotting celebrities in the street. She had a remarkable memory for all sorts of trivia and I often wonder what she would have made of her life if she had had the opportunities that we have had. Even as an older person, I remember walking with her to the town center in Saffron Walden and stopping every few feet to talk with a neighbor or to point out where someone lived. All of this disappeared in her later years. Talking to her just seemed to annoy her. I remember calling her one day and a football match was on the telly, and though she didn’t even like football she kept it on while she gave automatic responses to my attempts to engage her in conversation.
A few years ago, when I was laid up in hospital, under the influence of some heavy duty narcotics, I had an experience which I suppose corresponds to the Zen concept of the “eternal now.” I was listening to a Haydn symphony and I heard and understood every note separately, complete in itself, weighing for eternity. I understood that the moment that I observed did not disappear into the unreachable past, but that it existed, and that though my point of view might shift, the note stood for eternity. I think Pete Townshend must have had a similar experience.
There once was a note, pure and easy,
Playing so free, like a breath rippling by.
The note is eternal, I hear it, it sees me,
Forever we blend it, forever we die.
That’s how I remember my mother. Not how she died, but how she lived her life. And that, of course, is the meaning of life.
Strategic Uncertainty
August 25, 2009
I’ve been reading “The Strategy Paradox” by Michael Raynor, a book that Toby Elwin put me on to. The thesis of the book is that “Extreme positions in strategic space create the highest levels of profitability, but also create the highest levels of strategic risk and hence failure.” Although targeted at the commercial world there are also lessons that apply to the regulatory world. A few years ago at a safety workshop at Redondo Beach I had a beer with a safety inspector who shortly thereafter was promoted to be the principal operations inspector of a major airline. He observed that, while selection to become a PI was an important step in an ASI’s career, forever thereafter he would live in hope that his airline would avoid a major accident, because if they did have an accident his life would become one of answering questions as to why he hadn’t done this or that to forestall the event, and perhaps asking himself the same questions.
The FAA comes in for frequent lashings from NTSB , congress, and the press, and while some criticism may be justified, a good deal of it is both unfair and unhelpful to the agency’s safety mission. Although these critics presumably understand that you can’t predict the future, they continue to fall back on ineffective models of accidents being caused by an easily understood chain of events. Leaving aside the questions of what type of accident model you use, one thing is certain, it’s easier to identify the precursors of accidents after they have occurred than before – the question is how well one can reduce future risk given current knowledge. This is precisely Raynor’s point when he makes a distinction between forecasting the future with the future, and with forecasting the future with the “future present” that eventually obtains. In other words, at any given moment of time there exists a range of futures that might occur, and that is how one should evaluate the goodness of forecasting, not with what actually occurs. Given enough forecasts, someone will always turn out to have been accurate, but we don’t know at the time who that will be.
The counterpart of strategic uncertainty in a regulatory agency is the need to organize for robustness against a range of risks and hazards. This robustness comes at a price – less than optimal efficiency. The organization is working to mitigate future risks that are entirely possible but actually never transpire. That does not mean that the effort could have been better directed elsewhere — we are not working in an efficient system. One might conclude therefore that there is nothing one can do to address this issue, but Raynor goes one step further and recognizes that the issue of strategic uncertainty is tied to the time horizon. At the operational level one has a time horizon of days and weeks, while at the strategic level one has a time horizon of several years. The FAA has been labeled the “tombstone agency” but this characterization fails to distinguish its operational and strategic roles. At the operational level, there is nothing wrong, and indeed it is quite appropriate that the agency react to short term priorities and, especially, it must know how to react promptly to accidents, incidents, and other events. At the intermediate level, a process of selecting important problems and fixing them, as espoused by Malcolm Sparrow, is the appropriate course of action. But risks, by definition, are in the future, and it is at the strategic level that the agency can perform hazard identification and risk mitigation. Aviation safety already structures the organization by SMS pillars (policy, assurance, risk management, culture) and aviation system levels (national, organizational, individual), and should also structure itself according to different time horizons.
On Agile, PMBoK, and CMMI
September 29, 2009
The project manager doesn’t talk, he acts.
When his work is done,
the team members say, “Amazing:
we did it, all by ourselves!”
Tomorrow is the last day of fiscal year 2009, and you know what that means to a government contractor, don’t you. It means that you have to have all your plans in place for next year, even though the dollars haven’t shown up yet, you don’t have the staff, and the sponsor is continuing to shape the SOW. I’ve been a PMP for a number of years and while I find value in the PMBoK discipline and the common language that it provides, there’s a lot to be said for the agilist point of view. There are a slew of articles on the internet about integrating Agile with high ceremony approaches to software development. Two of the groups that I belong to on LinkedIn are the Agile CMMI (3,788 members) and the Agile Project Management Group (4,048 members). Some would say that they can’t be integrated, and others are trying to develop hybrids, but who says you can’t have both? Now I know that “Truth by analogy is fraud.” (Stroustrup) but isn’t this a bit like having an argument about whether Newtonian Mechanics or Quantum Mechanics is correct. It seems to me that Agile is just a better approach to running a software development team of skilled practitioners, and that high ceremony approaches (PMBoK, CMMI) are better at providing accountability to the customer. Agile works in short sprints, and although they may be the same length, the character of the sprint can change from the beginning of the project when you’re trying to figure out what to build, to the end of the project when you’re trying to tie all the loose pieces together and ship the product. Projects have a longer view – at least they do around here – and cover a lot more ground than just software. The unifying feature is that both sprints and projects deliver something of actual value to the customer for an expenditure of effort over a period of time, and both have measures. Agile has its burn-down charts and project velocity, and PMBoK has its EVM. Now if I can just figure out how to derive one from the other without increasing my workload, I’ll be happy. And that’s my next project.
Bad Doc!
November 2, 2009
I attended a presentation on Scrum last week, and afterwards my boss made a telling observation that none of the artifacts of Scrum (the Product Backlog, the Sprint Backlog, and the Burndown Chart) are of any use after the product is developed. Agile’s preference for working code over documentation makes it an easy target in the government world, where the objection is that we need both. One of the smartest and most productive developers I ever worked with rarely sent emails or wrote anything down – he used the whiteboard a lot though, and you could always drop in on him and he’d be happy to show you what he was working on. Customers, however, almost always want the documentation since it gives them the sense of security that they could, if they wanted, hand the product to another developer. Since customers define value, not developers, who are we to tell the customer that they are mistaken?
That’s not to say that there isn’t a lot of effort put into developing documentation that will never be used, either because it’s not needed or because it’s poorly produced. Bad documentation sends a message to the reader that his (or her) time is not valued. On the other hand, good documentation, printed on paper, can convey ideas in ways that other modes of communication can’t. You can skip ahead if the current topic is already clear, you can page back to see where a topic was introduced, you can annotate it, and you can take it on the plane with you and not have to turn it off for take-off and landing. Creating documentation (not just writing – I include modeling in this category) can also help you think through difficult topics. The brain works differently when you are putting things down on paper or on the computer screen.
One of the causes for the proliferation of useless documentation results from folks not collocated with the team, assuming that documentation is the main mode for how the team communicates. It’s not. Team members do a good deal of their thinking, communicating, and learning by talking, listening, and challenging each other. Team members typically work with short time horizons. When they’re done with a problem it’s time to move on to the next. Notes and whiteboards and remembered conversations work well for developers. Customers work with longer time horizons, and want a longer lifetime for the ideas that they’ve paid for. For ideas to persist they have to be recorded in some permanent and reproducible medium. In this respect, writing code and writing documentation are not that different.
Stefan and Andreas Present…
November 20, 2009
Tuesday this week saw the launch of the Agile Special Interest Group at the Center. It was standing room only and we had 71 federal staff and contractors attend. Stefan and Andreas presented from Frankfurt and we handed out Jim’s white paper. I was pleased at the turnout; it seems that we judged the mood of the center right and succeeded in our one chance to make a first impression. The SIG team met this afternoon and we looked at the feedback. My boss, who till now has been somewhat skeptical on the topic of Agile, said he appreciated the realism that Stefan and Andreas brought to the discussion and he’s signed up to attend the Agile Boston event next week featuring Jeff Sutherland and Ken Schwaber, the co-creators of Scrum.
We had a few questions from the audience at the end of the presentation that illustrated a healthy recognition of the challenges that face us as we try to introduce Agile methods to the Center. With that in mind, I talked with Larry, our organizational change management guy, about doing an assessment of As-Is stakeholder positions on Agile, where we want them in the To-Be, and how we’re going to get there. My question of the moment is how to make Agile robust under a range of customer styles and preferences and team skill levels. Alistair Cockburn in his Agile 2009 presentation I come to bury Agile… revisits Shu-Ha-Ri and the three skill levels in an Agile team. Right now I think we have precious few Level 3s, some more Level 2s, and a lot of Level 1s. Of this latter group there are necessarily going to be some that have no interest in being anything else than a Level 1, and I don’t want that to derail the initiative. Having said that, I think we have a good shot of being better than we are, and am looking forward to the journey.
Signatures
November 6, 2019
I’m sitting in an Indian restaurant as I write this, killing time while I wait for the auto-dealer to prep my new pickup truck. I’m convinced the delay is intentional since they know I was coming in with a confirmed purchase agreement. Still never having worked at a car dealership I really have no idea what they’re doing, and as an article Credulity and Politics in this week’s Economist points out, we appear to be hard-wired to believe people, so I’m giving them the benefit of the doubt.
I had an interesting session with the finance guy signing forms with an electronic signature. I narrowly avoided buying a maintenance package I didn’t want. The options page on the tablet that the manger handed me presented three options. They were labeled something like Maximum, Premium, and Standard – or some such language – leading me to believe that Standard was the lowest you could select. We are also hard-wired to expect three options. Each of the three options had similarly labeled buttons, encouraging you to click one of them. I selected [Standard]. Tablet moved to the next page with a signature block. I signed. Then the finance guy slipped up. He asked me if I drove into Cambridge every day. I said, no – I drive to the train station and take the commuter rail in from South Acton, and that I didn’t expect to put more than a few thousand miles on the truck each year. “Oh, in that case, we can change your coverage from 8 years, miles to 10 years miles.” Back to the options page. This time it dawned on me that I was being offered additional coverage beyond the manufacturer’s coverage. I asked him if I had to pick any of the options. The answer was no, so I told him that I didn’t want the additional coverage, and that was that, I just had to sign that I declined additional coverage. Here’s the observations:
- The options page may have had a checkbox or something to indicate that I didn’t want any of the options, but I certainly didn’t notice anything. Presented with three buttons on a page and little else, it seemed obvious that I was expected to pick one of them.
- The signature block was on a different screen that did not show the options. With wet signatures, the signature line is usually at the bottom of the page or block, and it’s clear what it refers to. In the tablet version it was disconnected visually from the options page.
One more observation. Although some of the signing was electronic, there were still some forms that had to have a traditional wet signature. I assume that’s because those forms were covered by regulations that don’t allow for electronic signatures.
All of this has bearing on the work I’m currently engaged in for FAA where they are building a system that will do way with the need for wet signatures on forms and items that currently require them. Yes – I know wet signatures are “old century” things, and that electronic signatures offer many improvements, but they need to be accompanied by commonly understood design pattern so that folks that are e-signing have an understanding that is at least as good as wet signatures. A couple of top level requirements might be in order:
- When selecting options, all options should be presented in a visually similar manner.
- The signature block should be presented on the same page as the options.