Author: admin

Posted on

The Rudiments of Retrospective

I want you and your team to have good retrospectives. Retros are the most important mechanism for continuous improvement. There are so many articles out there with good advice. But I’d like my own anyway and discuss a few concepts.

Method variance (part of facilitation)

As I write this in late March 2020, most of us are WFH – working from home, due to the COVID-19 “Coronavirus”. Eliminating the ability to collaborate face-to-face makes varying the conduct method of your retrospective even more important. This is because the variance subtly motivates different perspectives, and that is an important way we discover new things to try (experiment) to improve. For example, suppose you want to hear from every team member. You can call on everyone in turn as the Scrum Master. You can ask each to choose their successor, you can intentionally randomize. You can ask “who would like to go next?” Each has advantages. Choose a different method for doing business as often as you can. Here is one ‘net resource discussing this idea; here’s another.

Framework variance

Most retrospectives have a framework for engaging in discussion resulting in specific elements of continuous improvement. Vary this too; no matter how inventive it is it gets old with overuse. Start/ Stop/ Continue is great, but there are so many others, some with interesting names like Sailboat, and again each results in different perspectives. Here is a list of 10 different frameworks including Lean Coffee.

Agenda

The agenda for a retrospective is more than just executing the framework. It’s also a look back and of course a look forward. Here is a sample agenda with a beginning, the “meat”, and outcomes:

  • Introduction (try the Retrospective Prime Directive)
  • Celebrations
  • What were the three (no more than 3) behaviors we decided to change last time? How did that go?
  • What were the three (again, no more than 3) retrospective backlog items, actions, we decided to work on last time? How did they go?
  • Framework choice (see above)
  • Framework-based, facilitated retrospective free discussion
  • What are the < 3 behaviors we will change for next time?
  • What are the < backlog items of continuous improvement we will work on and complete for next time?
  • Other remarks / Conclusion

Inputs

  • An invitation to meet, with agenda
  • Recent behavior changes – let’s call them decisions – we’ve been experimenting with (an example: we decided to do three backlog refinement sessions last sprint instead of two, how did this go?)
  • Recent backlog items – actions – associated with retrospectives (an example: we added a Jira issue to build a Slack bot to do (whatever) is this done and how is it working out?)
  • Framework choice (or, this might be revealed during the retro session itself)

Guidelines

  • Ensure that your retrospectives occur sufficiently often. Less than monthly is almost certainly unacceptable.
  • Ensure that the feeling of the session is not that of a report or reports. It is a collaborative discovery session.
  • Allow for anonymous input. If you were all in a room together, the next sticky note you place on the wall in conjunction with your framework-based discussion is at least somewhat anonymous. When we discuss it, the person who wrote it may or may not speak up, and if they do they may or may not own up to having written it. Try to encourage this kind of anonymity, as it frees up discussion and makes more innovation possible.
  • Take inputs and group them to improve effectiveness. It’s ok for multiple people to say the same thing. Group them after collecting them, to facilitate discussion. The face-to-face method is to grab stickies and group them together. Do what you can if you’re remote to make this happen.
  • Take your team’s inputs and prioritize them, at least most of the time – perhaps in the interest of varying method you don’t always do so, but most of the time you should. The Lean Coffee method works fine, most votes is highest priority. Discuss the topics in priority order.
  • Have fun! Celebrate!

Outputs

  • Those behavioral things we’re going to change and experiment with, that is our decisions, and
  • those actions we’re going to work on, and which therefore will appear in our backlog, both of these first two bullets in the name of continuous improvement
  • the date/time of the next retrospective
  • Don’t forget to celebrate! You need to work that in somewhere.
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

Project Management Lessons from Star Wars

“I learned everything I know about Project Management from Star Wars.” No, definitely not my idea, I just enjoy it. And actually the first person I heard utter these words is my old friend Bob Wise. Truer words, though, have never been spoken. Some brief evidence for your reading pleasure …

  1. First lesson: if possible, it is best to operate from a position of strength: (Ep. V)
    Darth Vader: “I am altering the deal. Pray I don’t alter it any further.” 

  2. The Good Cop, Bad Cop paradigm can be a useful negotiating tactic: (Ep. VI)
    Moff Jerjerrod: “The Emperor’s coming here?”
    Darth Vader: “That is correct, Commander. And, he is most displeased with your apparent lack of progress.”
    Moff Jerjerrod: “We shall double our efforts.”
    Darth Vader: “I hope so, Commander, for your sake. The Emperor is not as forgiving as I am.” 

  3. Schedule … of course … as always … is paramount: (Ep. VI)
    Moff Jerjerrod: “Lord Vader, this is an unexpected pleasure. We are honored by your presence…”
    Darth Vader: “You may dispense with the pleasantries, Commander. I’m here to put you back on schedule.”

  4. Always work to enable, facilitate and motivate your team: (Ep. VI)
    Moff Jerjerrod: “I assure you, Lord Vader. My men are working as fast as they can.”
    Darth Vader: “Perhaps I can find new ways to motivate them.” 

  5. Somewhat less tongue-in-cheek, we have the following genuinely useful thought from Annakin’s mother to her son: (Ep. I)
    Shmi Skywalker: But you can’t stop the change, any more than you can stop the suns from setting.”

I recently discovered that others have taken it to a much higher level (no surprise!): 

  • Brandon Koeller: Top 10 reasons Darth Vader was an amazing project manager[1]
  • Tim W: Five ways Project Managers could have saved the Empire[2]

  – – – – –

Enjoy …

[1] https://www.geekwire.com/2011/top-10-reasons-darth-vader-amazing-project-manager/ .

[2] https://www.linkedin.com/pulse/star-wars-five-ways-project-manager-could-have-saved-empire-woolery/

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

to Kanban from Scrum

I recently transitioned a team from Scrum to Kanban. Here are some of the things I learned. Those of you experienced in Kanban – I’m really not – will probably find this boring. Many of these items are bread-and-butter for Kanban.

  • Kanban has less formality but requires the same degree of rigor as Scrum or even more. This implies a greater requirement in Kanban for discipline, enough so that teams can do it, but are unlikely to do it well, without focused help from a good coach, unless the Kanban Master is quite well-trained. That is, Kanban Master(s) needs to be higher quality with respect to Agile and Kanban techniques than are most Scrum Masters with Scrum techniques, for the team to be successful.
  • Kanban is Lean. Start with what you have, keep learning, and feel very free to change and expand your board. More columns, maybe more rows, and make it truly live and visually representative of your current work, state and needs. Be incremental. Experiment, try stuff, continuously improve. Focus on pull in lieu of push. (A good and easy example of pull is inserting a new column in a Kanban board between In Progress and Testing called Ready to Test.) Oh, and read Kanban by David J. Anderson. Don’t argue, just go read it. I found it a challenge to find the board online that I wanted to cite as a good example. Here’s one that is not bad, take awhile to just study it and think about what they must be doing and how it visualizes things for the team.
  • Policies. Each column-to-column move made by a work item is a state transition; endow each state transition with a policy. In Scrum, from In Progress or Doing or Testing or whatever to the Donecolumn (state) has a policy associated with it called Definition of Done. Optionally, from Backlog to In Progress has a policy associated with it called Definition of Ready. Each policy specifies the conditions that must be true to allow the state transition, as well as the actions to be taken when the transition is performed. In Kanban, all possible state transitions should be endowed with such a policy. They don’t need to be lengthy, but they definitely should be visible and easily found so that they are quickly referred to during work and updated during retrospectives with new knowledge gained.
  • WIP. Going from Scrum to Kanban made the transition from (work in progress naturally limited by 2 week sprints) to (WIP limited poorly and without a strategy) painfully easy to see. Shoring up the WIP limits to enable good flow and predictability became priority almost immediately. Fortunately it’s not difficult as long as the principles are understood. The rule of half got us in the ballpark: Team: “is this about right?” Coach: “try half that”.
  • Reviews. In Scrum there is a sprint review every two weeks. Everything forecasted for a sprint is reviewed or thrown back into the backlog if not done. In Kanban there is no such formalism, but every work item should still result in a product improvement that is executable, demonstrable, and demonstrated to a product owner or stakeholder(s) and approved. Visibility is key, so put the appropriate state transition into your Kanban so that you can know that all your work items pass this “it’s done, and it’s approved” policy test. In addition, don’t underestimate the value of cadence; maybe you should keep reviews of your working stuff on a regular cadence. Kanban doesn’t care; if it adds value, do it. Does that make it Scrumban instead of Kanban? Not sure, and not sure it matters, but rhythm is often useful to a team.
  • Retros. In Scrum there is a retrospective every two weeks. One must account for this functionally. In Kanban, once again, the retro does not have to occur on cadence, but experience shows it has to occur with similar frequency in order for your team to qualify as a team seriously engaged in continuous improvement. My suggestion: stick with what you did in Scrum, if you can. Set up a convenient time, and do your retrospective every two weeks on cadence. If this is the only thing you do on cadence, I believe it’s the best thing to do on cadence. Retros are the most important event, right? Rhythm is useful to many teams (see previous bullet), and it is a reason Scrum is so easy to like.
  • Kanban doesn’t have a Product Owner. I recommend a Product Owner anyway. Bring someone in from the Business who will do the things a Product Owner does. Make that person a full-time member of your team.
  • Kanban doesn’t have a Scrum Master. I don’t recommend one, but I almost do. You need a level of effort of approximately a one full-time person to engage the team in continuous process improvement, remove impediments, and facilitate ceremonies/events of importance. In fact, maybe the LOE is higher, because Scrum’s processes are straightforward whereas Kanban is nominally very flexible and dynamic. My suggestion then (falling just short of a recommendation), is to avoid underestimating the value of a single, dedicated person who acts for your Kanban process as your Scrum Master would if you were using Scrum. Call him/her your Kanban Master perhaps, if you as a team decide to leverage this idea. Be sure that person reads Kanban.
  • Story pointing or story sizing. Predictability is a major element of growing maturity as a team. In Scrum, we often perform Story Pointing as a part of backlog refinement, to understand the relative size of each work item (many of which are user stories, hence the name). However, in Kanban, one doesn’t measure velocity because there are no sprints. Instead one measures lead time and cycle time. For this to work well, each work item needs to be “about the same size” as its brethren. Story sizing keeps this from being a need, but story sizing only works if you’re on a static cadence like two weeks. If you have some 1s, 2s and 3s floating around, you’ll probably be ok with the assumption that all stories are close enough to the same size to ignore their differences. If you have some 2s, some 3s, but a 13 or three as well, then the assumptions of similar size required by the lead time and cycle time measurements don’t work as well, and those measures won’t help you nearly as much to understand your predictability. Therefore, a significant element of improving maturity with Kanban is to solve this problem by splitting those 13 point user story into stories that are 1, 2 or 3 or so in size, that is, all of similar size. And we don’t do this by explicitly sizing the stories, we just split them until the collection of stories all are “about the right size”.
  • Story Understanding. On the other hand, part of backlog refinement is ensuring that the whole team understands the needs represented in the backlog. My experience is that this happens very naturally when stories are routinely sized. If the team stops sizing stories, they often forego exactly what it takes for them to have an adequate understanding of the stories. Quality suffers. Thus, even if the team is not sizing stories any longer, they still need to understand them as well as when the stories were being sized. The team must figure out how to maintain that sufficient level of understanding of the backlog.

Hope that helps! Keep learning and improving.

Posted on

Scrum Cookbook

Scrum is easy! No really, it is. Doing Scrum well is quite difficult, but doing anything well usually takes thought and practice. We can start right in though. First, read the Scrum Guide at scrumguides.org . Second … follow my cookbook! Now laugh, because of course it is not quite that easy (and you can tell that because this is not a short post!), but once you have received training this cookbook may be a resource you and your Agile Coach can use to jumpstart your transformation to execution using an Agile paradigm.

Scrum can be used to quickly lead a team to the Agile Minimum Viable Product (to paraphrase Mike Cottmeyer): that MVP is (1) a genuine, collaborative team, (2) a single-source product backlog, and (3) frequently executing stuff. If you have these three items and you have a continuous improvement mindset, you’re genuinely getting close to Agile.

Ok, so have you read the Scrum Guide? No? Go do that, I’ll wait. Now let’s get started. Please let me know if you have any comments or questions.

Preface: Recently Scrum and Agile have been moving away from the use of the word ceremony, choosing instead to call them events. It is important that we stay away from the word meeting, because that means a gathering that is not in scope for core work, whereas a ceremony or event is intended to be exactly that. In this paper I’m going to stay with ceremony because it seems to stand out a bit more, but the Scrum Guide calls them Events.

Communications Guidelines

The following are suggestions for enhancing communications and collaboration, especially intra-team, particularly when there is involvement in multiple geographies. A multiple geographies situation is highly discouraged, but we are finding that they’re unavoidable. What I mean by this is most clients of Agile Coaches don’t respond well to the suggestion of colocation unless they already have it; they’ve invested (sunk) too much into distribution and emotionally they can’t just let go. (The admonition to ignore sunk costs usually does not help as much as you would like.) If the Coach insists, they usually throw out the Coach and s/he has no opportunity to help. I conclude that moving to colocation must wait for a substantially higher trust profile, must be very gradual, and must be initiated while armed with a client-specific, well-researched business case. Meanwhile, if we add just a bit of discipline in a few communications areas it can greatly assist us in communications precision and bandwidth, which in turn facilitates real collaboration.

  • Any time you are planning to communicate with someone where there is a higher risk of misunderstanding, and in advance if possible, draw a picture of the information you plan to communicate and socialize it.
  • Any time you are talking about a Jira (or Rally, or whatever your favorite work manager is, here I’ll use Jira) issue or ticket, try to begin the conversation by clarifying which one you’re talking about, by number. For example, TEAM-12.
  • No email – none. Email is transient, suitable for sending someone a gentle reminder, but otherwise, all information should be in a Jira ticket, or Sharepoint location, or Jive or Confluence location (below I’ll use Confluence), or Slack/Symphony channel (below I’ll use Slack) – whatever your collaboration environment gives you access to. You don’t have tools like these? Get them. Or colocate. Your client must make at least some investment in seamless communication and collaboration.
  • ANY information about a ticket in Jira should be either in that ticket, or referenced explicitly in that ticket. A ticket/work item is about work, so ensure that the results from the work – generally artifacts and deliverables – are obvious, or referenced in the ticket.

Socialization, Team Norms and Continuous Improvement

  • Responsible Party: Scrum Master
  • Facilitator: Scrum Master
  • Required Attendees: Entire team, including Product Owner
  • Frequency: on team startup, and whenever changes to the Team Norms are needed
  • Duration: As long as it takes. The whole team dynamic is based on trust and common understanding of how we will behave toward each other.

The following is suggested. 

  1. Certain basics must be followed by the team and therefore agreed on by the whole team. This isn’t a Scrum ceremony but treat it as such, because this is fundamental to continuous improvement.
  2. On the team’s Jive page, or Sharepoint page, or the team’s persistent and highly visible repository of choice, plan to reference, and then develop and maintain, live documents briefly declaring the following items. The scrum master should invoke these items frequently to ensure consistency and high performance. They can be changed in any retrospective by the team to experiment and look for performance improvements. The team trusts each other to follow these team norms.
  3. Team name, purpose and mission
  4. Team’s Agile metrics and Business KPIs, the business level measures the team is growing for the business or organization.
  5. The product(s) for which the team is responsible, and a vision statement, roadmap outline and product architecture for each product. Geoffrey Moore’s elevator pitch is a reasonable place to start in preparing a product vision statement. A roadmap should be high level, lots of detail is probably wasted effort due to reprioritization over time. Architecture is any guidelines, patterns and constraints to be used in governing development and delivery of the product.
  6. Team’s Definition of Ready (DOR) and Definition of Done (DOD) for work items (usually user stories) that can be in a sprint. Briefly, the DOR lists the properties of a work item that must be true for it to enter a sprint. The DOD lists the properties of a work item that must be true to consider it done and be included in the actual capacity (velocity) for the team. Plenty of sample definitions exist online.

Ceremony: Daily Stand-up or Scrum

  • Responsible Party: Scrum Master
  • Facilitator: Scrum Master (initially – note that not only can anyone can facilitate a daily Scrum, but surely there will come a day soon where the Scrum Master is unavailable to facilitate) 
  • Required Attendees: Entire team, including Product Owner
  • Frequency: daily, hopefully at the same time every day
  • Duration: 15 minutes plus optional 15 minutes (or more, as team agrees)
  • Other notes: (1) recommend being strict on starting on-time, (2) if you mention a Jira ticket, include the ticket number so people can track things

The following script is suggested. 

  1. Begin: Scrum Master or facilitator begins the meeting exactly at the appointed time, or at most 1 minute late. Stragglers will quickly learn that the meeting started without them, and that others’ time should be respected. If some are routinely and unavoidably detained, then maybe a slightly different start time should be agreed on.
  2. Intro: Scrum Master introduces the meeting: This is the daily stand up for the <team name or description>. As you know, generally we stand to ensure that the meeting stays short.
  3. Announcements: S/he makes any absolutely necessary announcements. If there are more than about 2, then they should be written out and referred to instead of explicitly announced. If they don’t belong anywhere else, they can go into the meeting notes (e.g. in Confluence), or Slack, whichever is appropriate.
  4. Script: The Scrum Master scripts the meeting for today (do this each time, it is important):  I invite each of you to let us know what you did in the past 24 hours, your plans for the next 24 hours, and any frictions slowing down or impeding you or the team. Generally, please focus on collaboration. Be sure to note any people you’d like to get together and work with today or soon. We will finish this meeting within 15 minutes. We’ll offer the next 15 minute interval as a “16th minute” for anyone who would like to stay and collaborate after the official ceremony, but that is optional. Who would like to go first? Note the invitation. Let the team set the order for who speaks. Another algorithm is to ask a speaker to nominate a successor; there are several good algorithms, perhaps you can mix them up.
  5. Participants: As the Scrum Master records input into Confluence, we proceed in random order by who steps up to go next until the team members have all contributed – what I did yesterday – what I plan to do today – things slowing me down; focus on collaboration.
  6. Actions and Collaborations: Scrum Master lists actions and assigns a responsible party to each. Scrum Master lists collaborations requested and ensures that there is an agreement on both sides that they will meet.
  7. Adjournment: Scrum Master adjourns the “first 15 minutes”, the actual daily stand up.
  8. 16th Minute: Scrum Master announces, we’re now on the “16th Minute” for anyone who would like to use this time for further collaboration. It will last until <time>. I’ll stay as long as I can facilitate or otherwise be useful. The floor is open.

Ceremony: Backlog Refinement (including sizing)

  • Responsible Party: Product Owner
  • Sometimes called: Backlog Grooming (deprecated) or Story Time
  • Facilitator: Scrum Master or Product Owner
  • Required Attendees: Entire team, including Product Owner
  • Optional Attendees: team representatives from teams with strong dependencies
  • Frequency and Duration: Technically this is not even a Scrum Guide ceremony; the Scrum Guide does insist, however, on frequent performance of this activity. We recommend that a collection of 1 hour (absolute max 90 minutes) sessions be established in a rhythm and total duration such that Sprint Planning (when done without “tasking”) takes no more than 45 minutes. 
  • When: anywhere in a sprint; note that the information to be covered is relevant primarily to the next sprint. Again, establish a rhythm.
  • Other notes: (1) recommend being strict on starting on-time, (2) if you mention a Jira ticket, include the ticket number so people can track things
  • Required Preparation: DOR/Definition of Ready is ready; this is an agreed on team definition of what properties a Jira ticket must have in order to be eligible for inclusion in a sprint. Product Owner has submitted into Jira any requirements – mostly user stories – that are needed (it is ok if s/he puts in a few more, but not a lot more, during this meeting) and that most of these are roughly prioritized (“MoSCoW”)
  • Optional Preparation: even though Jira is in use, many teams ask that the Jira tickets to be considered be placed onto 3×5 cards or sticky notes for tactile use if the meeting will be held entirely in the same room. This can be a fair bit of work but can be very worthwhile. Product Owner is responsible for this.

Definition: MoSCoW: this means to prioritize using this pattern (more here):

  • M – MUST have
  • S – SHOULD have, if at all possible
  • C – COULD have, if it does not affect anything else
  • W – WON’T have this time, but would like in the future

Sizing: means to size the requirement. A Wideband Delphi, and therefore consensus-based and relative, effort sizing method called Planning Poker generally should be used. There is lots online on Planning Poker, but here are some of my thoughts:

  1. Introduction to sizing: we recommend this script to be read each time sizing is performed: When we are sizing today, be reminded that our goal is not productivity but predictability. Please keep any thoughts of time to yourself, e.g. no mention of words like days or hours. Size relative to our baseline story (be sure to identify the story). Avoid sizing aloud to eliminate biasing; use the planitpoker. If you’re in a meeting room try using a phone app. In turn, the facilitator will try to ensure that everyone has voted before the reveal.
  2. If needed, baseline sizing with a baseline story – a first story (8 points) or a small (as perceived) story (1 or 2 or 3 points). That story becomes your baseline story. The previous sentence leaves quite a bit of flexibility; the initial recommendation is that teams start with a baseline small story that is designated as a 1 point story for comparison purposes.
  3. Discuss top story on the backlog (after all, its priority is highest, from the refinement that has already been done) – PO leads
  4. ALL team members pick their estimate face down or virtual face down. The PO may participate as the team decides, but stay consistent on this; the Scrum Master should not participate, only observe. The principle is: only if you are doing development work should you participate in sizing; after all, it is that work itself that you are estimating.
  5. Show estimates once everyone has committed to a sizing
  6. Explore largest/smallest
  7. Repeat until team agrees on size for the requirement

To perform sizing across several geographies, try planitpoker.com . To perform sizing including several people in a single conference room, try one of the phones apps listed here in my blog entry on the topic.

The following meeting script is suggested.

  1. Scrum Master opens the meeting, declaring its purpose, its time box (ending time), and ensuring that all required attendees are present, in particular the PO and PM. Scrum Master should state the best understanding of the team’s current user story velocity.
  2. DOR: the Product Owner is invited to review the Definition of Ready. This should be reviewed every time.
  3. More? Scrum Master asks if any requirements need to go into the backlog; those from the PO are automatically inserted. Those from others are considered by the PO, who should let them in unless there is a very clear reason not to (e.g. it’s a duplicate).
  4. Scrum Master asks whether there are any requirements that have not been at least roughly prioritizedalready; such requirements are immediately prioritized with MoSCoW. The PO performs this prioritization while s/he is watched by everyone. Anyone can supply input to the PO during this, however the idea is to get this done quickly. If there is lots of argument, just do what the PO is suggesting and move on.
  5. Scrum Master asks for rank prioritization. Product Owner leads this. S/he rank orders the Must Haves, topmost, then next, then next, etc. All discussion is welcome, but again the idea is to be brief. If there is lots of argument over placement of a requirement, put it where the PO wants to put it and move on.
  6. Scrum Master asks for sizing. See above. Take the top requirement. Product Owner briefly describes it. Team sizes the requirement. Repeat until the Must Haves are exhausted. 
  7. Scrum Master asks for splitting. Knowing the team’s velocity, and starting at the top of the rank ordering, split any stories that should be split. The Product Owner leads this. Each resulting story should be roughly prioritized, rank ordered and sized by the team as you go.
  8. If there is time, the Scrum Master can invite discussion of the Should Haves to determine if any of them actually are Must Haves, in which case they are rank ordered as before and sized by the team as before.
  9. When you run out of time, so be it. If you need more backlog refinement, the Scrum Master facilitates getting it scheduled.

Ceremony: Sprint Planning

  • Responsible Party: Scrum Master
  • Facilitator: Scrum Master and/or Product Owner
  • Required Attendees: Entire team, including Product Owner
  • Frequency: on the first day of each sprint or as soon as possible thereafter
  • Duration: until it’s done; schedule an hour and try to be done early … ok, perhaps your first time schedule 2 hours and try to be done early

Here is a suggested script:

  1. Scrum Master ensures that the following information is conveyed: the sprint, its dates, the current vision, current roadmap, current release features, development status, architecture, previous sprints highlights as needed. This needs to be quick, but it all must be covered, every time.
  2. Show the velocity in prior sprints, preferably from a Jira-based information radiator. Team then comes to agreement on new velocity.
  3. For each team member, determine availability and resulting capacity in story points (there’s some math here for which a spreadsheet often proves convenient)
  4. Review the Definition of Done
  5. Review other definitions as needed
  6. Product Backlog review by PO, and select user stories that can be completed in sprint
  7. If user stories must be tasked, then this is the place to do it. This is a significant topic and we do not go into it at all here, other than to say we recommend that a team new to Scrum and User Stories begin by doing no tasking and see if they can make it work with nothing more than informal and frequent collaboration instead.
  8. Challenges, dependencies and risks
  9. Review capacity required, risks and mitigations, and ask for …
  10. A Commit to the forecast! (use a fist of five)
  11. Parking lot and actions
  12. Any quick plusses and deltas as a quick retrospective on the meeting

Ceremony: Sprint Review and Demonstration

It’s simple: at the end of each sprint, review your software (or systems, whatever it is that has been developed). This must include an objective demonstration of the software, a real demo; though it need not be formal it must be a real demo.

  • Responsible Party: Scrum Master
  • Facilitator: Scrum Master; not the Product Owner, as the Product Owner should focus on the Product, and receiving and approving work done as meeting stakeholder needs
  • Required Attendees: Entire team, including PO; any interested stakeholders; as many clients and/or client proxies as you can find
  • Frequency: near or at the end of each sprint
  • Duration: as long as it takes with a preference for shorter
  • Notes: many use Jira for this exercise: each user story is demonstrated in turn. Reminder: it’s not justa demo, it’s a review of what has been developed. The demo is your objective demonstration that what we say has been done, has been done.
  • Introduction: the ceremony can start with this: This is the Sprint Review. Its purpose is to review our product as it has been refined over the last two weeks, and demonstrate what we have done to our stakeholders to obtain their feedback. This is our objective demonstration that what we believe we’ve completed is done to the satisfaction of our stakeholders. In general we’ll go through the Jira items one at a time in priority order, per the script we’ve been preparing over the last few days.

Ceremony: Retrospective

At the end of each sprint, review your process.

  • Responsible Party: Scrum Master
  • Facilitator: Scrum Master
  • Required Attendees: Entire team, including Product Owner
  • Frequency: at the end of each sprint; optional: every other sprint
  • Duration: 1 hour

Suggested script: 

  1. Introduction, including the ceremony stop time. Here is a good script for the introduction that includes Norm Kerth’s prime directive: This is our retrospective, where we evaluate and experiment with our development and delivery process with intent to improve. Regardless of what we discover today, we understand and truly believe that everyone did the best job s/he could, given what was known at the time, his/her skills and abilities, the resources available, and the situation at hand. Our purpose here is continuous improvement, to become more skilled and higher performing as a team over time. We will end this session at ____.
  2. A framework is set up for the retrospective. There are many available, for example search for “10 retrospective styles” online. Here is one often used early on: Scrum Master asks for each person attending 
    1. to write down 3 things that went well
    2. to write down 3 things that could use improvement
    3. to prioritize each set

Stickies can be used if everyone is in the same room – one item per sticky note.

  • Each person articulates to the group attending their top went-well item – skipping those already covered
  • Ditto improvement suggestions
  • Scrum Master records actions as we go
  • Suggestions for improvement are prioritized
  • Each is placed into a Process Improvement Backlog
  • The Scrum Master ensures that the top two are assigned volunteer owners in Jira
Posted on

Link Library – stuff I recommend on the www

For a long time I maintained a web page. It’s still there (www.densmore.org) but I just don’t use it for a whole lot anymore. Maybe I should link from there to here – I just might do that. Meanwhile, I do occasionally like to keep a link, or recommend a link, on a variety of subjects. Most of my links should be thought of as starting points – there’s always more to learn. So that’s the purpose of this post. If I do as I just promised myself I’ll update this when I find new stuff … and even occasionally test the thing to be sure a previously installed link still works.

Subjects you’ll find below, should you choose to you scroll down: Agile, Distribution, …

Subject: Agile and Agile Frameworks and Methods

Subject: Distribution or non-colocation or we’re all in different places

Posted on

Jiras

What do you call it? A ticket? An issue? An item? A work item? A requirement? A Jira issue? (Obviously not, if your squad is not using Jira.) I am referring to the most general notion of an item in the collection of items in your Agile workflow management system. By most general, I mean that some of them might be called defects, and others might be called user stories or epics or requirements or what have you, but what do you call an item that could be any of the items in the entire collection, regardless of type?

At Rational we usually called them Work Items. Jira calls them issues. I’ve heard the word tickets used many, many times over the years. My current squads seem to be calling them Jiras, which strikes me as kind of amusing but it’s entirely logical, given that they use Jira.

I looked up some examples of Agile workflow management systems. There are a lot of them, some I haven’t even heard of, and some I know but which the current literature doesn’t mention. I found Atlassian Jira, Rally, Clearquest, Rational Team Concert, Active Collab, Agilo for Scrum, Pivotal Tracker, SprintGround, TargetProcess, and VersionOne, among others.

I’m also interested in whether you think of these items more in the context of work to be done or more in the context of specifying the need or requirement. (Except, per Walker Royce, it’s not a requirement, it is a desirement. It’s negotiable. Agile readily acknowledges this but it wasn’t at all obvious at the time Walker first began speaking of this idea.) These days I see less of a need for requirements management because Agile asks your feedback loop to be very short, and asks for dedicated product management, which generally means that simply accounting for the requirements/desirements as work items is sufficient. That is, this work to do, and when done, the work will result in meeting this desirement. In very large systems, not so much, but in a substantial part of the IT world this is what is working.

As always, your thoughts are welcome.

Posted on

Installed uAvionix ADS-B solution on my 180

Ok, aviation post for a change. (I should post more aviation posts.) I decided recently to acquire a uAvionix tail beacon ADS-B unit. It’s described here: https://uavionix.com/products/tailbeacon/ .  I wanted something in 1099 but the price here was hard to beat and I wasn’t ready for the 1099 solution, which includes other stuff I need to get, for example replacing one of my comm radios. I need to save more money.

This solution was trivial to install. I ran the checkout flight the other day and it went pretty much flawlessly. Bottom line is follow the directions and it’ll likely work out well. uAvionix tells you how to do it here: https://uavionix.com/support/skybeacon/flying-a-performance-or-rebate-flight/ . I left kFLY after a good solid 15 minute warmup, flew over COS for over 30 minutes, and did some 360s as indicated in the directions.

A colleague of my IA’s wrote this up about my result: 

The report is a passing report and the unit is effectively certified.  A hard copy of the report should be placed with the aircraft paperwork.  A logbook entry is required that states the ADSB unit was tested as per FAR 91.225 and shown to meet FAR 91.227.  There is annual continued airworthiness that must be performed as per the Continued Airworthiness Manual that should be printed and placed with the aircraft paperwork.

It looks like he did not wait long enough for the GPS system to meet the WAAS standards and that is what caused the very small percentage of NIC/NACp errors.  It is still a passing report, so just advise Jim to wait a little longer before takeoff.

The advice to wait longer is sound, but after waiting 15 minutes to depart, I think kFLY is simply in an ADS-B hole. Anyway, I had a good experience here and I hope yours is equally good. Please let me know if you have any questions and I will try to answer them.

Oh, here is my report, suitably sanitized and kinda totally outta format but you’ll get it if you have seen other reports. You get your report after your flight here: https://adsbperformance.faa.gov/PAPRRequest.aspx .

U.S. Department of Transportation Federal Aviation Administration ADS-B Performance Monitor 

Public ADS-B Performance Report
Broadcast ICAO: A8A255 (52121125) 

Period: 10-19-2019 21:45:33 to 10-19-2019 22:28:23 

Operation Analysis Overview 

Airborne UAT 

Prepared By 

Surveillance and Broadcast Services (SBS) Program ADS-B Performance Monitor 

October 20, 2019 

Note: Items high-lighted in red within this report indicate the ADS-B Out system installed on this aircraft failed to meet the corresponding performance requirement as specified in § 91.227. 

For more information on this report, reference the User’s Guide.
OMB Control No. 2120-0728 | Expiration Date 4/30/2017 

Operation Summary 

Operation Id: 412384628 Start Time: 10-19-2019 21:45:33     End Time: 10-19-2019 22:28:23 

Broadcast ICAO: A8A255 (52121125) 

Duration: 00:42:50 Reports: 13371 Stationary: No 

Mod: 00:42:50 Best Msg: 2539 Baro Alt (ft): 

Rule: 00:40:48 

TIS-B Client: 97.6% 6800 – 10900 

Link Version: Last Flight Id: Operator: 

Airborne 

Surface 

Out Capability: 

UAT

In Capability: DUAL 

Airborne 

UAT Analysis Summary 

Start Time: 10-19-2019 21:45:33 Duration(s): 00:42:50 Mod: 00:42:50 

Link Version: 2
Emitter Category: 1 – Light (<15,500lbs) Last Flight Id: N6555A 

Exceptions: 

End Time: 10-19-2019 22:28:23 Rule: 00:40:48 

Out Capability: UAT Antenna(s): 1 – Single 

Total Reports: 13371 Processed Reports: 2511 

In Capability: DUAL 

NIC NACp NACv SIL SDA 
No No No No No 
page3image59771904

Airborne UAT Analysis 

Missing Elements 

Category NACp NACv Vel Flight Id Mode 3A Emit Cat Baro Alt Geo Alt 
% Fail 0.00% 0.00% 0.08% 0.00% 0.00% 0.00% 0.00% 0.00% 
Max dT 00:00:00 00:00:00 00:00:02 00:00:00 00:00:00 00:00:00 00:00:00 00:00:00 
MCF 0 0 1 0 0 0 0 0 

Integrity & Accuracy 

Category NIC NACp NACv SIL SDA 
% Fail 0.12% 0.12% 0.12% 0.00% 0.00% 
Max dT 00:00:04 00:00:05 00:00:05 00:00:00 00:00:00 
MCF 2 3 3 0 0 
Category NIC NACp NACv SIL SDA 
Avg 8.3 9.2 1.8 3.0 2.0 
Min 0 0 0 3 2 
Max 10 10 2 3 2 

Kinematics 

Other Checks 

Velocity Position Δ 
% Fail 0.00% 0.00% 
MCF 0 0 
Baro Alt Baro Alt Δ Geo Alt Geo Alt Δ 
0.00% 0.00% 0.00% 0.08% 
0 0 0 2 
Emitter Cat Mode 3A 
% Fail 0.00% 0.00% 
Max dT 00:00:00 00:00:00 
MCF 0 0 
Flight ID Tail # Mismatch Non-US No “N” Only “N” Partial Spaces All Spaces Illegal Char Unavail Char FP ID Mismatch 
% Fail 0.00% 0.00% 0.00% 0.00% 0.00% 0.00% 0.00% 0.00% 0.00% 0.00% 100.00% 
Max dT 00:00:00 00:00:00 00:00:00 00:00:00 00:00:00 00:00:00 00:00:00 00:00:00 00:00:00 00:00:00 
MCF 0 0 0 0 0 0 0 0 0 0 
Air on Ground 
% Fail 0.00% 
Max dT 00:00:00 
MCF 0 

Note: The above FP ID Mismatch field can be disregarded when no flight plan was filed for the associated flight. 

page4image60218880

Airborne UAT Analysis Page 4 of 6 

This page intentionally left blank. 

page5image60219456

Airborne UAT Analysis Page 5 of 6 

This page intentionally left blank. 

page6image60220032

Airborne UAT Analysis Page 6 of 6 

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.