Use Time on the Road Effectively

Posted on December 22, 2015 by R.P. Churchill

While a lot of folks are traveling for the holidays it’s a fine time to comment on how best to make use of your time while traveling for work. I’ve experienced three kinds of business trips and you should employ different strategies for each. Two things you always want to do are take care of your family by staying in touch and take care of yourself by trying to eat healthy food, exercise, and get enough sleep.

The Run All Night is the kind of trip where you’re going to be busy more or less around the clock. This may be true of trade shows, system commissionings, or sales calls where you’re meeting with customers morning, noon, and night. These situations are actually the easiest in which to be efficient because you have no choice; your time is mapped out for you. You’re trying to get everything done and are wishing there were more hours in the day. You should leverage colleagues at the home office if and when they’re available but the main thing you can do is take notes on anything that seems important that you want to get back to, so you can research it when you return home. These kinds of trips may throw a lot of ideas at you so it’s important to be able to capture a decent amount of information quickly. A note-taking app may be helpful but a voice capture device or app is even better. The latter allows you to capture more information and I always found the process of transcribing my notes to be an opportunity to clarify and better structure my thoughts. It’s helpful to do the transcription as quickly as possible but if it has to wait then it’s still better to get it than not.

The Nine-To-Five trip (which is usually more like Seven-To-Seven) is where you work more or less regular hours but over the course of many days or weeks. This setup leaves evenings free, may allow breaks during lunch, and may even include free weekends. If you’re traveling with colleagues you’ll probably spend some of the time extending dinners, grabbing the odd beverage, or checking out the local scenery but that still leaves time you can use for yourself. In these cases you’ll want to keep up with whatever reading you’re usually doing (you are reading something regularly, aren’t you?), review your notes from the day and do any research they might suggest, and possibly knock out an hour or two of a course or study project you have going. A subspecies of this kind of trip is the Steak Run, which is a brief trip for a short task or meeting. These usually involve a lighter work schedule and greater-than-normal conviviality. Don’t be stupid, but enjoy them when they come by.

The Waiting for Godot is where you often aren’t doing much of anything at all. I’ve experienced this on a couple of occasions–I’m talking four to six weeks of nothing. I will suggest that you want to avoid this situation at all costs if you can, unless you can make use of the time. My ability to make better use of the time when this happened to me (in 1996 in Korea and 1998 in Thailand) was limited by lack of ready access to the Internet. I could only get online through a Compuserve dial-up connection (in some cases only by dialing back to Pittsburgh), and traveling to remote places, like Tapachula, Mexico on the southernmost end of the Pacific coast bordering on Guatemala, in 2006, is the reason I kept that account for so many years. Now I keep it because AOL (and now Verizon) support legacy accounts for free, they’re good for social media and as a destination for certain kinds of mail contacts. Anyway, now that the Internet is nearly ubiquitous and a spectacular range of productive and edifying content is available there are no excuses. You want to do everything I’ve described plus you want to dive into some kind of class, research, or project. If you need ideas ask your colleagues or superiors for suggestions.

A big part of getting motivated to do something substantial is that you might not know how long the down period is going to last. If you know then you can plan but if you don’t, which is more likely, you have to be willing to jump in and get busy. Don’t wait so see if time is starting to stretch; it’ll stretch more if you keep waiting. You don’t want several weeks to have gone by that you could have used. If you get busy and keep busy, however, you’ll stay engaged and may even be disappointed when you have to back to your normal work. If that doesn’t happen for a while you can learn or accomplish something meaningful.

Don’t wait. Get to it!

Posted in Soft Skills | Tagged , , , , | Leave a comment

Discovery Takes Place on Many Levels

Posted on December 21, 2015 by R.P. Churchill

Technical projects involve learning on many different levels. You learn about your customers, your colleagues, yourself, technologies and techniques, modes of organization, ways to prevent errors, ways to add value, your customer’s project, how to do the next person’s work, and the endless surprises that always seem to crop up. I’ve always liked Bill Moyers’ observation about journalism in his introduction to The Power of Myth, that he wrote with Joseph Campbell.

A journalist, it is said, enjoys a license to be educated in public; we are the lucky ones, allowed to spend our days in a continuing course of adult education.

In truth the journalist brings a particular set of tools which allow that learning. A project team brings a set of skills it applies in its own way. The team isn’t just a machine meant to apply skills but also to learn—about everything listed above. This requires an open mind and the ability to adapt on the part of all participants. It is up to leaders at all levels to encourage everyone to be a mutually supporting part of the process.

Posted in Management | Tagged , , , | Leave a comment

Suggestions for How to Learn More Quickly

Posted on December 17, 2015 by R.P. Churchill

I’ve encountered a few interesting comments and stories about how to learn things more quickly. One thread that runs through all of them is frequent review. It’s one thing to blast through and learn something, even to the point of getting through a test or a class, but quite another to incorporate the new knowledge in a longer term framework.

Two writers and instructors I respect have created courses that involve presenting new material on Monday through Thursday, and then tie it all together on Friday with a review session that puts everything in context. One of them also suggests cementing your own knowledge by pretending you are teaching it to someone else. Teach to a wall if you need to. It doesn’t matter if anyone else receives the knowledge; what’s important here is the learner’s need to organize, structure, and simplify the information in his or her own mind. Teaching or pretending to teach provides a human motivation for getting that done.

A good curriculum will build on previously-acquired knowledge over the longer term as well. I remember hanging out with younger students in college and helping them with homework assignments I had done a year or two before. As we were working through some of the problems I was struck by how much easier they seemed than when I worked them the first time.

I’ve experienced this in other contexts as well. I’ve been swing dancing for a number of years and while I’d never suggest that I’m very good at it (I know enough to know some of what’s wrong by this point…) there have definitely been times when things have become more clear to me when I’ve been asked to explain them. There have also been a few moments where I suddenly understood something an instructor had said previously, sometimes by several years.

I also read that workers and managers who reflected on the events of the day before leaving tended to learn and adapt more quickly than those who did not. It probably helps if they make notes about those reflections. Engaging different forms of action and memory–seeing, listening, and writing–can help cement those memories as well.

Another common thread is simplification. Becoming an expert is partially a process of eliminating wasted motion. One wants to devote all of one’s energies to accomplishing a given end. This is true of throwing a curveball or teaching. I can’t find the nice article I read about a guy who measured the movement of his (amateur) wrist and compared it to that of a professional but this classic story about Richard Feynman should cover the teaching angle, as told by David L. Goodstein:

Feynman was a truly great teacher. He prided himself on being able to devise ways to explain even the most profound ideas to beginning students. Once, I said to him, “Dick, explain to me, so that I can understand it, why spin one-half particles obey Fermi-Dirac statistics.” Sizing up his audience perfectly, Feynman said, “I’ll prepare a freshman lecture on it.” But he came back a few days later to say, “I couldn’t do it. I couldn’t reduce it to the freshman level. That means we don’t really understand it.”

OK, so the method only works if the subject is actually explainable, but who can resist a good Feynman story?

Posted in Soft Skills | Tagged , , | Leave a comment

You Can’t Always Get Kismet, But You Can Avoid Terrible

Posted on December 16, 2015 by R.P. Churchill

Sometimes things just come together. You end up with magic. Kismet. And maybe a nice trophy.

And sometimes you don’t.

My fraternity at Carnegie Mellon was rarely any good at Buggy (also called Sweepstakes) but we were always competitive in Greek Sing and Booth. My big brother in the fraternity was booth chairman my freshman year so I always got cranked up for that event. The goal was to build a booth that was decorated to match that year’s theme, incorporate an engaging game, meet all the requirements specified in the rules, give away clever prizes, and maybe make a few quarters.

Come the spring of my junior year we learned that the theme for the year was “Adventure.” That was pretty generic so there was a lot of leeway. The previous years’ themes had been “The Wild West” and “The Lure of the Sea” (where the tagline was, inevitably, “It’s better when it’s wet” — we killed us…). One night a few of the brothers and I were sitting around shooting the breeze and bouncing ideas around. I think I was the one who came up with the idea of doing “Around the World in 80 Days,” though I can’t remember for sure. And when you think of that title what is the first image that pops into your head? The story involves several modes of transportation but many people’s minds will jump straight to the hot air balloon. A Google image search sure does. A big. round. hot air balloon.

That got everyone in the room excited right away. What could be more Adventure-y than that? OK, then what? Well, you ride in a balloon over the countryside and drop things and try to hit targets or get things to land in holes or whatever. Hmmmm. How to make the countryside go by? How about a green conveyor belt with some props on it, with the balloon and gondola suspended above it? I don’t know… might be hard to implement. Then I remembered something I’d seen in a random mail order catalog within the previous couple of days:


Four 4x4s could hold up a nice, square gondola and a pretty good-sized balloon. Two of the turntables could be mounted on L-brackets on one of the legs to support a half-sphere representing the northern hemisphere of the Earth. It would be about eight feet in diameter and close to four feet high. We could map out the continents and mountains with papier-mâché and dot the globe with famous landmarks onto which, someone else suggested, people could drop soft rope rings from the gondola.

And we were off…

Word spread around the house and people were starting to buzz. A little while later I heard that one of the Architecture majors had suggested changing the spherical balloon to an elongated dirigible that could stretch from corner-to-corner of the 12×15-foot plot we were allowed. That would give us the longest possible feature that would catch people’s attention as they walked along the midway. The pieces and proportions added up to exactly the 25 feet in height we were allowed so that was perfect, too. Someone, I think one of the other Architects who ended up being co-chairman with me, suggested surrounding the “world” with cotton to make it look like it was floating in clouds, and erecting some theater flats in back painted to look like more sky and clouds. Somewhere along the way we figured out that we could add fluorescent highlights to the landmarks that would glow when they went under the black light mounted under the gondola, which created a bit of a day-night effect as the world rotated.

As exciting as all that was there was still a major obstacle: the theme-and-placement lottery, which worked like a snake draft in football. All the organizations drew numbered lots and got to pick in order either their desired theme or their preferred spot on the midway (the far end down near most of the rides was prime real estate, for whatever reason). If we had drawn a high number somebody would have had the chance to grab our theme.

Fortunately my co-chair drew number four.

It was barely enough, out of about 25 organizations. The three groups ahead of us had different ideas and when we announced our theme there was an audible groan from the back of the room… from the group holding ticket number five. Another bullet had been dodged. We picked our location almost last and still got a coveted spot down near the end.

The next obstacle was the weather, which was lousy for much of that spring. I got the 4x4s and the gondola platform and top frame up easily enough, and then I got the frame of the half-sphere mounted and turning. The world’s shape was defined by bowed 1×3/8ish-inch slats that were wired to a top ring supported by the upper turntable and the outer edge of the lower disk supported by the lower turntable. That frame was covered in chicken wire and then a flat layer of papier-mâché. Onto this I laid out lines of latitude and longitude I used as a guide to freehand in the outlines of the important land masses and islands. The continents were all built up using thicker layers of papier-mâché and important mountain ranges were eyeballed in.

I must say I learned a lot about the northern coast of Russia that way. It’s funny how often you can look at maps and just not “see” certain things. Oh, remember that weather, and how lousy it was? Yeah? The thing about the papier-mâché continents and mountain ranges was that they were all built up while it was snowing outside, and while I was lying face-down on a ladder running from the ground to the gondola platform. I made sure to use warm water or my hands would have been in rough shape. The guy who built the dirigible was also stymied by the snow. His shape was built from hoops made out of the same-sized slats I’d used for the world, each of which was mounted on a vertical and horizontal support that was itself fixed to a central spar. The whole thing was covered in bedsheets a nursing student had gotten as donations from the hospital where she worked. The girls tried to dye the sheets but they wouldn’t take the color consistently, so a couple of the guys just painted the whole thing with an industrial airbrush. (Alas, one of the other guys ended up having to rub the overspray off the paint job on his car. Sorry, Tim…) I used that same airbrush to paint the landmasses to match a vegetation map I had in an atlas. I used a couple of clamped slats to hold the atlas open and flat so I could read it with one hand and paint with the other. One of the guys said he got a great picture of me doing that but I never saw it.

Most of the landmarks were made by one of the brothers who got completely into it. He spent weeks coming up with all sorts of buildings and items in creative shapes and with different features. He made the Great Pyramid of Giza out of a small section of 4×4 (it proved to be the hardest to land a ring on; it usually happened only by accident). Our fraternity house marked Pittsburgh, and it included a picture of the guy busting through the big plate-glass window in the dining room during a game of beer pong just a few weeks previous. The Titanic was sinking in the North Atlantic and a multi-looped sea serpent plied the North Pacific. Oil derricks in Alaska faced off against nuclear missiles in Siberia. The Eiffel Tower looked across the English Channel at Big Ben (which sits proudly in a curio cabinet to this day). I forget what else he came up with but a lot of the obvious highlights were hit. I think I can see the Leaning Tower of Pisa and the Taj Majal in the picture. The Sears Tower rose in Chicago and the Gateway Arch probably marked St. Louis. A volcano marked Hawaii.

I had gone out of my way to be accurate in painting the vegetation on the continents and had intended to do the same thing for the different depths of the oceans and major seas, but I never got to it. The night before the open I was grateful to see two of the guys painting away with aplomb. They were using brushes and weren’t getting the light blue and dark blue laid out the way it was in the almanac, but they were on it and I was both thrilled and grateful. A couple of Little Sisters and girlfriends weaved slats of brown wrapping paper to flesh out the gondola’s basket. One of the guys added 1×6 kickboards around the inside bottom of the gondola so no one would accidentally kick through the paper weave. Somebody made a nice sign which included mileposts to various locations around the world. Someone else made sandbags. Someone made the loading platform and the two stairways. The guy who had diligently made all the landmarks spent hours nailing cross-pieces in underneath the floorboards on the gondola platform to make the floor feel more solid.

A big part of building any booth was getting it from the House to the midway. In previous years the whole brotherhood picked up the structure as a single unit and carried it across Forbes Avenue and down the midway. This structure was made up of smaller pieces so that wasn’t going to be necessary. Most of the pieces were easy to move but the dirigible proved to be a major challenge. We flagged down a utility truck with an extendable boom and the driver was good enough to schlep the thing over to the midway, but the boom couldn’t extend far enough to get it high enough to secure it to the top of the main frame. Then the guys got creative!

We ran a couple of tall ladders from the hill just behind the booth, across the top of the backing flats, and right up to the top of the frame. The guys then muscled that dirigible up those ladders and somehow got it mounted while some of the other guys quickly got it fastened down with nails. It snagged on some of the bunting and we had to cut it free with an Exacto knife. In the rush I wasn’t as careful as I needed to be and I cut one of the guys’ hands. (Sorry, Jay…) It’s a wonder that was the worst of it. The bizarre thing was that after we got it mounted I had to run off to give a short presentation on the design of touch sensors for a robotic hand for Mech E Seminar II. I think I still have the overheads for that.

Was that the end of the adventure? Of course not! The midway opened on schedule on Thursday evening but the weather had prevented most of the groups from getting the finishing touches put on. The Carnival Committee therefore decided that we could keep working after the midway closed at midnight. Ugh. But, work we did. Four of us stayed up all night to get all the details right, including the application of strands of white Christmas lights around the balloon. The way we used pairs of ladders in A-frames to secure lights and ropes to the ends of the dirigible was ludicrously ill-advised. The highlight, finished just as the sun came up, was something we did to enhance the day-night lighting effect. I won’t tell you what we did and if I’m ever asked I’ll deny everything. I will, however, extend many thanks to Rich Wilkinson, Mike Shenck, and Tom Rieger. That night was magic and I’ll never forget it.

Our work completed we grabbed a quick shower, got some breakfast, watched the Friday heats of Buggy, and headed back to the midway to keep an eye on things. One of the girls expended quite a bit of energy barking the passersby to get them to try out our game. She was really sweet and it seemed to work. As a student of Architecture my co-chair was used to dealing with public critiques of his work so he handled the judges when they came by that afternoon and evening. In the afternoon on of the judges decided he was going to test out the floor of the gondola to see how solid it was. He stomped in place from side to side like a football player’s calisthenic exercise, and then declared himself satisfied. One of the brothers told me later that he made sure he was standing on the one loose spot on that platform so the judges wouldn’t feel it.

Seriously, the whole project was like that. A million things needed to go right and a million things did, and it happened because everyone got excited and jumped in and got things done when they needed to. It wasn’t all planned out; it just worked. It also didn’t hurt that of the five or six really beautiful booths that were our actual competition, one spent more than the maximum allowable two hours in downtime (we racked up all of three minutes!) and another had tried to write an overly ambitious computer game and failed. The House usually budgeted a sizable amount of money for the Booth competition. It wasn’t about making money, it was about winning the prize. The financial results turned out to be as special and surprising as everything else that year. We spent only a bit over $700–and made over $500. That’s over 2000 plays in only 24 hours and a net cost of barely $200.

Some people already knew the results when the awards ceremony rolled around on Saturday evening at the close of Carnival, but I wasn’t one of them. It was therefore a surprise and a relief when we found out we’d actually pulled it off. First place! We’d been killing ourselves for years in Booth and Greek Sing and had always come up short, but finally the house had won a major award and the seniors and everyone else had a great memory to take away with them. There was a mixer that night, but I was spent and crashed and burned by 11:00pm. The score sheets I saw later showed that we were near the top of every judge’s ranking but I especially enjoyed the perfect score we received from the stomping judge!

The next year’s theme was “Time Machine” and the idea that jumped to mind was a Polynesian pagoda-like structure against a background of a volcanic island and a game that involved a lagoon, small volcanoes, and ping pong balls. We discussed making different shapes and colors of cellophane flowers with little lights inside. It would have been beautiful and would ideally have evoked a feeling like the movie “Avatar.” I got myself nominated as booth chairman again but the magic didn’t happen. We drew a high number in the lottery and the Chinese and Japanese themes were snatched up whereupon the guy running the meeting was only too happy to suggest that there shouldn’t be any more pagodas. Well, there darn well should have been and I should have gone with the initial idea (technically it would have been more like an open air nipa hut), but instead I went with Land of the Lost (the classic old Sid and Marty Krofft show, not the execrable recent rehash of it), and we ended up building a big, ugly fiberglass cave with a dinosaur on top. It had a little lake that leaked, a waterfall, and some big Styrofoam lettering meant to evoke the feeling of Busch Gardens in Tampa. I delegated the game a team of good guys while the rest of us worked on the structure, but they couldn’t get it to work and I had my hands full. They put together a different game which wasn’t as clever or visually interesting. Some people volunteered to add little touches like hanging bats and whatnot but the excitement never really caught on the way it had the previous year. Fortunately one of the underclassmen got a little bit excited by the whole thing and he carried the torch forward with good results, but that begins a whole different story.

Over the years I’ve thought about what I might have done differently to get a better result the year after we won. I tried to get people involved in coming up with alternatives in case we didn’t get our first choice, but some of them got mad we didn’t run with their entire idea. It was seen as one person’s project rather than something that grew organically. Some people came and helped and added their efforts here and there but the overall level of excitement was less. I tried to point out and publicly talk up the folks that had contributed ideas and efforts we used but some people weren’t happy with that. Maybe if I’d had the presence of mind to adapt the right theme (one of the pagodas ended up winning and deserved to) it would have been more interesting to people. I know there was some excitement brewing that we didn’t get to leverage. I’ve beaten myself up enough for my own mistakes and have tried to learn from them but I also accept that sometimes things don’t gel. You have to do the best you can with what you’ve got, try to learn from it, and come back the next time and try again.

Out in the Real World the goal is to do things more purposefully. You don’t want to rely on luck or enthusiasm or Kismet; you want to make damn sure that all the bases are covered, that everyone is talking to everyone else, and that you capture every good idea you have from everyone who has them. I’ve seen that done well and get good to excellent results and I’ve seen it done poorly and get highly variable results, ranging from OK at best to very, very not OK at worst. You may not always get Kismet if you do everything right but in project and product work, like investing, you limit your losses. In engineering the whole point is to include a safety margin against losses, sometimes up to 6-to-1, as is the case in passenger elevators. Being conscious, proactive, and purposeful helps limit losses and helps generate more wins.

Posted in Management | Tagged , , | Leave a comment

Context of a Scrum Product Owner

Posted on December 15, 2015 by R.P. Churchill

The USS Constitution, launched in 1797, is possibly the oldest wooden ship still afloat. Over two hundred years of repairs, retrofits, and refurbishing has left only an estimated ten to fifteen percent of the original timber in place. I’ve read articles asking the interesting question of when the original ship becomes the pile of timber sitting on the ground and the remaining ship becomes something new. The same question might be asked of the human body, wherein most cells are replaced at various rates, but some brain and nervous system cells, and potentially some others in the heart, are never replaced. We would never suggest that a human isn’t that same person through his or her life, would we?

I was pondering this recently when considering the skills required of a Scrum Product Owner. The techniques and roles of Agile in general and Scrum in particular come with many very specific descriptions and definitions, but how important are those compared to the skills needed to carry out the same functions the way things were done or are done in the absence of Agile or Scrum techniques? That is, someone has to go talk to the customers, figure out what they need, work with the developers (and/or be a developer) to get the requirements implemented, get feedback and adapt to changing conditions, and provide a range of additional management support. When these activities are recast in a Scrum framework, how many of the skills carry over and how many are new? This is analogous to asking how much of the ship is the refurbished thing floating in the harbor and how much of the ship is the pile of timber sitting in the yard? Does the Scrum framework knowledge constitute ninety percent of the job, fifty percent, twenty percent, five percent, or possibly as little as one percent?

Let me ask the question this way. Would you rather work with an individual who knows all the Scrum buzzwords and can answer all the trivia questions but doesn’t have much experience working with customers, analyzing systems, and delivering code and support or would you rather work with someone who has quite a lot of experience working with customers, analyzing systems, and delivering code and support and needs to review the Scrum Product Owner’s handbook from time to time to ensure he or she is following every procedure and considering every option that body of knowledge provides? Moreover, do you believe that any conscientious practitioner would review the framework materials at intervals anyway, instead of relying solely on memory, and do you believe that most practitioners and teams follow every rule by the book to begin with?

Agile and Scrum are terrific tools that I endorse as much as anyone, but by themselves they are only so much of putting a working system together to meet a customer’s needs.  The bulk of the work is still about being able to break the problem down and build up a good solution.  That part never really changes.

Just something to think about.

Posted in Tools and methods | Tagged , , , | Leave a comment

Scrum Product Owner – Basic Outline

Posted on December 14, 2015 by R.P. Churchill

I found it helpful to review my notes on the role of a Scrum Product Owner and place an outline here to which I can refer quickly.

  • Three Pillars of Scrum
    • Transparency
    • Inspection
    • Adaptation
  • Iron Triangle (from Project Management)
    • Scope
    • Cost
    • Schedule (Time)
  • Scrum Ceremonies
    • Sprint Planning
      • all team members including Product Owner
      • Dev Team commits to complete a negotiated amount of work from the highest-priority PBIs (Product Backlog Items)
    • Daily Scrum
      • Dev Team, ScrumMaster
        • What did I do yesterday?
        • What am I going to do today?
        • What impediments do I face?
      • presence of Product Owner can be very helpful to answer questions
    • Sprint Review
      • mainly review what was accomplished
      • outside managers are encouraged to attend
    • Sprint Retrospective
      • mainly review the team’s internal process
      • mostly just for Dev Team and ScrumMaster
    • Product Backlog Refinement
      • Product Owner with Stakeholders, SMEs, Customers, Managers
      • Also work with ScrumMaster, less with Dev Team
  • Scrum Artifacts
    • Product Backlog
    • Sprint Backlog
    • Product Increment
  • Product Owner Activities
    • Inward-Facing: Work with the Scrum Team
      • Release Planning
      • Sprint Planning
      • Daily Scrum
      • Answer Questions
      • Validate PBI (Product Backlog Item)
      • Sprint Review
    • Outward-Facing: Work outside the Scrum Team
      • Work with SMEs, Stakeholders, and Customers
      • Understands Needs
      • Validate Product
    • Groom/Refine Backlog
      • Create PBIs (Product Backlog Items)
      • Split PBIs
      • Reorder the Product Backlog
  • Product Owner Responsibilities
    • Gathers input from stakeholders
    • Establishes a high-level vision and goals
    • Obtains a budget
    • Identifies ways to improve business value
    • Optimizes ROI
    • Establishes clear release criteria
    • Prioritizes the product backlog
    • evolves the product backlog
    • clarifies user stories
    • maintains a release burndown chart
  • Balance for Scrum Roles
    • Product Owner: Build the Right Thing
    • Development Team: Build the Thing Right
    • ScrumMaster: Build the Thing Effectively
  • Levels of Planning (small -> large)
    • Daily Planning
    • Sprint Planning
    • Release Planning
    • Roadmap Planning
    • Vision Planning
  • Scrum Overview
    • Idea->Product Vision
    • Roadmap
      • Initiation – Sprint 0
      • Releases 1-n
        • Sprint 1
          • Sprint Plan
          • Sprint (days)
            • Day 1
            • Day …
            • Day n
          • Sprint Review
          • Sprint Retrospective
          • Produces a Product Increment
            • Meets Definition of Done
            • Increment usable by customer
            • Release (final)
        • Sprint n
          • Sprint Plan
          • Sprint (days)
            • Day 1
            • Day …
            • Day n
          • Sprint Review
          • Sprint Retrospective
          • Produces a Product Increment
            • Meets Definition of Done
            • Increment usable by customer
            • Release (final)
        • Release Review
        • Release Retrospective
      • Final Release
  • Roadmapping
    • Start from core functionality
      • Minimal Marketable Features (MMF)
      • Minimal Viable Product (MVP)
    • Add working features and sets of features with each release
  • Release Planning
    • Cadence-based (schedule-driven)
      • Advantages
        • Deliver functionality and business value earlier and more often
        • Predictable schedule
        • Predictable burn rate
        • Sustainable pace
      • Disadvantages
        • Must slice scope to fit schedule
        • Must use resources differently
      • Teams are more interdependent
    • Scope-based (feature-driven)
      • Advantages
        • Discrete Statements of Work (SOWs)
        • Commodity oriented
      • Disadvantages
        • irregular delivery
        • delay in business value
        • resources may be used unevenly
      • Teams are more independent
  • User Stories
    • Components
      • As a [role (who)]…
      • I want [feature (what)]…
      • So that [business value (why)]…
    • Acceptance Criteria
      • help define done
      • manage expectations
      • lead to new requirements
      • attributes:
        • objective
        • measurable
        • testable
    • Importance of components
      1. Why
      2. Who (personas)
      3. What
      4. Acceptance criteria
      5. How
    • User Roles
      • How often do they use the system?
      • How technically savvy are they?
      • How much domain knowledge do they have?
      • What are their goals?
      • What are their pain points?
  • Grooming
    • Progressive Elaboration
      • Higher-priority, sooner-to-be-completed items are smaller and better defined.
      • Lower-priority, farther-in-the-future items are larger and less defined
    • Attributes of a good user story
      • Independent
      • Negotiable
      • Valuable
      • Estimatable
      • Small (no more than 1/2 sprint and only one of those)
      • Testable
    • Dependencies for:
      • Business: Product Owner resolves
      • Technical: Dev Team Resolves
    • Splitting User Stories
      • When to split stories
        • Split stories that are dependent on each other
        • Split stories that are too big
        • Split stories into spikes if complex or risky
        • Split compound Stories
      • How to split stories
        • Stories should represent some level of end-to-end functionality
        • Do not split into tasks like design/code/front/middle/back
        • Deliver cohesive subset of all layers
        • Do simplest thing that could work
        • Horizontal vs. Vertical
          • Horizontal: layers or hardware or software functionality (e.g., database, I/O, UI, security, user control, business rules, middleware, etc.)
          • Vertical: units of business functionality that cut across or incorporate functionality from horizontal system layers (e.g., user login and management, transaction processing, reporting, etc.)
      • Patterns for splitting stories
        • Data boundaries
          • local vs. international
          • by credit card type
          • by currency type
        • Operational boundaries
          • CRUD
          • happy path vs. exceptional cases
          • business rules
        • Cross-cutting concerns
          • security
          • logging
          • error handling
        • Performance
        • Priority
          • necessity
          • flexibility
          • safety
          • comfort, luxury, performance
      • Development Approach: Iterate through…
        • core operations
        • capability, flexibility, safety
        • usability, performance, sizzle
      • Definition of Ready (for Dev Team to work on)
        • Defines when PBIs are ready for Dev Team to consume
        • Use INVEST as a guide
  • Estimation
    • Context
      • Who provides the estimates?
      • Who commits to the estimates?
      • What units are used?
    • Story Points
      • based on relative effort
      • based on volume of work, complexity, and risk
      • Fibonacci sequence?
    • Planning Poker
      • all team members independently estimate
      • estimates are compared and outliers are discussed
      • consensus and understanding are reached
    • Benefits
      • fast techniques
      • increases accuracy
      • builds understanding
      • drives commitment
      • provides data points
  • Sprint Planning
    • Select highest business value stories
    • Generate Sprint Backlog
    • Determine what will be delivered
    • Determine how it will be achieved
    • Should take less than two hours per week of sprint
    • Break PBIs into tasks and estimate
    • End with Team’s forecast of what can be accomplished
    • Task Board Columns (tasks per story by row, migrate tasks across)
      • Task
      • In-Progress
      • To Verify
      • Done
  • Sprint Review
    • Dev Team presents Product Increment
    • Product Owner, Stakeholders, SMEs review the increment and provide feedback
    • Feedback is processed by Product Owner and used to adjust backlog and release plans
Posted in Software | Tagged , , | Leave a comment

A Recommended Course on Udemy.com

Posted on December 10, 2015 by R.P. Churchill

Upon completion of Rob Percival’s course, The Complete Web Developer Course – Build 14 Websites on Udemy.com, I’d like to give the course a positive recommendation. The course guides you through setting up all the behind-the-scenes parts of a website and how to create web functionality using the most common technologies. I’ve done a minimum of web work over the years but since it was never a part of my 8-to-5 I didn’t get into too much detail. It was nice to have been led through it in an approachable and organized fashion.

The course is divided into 11 sections as follows:

  1. Getting Started and HTML
  2. CSS
  3. Javascript
  4. jQuery
  5. Twitter Bootstrap
  6. WordPress
  7. PHP
  8. MySQL
  9. APIs
  10. Mobile Apps
  11. What Now?

The early sections have more lectures where you need the most guidance and include fewer as you go. The sections on Javascript, jQuery, and PHP lead you through the basic language constructs. It’s hard for me to say just how good of an introduction they are to programming in general, or how effective they would be for a novice, but they cover the basics. Most programming languages only do a handful of things anyway; most of the knowledge is in the special commands and the APIs. There are plenty of additional courses and references that go into more detail but what’s covered in this introduction is more than appropriate. Each lecture runs anywhere from a couple of minutes to a bit over an hour. Each section also includes one or two major projects which summarize and build upon everything covered to that point. Those tend to be the longest items.

The instructor has a pleasant and clear delivery (the just-so British accent probably doesn’t hurt) and has actually provided several popular courses. This particular course may be the most popular and highly rated on the site. If it isn’t it’s close.

I will probably offer a five-star review for the course but I would not say it’s perfect. It’s easy to leave a few loose ends, particularly with someone as experienced as this instructor, and I spent quite a bit of time trying to tie them up. Web searching (which often leads to StackOverflow) helps some, but Udemy’s own discussion forums, which are attached to each lecture within a course, can be very helpful, particularly in a course with so many students. I’m guessing there aren’t too many new errors students can make so many questions you may have are likely to be addressed right there. You’re likely to avoid the most obvious errors just by paying close attention and being diligent.

Many lectures are followed by a page which offers a download of the code written during the previous demonstration. They usually match what’s in the lectures, but not always. You should definitely save your own work and your own comments and notes.

Another issue that can cause problems is that a course like this inevitably references many resources from elsewhere on the web, and those resources can change. I encountered specific problems working through one of the projects using the Google Maps API and the problems I encountered in the Mobile Apps section were close to catastrophic. The basic ideas were still good but there were major changes in required tools, security issues, and configurations that it took more hours than I care to discuss to plow through. I’m thick-headed enough that I did most of it, and the instructor has specifically noted that he plans an update (he has courses on developing for both iOS and Android which I hope are more up-to-date), though I can’t say when. The student comments on the issue go back at least seven months at this point. This process has also left some unwanted plaque in my system that I’m going to have to clean out.

In the Mobile Apps section, and in any complex lecture, it’s probably a good idea to check the student comments first. Knowing about major issues ahead of time could save you a lot of wasted effort. I’m tempted to suggest that the section on Mobile Apps shouldn’t even be there. It only covers adapting one basic HTML5 app to both the Android and iOS and given the problems I encountered (the source app has problems of its own that I had to debug) it seems to be promising more than it can really deliver. The course was pretty solid until the end left a sour taste. Other students shared the same opinion. To the good I got a better ‘education’ than I’d planned…

This entropy is likely to get worse over time. We’ll see how well this instructor and others choose to respond. My guess, given the level of engagement and interaction I see, is that this course is likely to be kept up-to-date, though updates may take time. The courses can also be expanded occasionally and I’m aware that several have announced additions.

Edit, Feb 4, 2017: The provider for this course has released an updated 2.0 version and remains an engaged and popular instructor.

I had previously worked though a few of these subjects on Code Academy but I found the Udemy format superior because the lectures only lead you through the steps, you have to do them on your own in your own environment. The benefit of that approach is that you have all your work when you’re done and some working websites as well. You also get to do all the searching and configuring and everything else. In Code Academy you work in their fishbowl, which hides some important context. That said, Code Academy has the virtue of being free while the Udemy courses are (mostly) paid.

If you are clever—and patient—you can often find Udemy courses at a pretty steep discount. These opportunities come by more often if you have already subscribed to one or more of the courses. The site also provides lifetime access to all courses you sign up for so it might be a good idea to load up on more when they go on sale, on the theory that you’ll get to them eventually. I paid only $24 for my first two courses and only $10 for six subsequent ones. Now I just have to figure out which one to take next…

Posted in Software | Tagged , | Leave a comment

Engineering as a Starting Point for Other Careers

Posted on December 9, 2015 by R.P. Churchill

Over the years I’ve met and worked with a number of people who started off as engineers and went on to do other things. One friend started as an electrical engineer and went on to become a corporate lawyer, though in truth that was his original aim in the first place. Other friends started off the same way I did, as mechanical engineers, only to become a lawyer, a doctor (specifically an OB-GYN, he wanted to deliver babies), and a professional dance instructor. The judge who performed my father’s second marriage started off as a mechanical engineer as well. Engineering is a good mix of the practical and the theoretical and mechanical engineering seems, to me at least, to be the most general of the engineering disciplines. A well-rounded mechanical engineering education touches on every other engineering field from chemical to civil to electrical to controls to computers to aerospace to power to materials science to just about anything else. Indeed, Professional Engineer (P.E.) certifications are given in the following engineering specialties, and mechanical engineering seems to touch on all of them:

  • Agricultural and Biological Engineering
  • Architectural
  • Chemical
  • Civil: Construction (with new design standards for 2016 exams)
  • Civil: Geotechnical (with design standards)
  • Civil: Structural (with design standards)
  • Civil: Transportation (with design standards)
  • Civil: Water Resources and Environmental
  • Control Systems
  • Electrical and Computer: Computer Engineering
  • Electrical and Computer: Electrical and Electronics
  • Electrical and Computer: Power
  • Environmental
  • Fire Protection
  • Industrial
  • Mechanical: HVAC and Refrigeration
  • Mechanical: Mechanical Systems and Materials
  • Mechanical: Thermal and Fluids Systems
  • Metallurgical and Materials
  • Mining and Mineral Processing (new specifications for the 2016 exam)
  • Naval Architecture and Marine (new specifications for the 2016 exam)
  • Nuclear
  • Petroleum
  • Software
  • Structural (with design standards)

I’ve touched on as many as eleven of those fields during my own career, but what really unifies the thinking in all of them is a grounding in reality and a systems approach. Engineering is in many ways a form of economics; the engineer explores trade-offs among different constraints. The classic triple constraint in project management is based on cost, scope, and time. Another classic triplet is time, cost and quality. People often say, “You can have it fast, cheap, or good: pick two!” I might add that if you want it really fast, really cheap, or really good: pick one. This has also been expressed by the pithy observation that “Engineering is the art of doing with one dollar what any damn fool can do with two.” (I’ve seen a number of different versions of that and have failed to nail down its provenance.)

I’ve spent much of the last thirteen years doing operations research, which is about optimizing across many different resources or factors, or at least understanding the trade-offs between them. I’ve always been fascinated by this and seek improvements in every phase of every process.

Charles Stross, in his otherwise excellent novel Accelerando, posits what he calls “Economics 2.0”, which works in a fundamentally different manner than does “Economics 1.0.” In this he is incorrect. Economics is about choices made under conditions of scarcity. Period. If changing technology makes different things scarce, which he writes about ably enough in the book, that only means different things are scarce. It does not mean that economics works in a fundamentally different way. I mention this because economists and engineers are often likely to have similar types of personalities. An engineering mindset is in many ways an economic one.

In the end every job is about economics, is it not? You are trying to meet someone’s need in the most efficient way.

Posted in Tools and methods | Tagged , , | Leave a comment

Working for Big Companies vs. Small Ones

Posted on December 8, 2015 by R.P. Churchill

I’ve worked mostly in smaller companies during my career, which has been a mixed blessing. I worked for two larger companies at the beginning of my technical career (and I guess you’d have to classify the Army as a large company!) but all the rest have been medium to small. Here are some pros and cons I’ve identified.

In large companies you’re likely to get more formal training; smaller companies often don’t have the budgets for training. That said, if companies do have funds available you’d be foolish not to avail yourself of them. Taking a course or two every year has the potential to keep you fresh, challenged, and up-to-date. I’ve taken a boatload of training sessions over the years, of varying duration, subject matter, and complexity. Informal training sessions, particularly during lunches, can be readily conducted in any environment. I kicked off a trend to brown bag sessions at a smaller company that went on successfully for a while.

In large companies there are likely to be multiple people doing the same job as you. At the least you will be in a department with multiple colleagues doing closely related work. In small companies you may be the only one that knows what you do. That’s great in some cases because you get a lot of autonomy if you’re getting the job done. That said, you may also miss the chance to review the details and learn from other people who discover better ways of doing things. The communities of practice weren’t as strong or as organized as they could have been at Westinghouse, but there was a grapevine through which some discoveries were passed, and you could always wander around asking for opinions. The ability to do this at smaller companies may be limited. The web can provide some outside support in this area, but I’m not sure a week or sometimes even a day doesn’t go by where I don’t think of ways some of my previous work could have been better.

If you run into personality conflicts or political problems in large companies it may be easier to avoid or work around them. In smaller companies you may be stuck working with someone who causes you no end of problems, and there might not be any escape. Fortunately I’ve been able to dodge or outlast most such problems over the years.

Unless you work with very special people in a small company, who keep up with the latest trends, you might not get exposed to industry practices until much later than you might have. I wasn’t really introduced to Agile and Scrum until entirely too recently. I’ve done a lot of extra study and certification to catch up, and certainly have a wide range of experience to support it, but I can’t say I’ve done enough of it as a formal practice.

As a corollary to the previous point, larger companies are more likely to have formal and effective management structures in place at a variety of scales. Everything we did at Westinghouse was formalized from a workflow and project management point of view. It wasn’t perfect and things were missed (and effort wasted in some colorful ways), but everyone saw how it worked and learned from it. In smaller companies things might be done by the seat of the pants or not at all. At this point I’ll never allow not at all to happen again.

At larger companies there are likely to be sports leagues, clubs, volunteer opportunities, and social events to get people together in interesting ways. I loved the camaraderie of parties, outings, bowling and golf and softball leagues, seats in the company box at Pirates games, and all the rest of it. I still have some good friends from those years, of all different ages. I got together with some nice people a few times at smaller companies but it just wasn’t the same.

If you figure out a significantly better way to do something you may or may not get to implement it at a big company. If you do, congratulations! You may get support, recognition, and the leverage to make some really cool things happen. If you don’t, then bummer. Better luck next time. An automation tool I created at Westinghouse might have proved extremely useful to the entire division, but I was a contractor and the division was being wound down having completed most of its work. I got a couple of managers to compliment my work and recognize that it would have been great to pursue, but the timing wasn’t right. In a smaller company you might just be able to go ahead and do it. Better to ask forgiveness than permission, right? (This is great if your innovation works.) You can also go to the most senior managers for support. On the other hand, you might run into a senior individual who just doesn’t want to hear it.

An individual’s fate at both large and small companies can be affected by outside events. Sometimes entire divisions are sold off or closed and many people lose out no matter how good they are. In other cases entire divisions are acquired that obviate what you were going to be brought in to do. That, however, is life. That happens at companies of every size.

The more important point is that individuals, particularly managers, always have the opportunity to make things better. If you have a great idea bounce it off some people. See what they think. Build up some support and momentum. Make it go! That can happen at companies of every size, too.

Posted in Management | Tagged , , , | Leave a comment

High Overhead vs. Lean and Mean

Posted on December 7, 2015 by R.P. Churchill

A company I worked for some years ago tended to work on projects of a certain size. They weren’t what anyone would call large projects but they weren’t small ones, either. They carried a certain overhead: discovery, requirements, development, application, testing, verification. Once we had the model-building tool working we had to build the models within it, each of which involved a development cycle of its own.

After giving a talk at a symposium I was approached by a potential customer who wanted an analysis of a subsection of what we normally modeled, in several iterations with minor mods. There was no way this guy was going to pay $100-200k for such a thing, but when I told our team and managers about the opportunity they said they didn’t have a way to make it work for $10-20k, either. We did other analyses at that incremental cost for things we did repeatedly but nothing that required much in the way of custom development.

That always disappointed me. I get that things cost what they cost and I can also appreciate not wanting to lower the perceived value of your work, but I think it’s important to at least consider ways to capture additional value when opportunities to do so present themselves. It might be a good idea to examine whether smaller units of functionality might be of use on their own. Some might be obvious and some might not but consciously taking some time to think about it can’t hurt.

Posted in Software | Tagged , | Leave a comment