Skip to main content

Tag: Risk

In Security

Let’s face it. It’s all about information. Everything we do is about information. We need information to do our job, and our job is usually about information, information that is collected from a wide range of sources over a long period of time, information that is created through the combination of other information, information that is printed, displayed, organized, manipulated, and stored for decades if not eons.

And that information is important. We depend on information.  We use information to know what is going on, to make decisions, to entertain us, to communicate, or simply to take us to places we’ve never been. It’s all about information.

It’s all about information security

And then, it’s all about security of that information; who can see it, when they can see it, how much of it they can see, and in what form will the information be kept and for how long? Should the information we need be secure and to what level? Should it be private, and private to whom? When should it be released? How long should it be kept before releasing or destroying? Can it be destroyed?

Security. Even in IT, we tend to view security as a specialist’s area. Security people are strange birds, and security “stuff” is generally the bailiwick of specialists who think differently than the rest of us. They have their own vocabulary – black hat, white hat, encryption, public and private keys, breach, vulnerability, hacker, cracker, malware, and so forth. As Business Analysts, and even as Developers, information security is viewed many times as a layer of nonfunctional requirements and / or software added to the basic business requirements at some later date in the software development lifecycle.  And in many cases that is the way it has to be.

But consider this; a breach in security is bad for business. Loss of information is not simply an IT issue; it is a business issue.  The loss of information might well lead to the loss of the entire business. Security requirements are business requirements. Consider even further – the level of security is based on the value of the business assets being secured. Therefore, it is necessary to analyze the business assets to determine the value of those assets and what levels of security are necessary. Note the words “analyze the business”; in other words, business analysis.

We are all insecure

The reality in information security is that there is no foolproof way of securing the business’ information except by physically disconnecting all the information from any external access.  In other words, “unplugging”. And while that was a perfectly valid business strategy 50 years ago when I started, today the concept of being completely disconnected from the Internet and still being successful in business would be considered far-fetched. (Actually for most businesses back then “unplugging” was not an option since there was nothing to “plug” into. Locked file cabinets containing the business “secrets” sufficed.) In those days, we who defined requirements, design systems, wrote the code, and tested the results were not worried about information security. Security, not just information security but all security (there was no category called information security at the time) was indeed handled by a completely different organization with whom we in data processing (as it was called back then) rarely had interactions. Security back then was focused on physical security, preventing unauthorized access to the premises, and to those locked file cabinets.

A Security Guideline for Business Analysts

Since we cannot, as Business Analysts, developers, or even security specialists, completely prevent an intrusion or a breach from occurring in today’s interconnected spider web of information, we need to have a guideline, a balance between security and convenience, between preventing access by the bad guys and inappropriately filtering out the good guys. If we do business on the Internet, we need to make it as easy as possible for those seeking to do business with us to access the information they need to do business while at the same time preventing those with malicious intent from accessing, manipulating, or modifying our information.

So we have this guideline that was written on a card which I kept pin on the wall of my office in a previous life in security:

Make the cost of the breach exceed the value of what is compromised.

If we are able to implement this guideline effectively we should be able to present the majority of damaging breaches, and pretty much all intrusions based on economic gain. What this does not prevent against those who are attempting to break security for reasons of revenge, “fun”, or simple malevolence. And those areas are indeed the purview of the security specialists, and probably also the psychologists.

However, the general approach will be effective.  Considering that the “cost” includes not only the time, effort, and or monetary expenditures to get to the information, but also the length of time of exposure. For example, the “Club” which many car owners have affixed to their steering wheel to “prevent” theft of their vehicles does not actually prevent theft. Cars can be stolen with a Club on the steering wheel. What the Club does is increase the amount of time the car thief has to spend to steal the car; thus, the “cost” of the theft is in the extended exposure and increased potentiality of being caught. If the vehicle is a Ferrari or some other car that costs six figures to purchase, it might be worth the risk. If the vehicle is my 17-year-old sedan, it clearly would not be. So the “cost” can also be measured in “exposure time” for the bad guy.

To make that guideline work effectively, the business must first have a definition or assessment of the value of its information. Not all information has the same value. And the cost of securing that information should be directly proportional to the value the information has. In other words the organization should spend more time and money securing their customer master files which have national identification numbers and credit card information than in securing the departmental picnic list file that contains the names of employees attending the annual picnic and what dish they are bringing (to prevent too many bags of potato chips and not enough vegetables).


{module ad 300×100 Large mobile}


The Business Analyst’s Role in Security

It takes business analysis to determine and assess the value of the information in the organization for any given business process or information system. Since security should not be an afterthought to be added after the systems or changes have been developed, it is up to the Business Analyst to determine the value of the information, all the information, being used by a particular business process or information system. The Business Analyst may not be required to identify threats and or countermeasures which is indeed the domain of the security professional (although I have seen many Business Analysts involved with threat assessment in organizations because of their breadth of knowledge of the business activities, processes, and information.)

The Business Analyst also provides a valuable check and balance to security by identifying when security measures may be too much – they prevent business from happening or make it exceedingly difficult – thus impairing the organization’s mission or keep it from achieving its strategic goals.

Helping the organization become secure

We typically think of security in terms of protecting against malicious intrusion or identity theft. But when we consider the entire business there are many other areas in which security is important to the business. For example, corporate espionage is a threat to many businesses. Privacy of both the employees using the systems and customers entering their data into the corporate databases has been increasing in importance the century and generally falls under security. While security is a policy of the organization to protect the organization, privacy falls under regulations of countries and other jurisdictions and may cause an organization to run afoul of the law.

Many times the solution to a security problem is not additional software or technological engineering, but a simple change in the business process. The Business Analyst is the primary role familiar with the entire business process and is able to identify security weaknesses in the human activities which in many cases is where a security breach starts.

While the technologists will focus on the networks, the portals, the access points, the web servers and other technology-based vulnerabilities in the organization, the Business Analyst can look at a wider picture that includes the movement of information outside the computers throughout the company and the people who handle that information.

It takes a Business Analyst to put a security problem into a business context. It takes a Business Analyst to evaluate whether the assets being protected are worth the cost of the protection. It takes a Business Analyst to understand the human factors involved with security issues and security breaches.

The Business Analyst can provide valuable information to the security professionals to help make their job easier and more accurate thus adding value to the organization (in terms of increased and better security, and a better cost-benefit ratio for the security activities) which is what the Business Analyst is all about.

Let’s Make a Deal – The Art of Project Negotiation

You’re a Business Analyst or Project Manager on a technical project. You probably realize most of the roles and hats you need to play and wear. You are a task master, a resource manager, a change agent, a master communicator, a meeting facilitator, a financial wizard, and a critical decision-maker.

And now you find out you are also a master negotiator. Yes, master negotiator. Or at least, you should be. At least, you better be ready to at least “fake it till you make it.” You may be negotiating right now on your projects and not really realizing it, but you might want to focus on where you are doing the negotiating and pinpoint what you are doing and work at improving those skills. Why? Because you will always need those negotiating skills – likely on every project that you manage to some degree – and you’ll want to continually improve in this area. Again why? Because you often need to rely on winning those rounds of negotiation in order to win on your project or keep it moving forward and keep your project customer satisfied and confident in your ability to keep the project running efficiently and on track in terms of time and budget.

Do you consider yourself a negotiator?

Whether you are a Business Analyst or Project Manager, you are negotiating from time to time on the projects that you are engaged on or managing. Do you consider yourself a negotiator? Have you been aware of these events as the projects unfold? Let’s consider what these negotiating opportunities and needs are so that we can be aware of them the next time they occur and use our negotiation skills to our maximum benefit and become even better at negotiating when we need that skill next time. Some negotiation events or opportunities we likely run into during the course of some of our projects throughout our careers are:

Negotiating for resources. Maybe you really need a top technical resource, and you can afford to put more of a part-time Project Manager or Business Analyst on the project – or one with a little less experience – because it’s a very short-term, but very complex project with a complex technical solution. You negotiate that resource acquisition to the most favorable way possible for your project, right? You look at the landscape of your resource needs and trade-off accordingly because you’re never going to get the best of the best at every project team member position anyway.

Negotiating for task assignments. You look at your resources on the project team and the tasks to which you need to assign them. When are they going to be available considering their other project commitments with other Project Managers and Business Analysts and which tasks do they love or hate. Some “don’t do windows”, so to speak. I had a contractor on my house who would do everything but hated to paint, so I found someone else to paint and he gave me a great price on all the work he loved to do. Negotiation – it gets tasks assigned and to the right people who have the right skills and love that specific work.

Negotiating for deadline dates. Sometimes deadline dates need to move, for whatever reason. Usually for the good of the project, but that doesn’t mean you won’t need to do a little negotiating with the project client to make date changes happen. As the Business Analyst, you can work with the technical team and see what functionality can be shifted around if you are doing a phased rollout on an Agile project. The key is to show the client documentation that convinces them the project won’t be at risk, and the trade-off is not going to affect them adversely. It may take some skilled negotiating, and you will have to do this from time to time. If you haven’t yet, you will.

Negotiating for project funding. When have you ever run a project that had an abundance of funding available? If additional funds are needed – if that is even an option – you may find yourself negotiating for those extra funds. Whether that’s from your senior management or the BA going to the client and explaining why the technical solution is going to cost more than originally planned – either way negotiating skills will likely come into play.

Negotiating on project change orders. Just as for additional funding, you may find yourself negotiating with the client to get needed change orders approved. Usually, this will come up as needing to give away some work for free in order to get sign-off on a needed change order that will add needed functionality to the project but also will end up costing the project client more than they originally planned to spend.

Negotiating on technology used for project solutions. Sometimes the client comes in with a technical solution in mind. In fact, the latest and greatest technology may be the entire reason the project was initiated. How that technical solution is implemented, and even the technology behind the solution may need to be changed from what the sponsor originally wanted for practical purposes or to stay withing budget and time constraints. Either way, negotiations will likely need to take place.

Summary / call for input

I realize that some of these instances just happen, and you may not have considered them negotiating points. But many times they are. And you can leverage one incident against another when necessary to get what you may really need or want on the project. You can take a less experienced tech lead resource in exchange for the top data integration specialist this time around because data integration is critical on this project but you can let the top tech lead go to another project. In the long run, you’ll be ok. There, you just negotiated. It’s often give and take – you gave, and then you took.

What about our readers? When have you had negotiating opportunities on the projects you are working on? What strategies do you employ to get the things you need and the dates you require and the funding that is critical to your project? What other negotiating opportunities would you add to my list above?

Leadership Lessons: A 7 Phase Methodology – Phase 2 – Establish Rapport

 Editor’s note: We will be showcasing each phase of Peter de Jager’s methodology in weekly posts. Click here for phase 1 and check back every week to read the next phase.

As someone involved with ‘selling’ the change, remember the lesson from sales. People buy from people they like. Do they trust you? Change management is an exercise in diplomacy.

  • Don’t have all the answers.

Change ‘agents’ have a tendency to outline the entire change. They see the change as something they ‘own’ and must, therefore, dictate the exact ‘solution’. A system written with the users input will ALWAYS have a better chance of success than a solution foisted upon them by an isolated IS. The role of a ‘change agent’ is to make change possible, not to define the change to be adopted.

  • Support empowerment

Empowerment means giving the target audience the option to make decisions. The flip side is that you, the change agent, must give up the desire to make all the decisions. The more you leave in the hands of the target audience, the more you build their sense of ownership.

Related Article: Implementing Change – Phase 1 – Understand the Change

  • Don’t ask for ‘buy in

When you ask for ‘buy in’ you’ve already failed. It means you’re presenting them with both a need to change and the ‘solution.’ To be more precise, you are presenting them with your solution. You’ve invalidated any empowerment you may have created.

  • Seek out their ‘vision’

Again, this meets their need for ownership in the change. We resist change most when it leaves us powerless when we have no control over our future.

  • Identify influence leaders, early adapters, and resistors

Influence leaders are those whom others look to for guidance; they are not necessarily those early adapters that take to a new change first. Your time is best spent getting influencers to change, rather than catering to the early adapters or resistors. (Of course, sometimes you’ll be in a situation where the biggest resistor is also the biggest influencer.)

  • Change thinking: ‘Change Agent’ vs. ‘Inflictor of Change’

The term ‘change agent’ creates an image of a person on a mission. Another phrase more in keeping with the reality that change hurts is ‘change inflictor.’ It forces you to keep in mind your primary task is to disrupt the status quo. When you think like a ‘pain inflictor’ then you have one strong objective – reduce the pain. Consider your local dentist. His single goal is to minimize the pain experienced during a specific ‘change’. By showing concern for people’s reluctance to leave their status quo behind, you also reduce their resistance to the proposed change.

© 2015 Peter de Jager – Reprinted with Permission. 

Bob the BA – The Intelligent Disobedience of a Badass Business Analyst

Join us at at ProjectSummit * Business Analyst World NYC, Oct 13-15 where Bob the BA will be the keynote speaker!  Spots are filling up fast – don’t miss out! Register today!

As a Badass Business Analyst, I am keenly aware that there are always going to be difficult conversations to be had, opportunities to be seized, monumental influencing efforts to undertake, and times where I simply need to go against the grain or broach a difficult topic. I might just have to disobey normal conventions. We are about to have one of those “moments”. Have you intelligently disobeyed your leader or your organization lately? One can argue that if you are not actively and intelligently disobeying on a regular basis you are not progressing, evolving, and helping out your organization.

Now before you answer quickly, rage against, or praise the question and/or the concept, let’s level set a few things… Let’s answer the questions of what is a Badass Business Analyst and what is Intelligent Disobedience?

A Badass Business Analyst is someone whose moral compass always guides them to do the right thing for the people, the project, and the organization maximizing business value. They are someone who uses their knowledge, skill and experience to call bullshit on entitlement, and speak truth to power because they give a damn.

What is Intelligent Disobedience? Technically, Intelligent Disobedience is where a service animal trained to help a disabled person goes directly against their owner’s instructions in an effort to make a better decision. Why don’t we break this down for how a human might interpret and apply it? “Intelligent” means the ability to acquire and apply knowledge and skills as well as having the capacity for thought and reason, especially to a high degree. “Disobedience” is a failure or refusal to obey rules or someone in authority. They seem to work against each other but actually fit together like warm cherry pie and vanilla ice cream. “Intelligent Disobedience” is understanding that you should disobey instructions, authority or other influences to make a better decision. When you combine that with the “Badass” mentality, Intelligent Disobedience is: A Business Analyst who is willing and able to disobey authority, break rules, or go against the status quo when they know it is the right thing to do for the people, the project, or the organization. But is that easy to do? No, but when you are successful it feels like warm cherry pie and vanilla ice cream. Tart, sweet, and soothing – it just tastes so right (and yes, insert your own flavor of pie and ice cream for the full experience)!

A lot can get in the way of breaking the rules or going against authority. Most people have been taught early on that Disobedience is simply not tolerated. For example: disobeying my father was not a smart thing to do. He took a belt to me once, just once, and thereafter it was the threat of the 2×4. No, I am not kidding! Disobedience in his world was the last straw and if he sensed you were about to disobey he would run out to the garage, come marching into the house with the 2×4 in hand yelling “Do you want this!? Are you sure!?” For the record, I never got hit by the 2×4. It was the threat that kept me in line. My mother though had her own methods; which was a bar of soap and a washcloth – for everything (which I can still taste to this day – thanks mom). Despite that upbringing of the fear of the 2×4, I have still recognized that disobeying can be good in organizations where rules, processes, and decisions simply do not make sense. For some organizations, disobeying a leader could be a CLM (career limiting move) which is a lot like that 2×4! Judging when you can break the rules or disobey a leader is not always readily apparent and much thought should go into this decision.

Intelligent disobedience is not about extremism. You do not simply jump off a cliff because no one else has. You never compromise the principles and values of your organization, nor do you withhold communication from your leaders. It does not mean you argue just to argue, be a random rule-breaker or be disruptive and sabotage. One could argue that you can indeed disagree with the principles and values of an organization but ultimately, they are paying you to uphold those values and add to their collective whole. What you should be arguing and disobeying is whether or not what you are actually working on supports those values and goals of the company.

Intelligent disobedience is about dealing with conformist views, challenging the fallacy that your leader or people you work with are always right, ensuring you are a critical thinker, and when no one else can see the answer make a decision for the right reasons. Please keep in mind when I say you should “challenge the fallacy that your leader or people you work with are always right”, this is not a disrespectful view. This is a realistic view that everyone is challenged with making difficult decisions and we should not assume that those decisions are always right. When all is said and done, intelligent disobedience is not exactly something that will be easy to do for some of us, even if we are Badass Business Analysts! Here are some ways to help you be ready to be intelligently disobedient.

  • Determine if it is a fact or opinion? Don’t let your mental model of what you think something is become truth without verifying. This is where you will learn to be a better critical thinker. A lot of things come out of people’s mouths where the truth is stretched, manipulated in some fashion, or clearly not present. A critical thinker will question fairly to break down statements to validate and verify.
  • Trust and then verify. Do not blindly trust – not even your subject matter experts. Yes, our SMEs work very hard and they have a tremendous amount of knowledge that they are entrusted with. Knowledge that they are expected to manage with accuracy. However, our subject matter experts also know things by muscle memory and rote. They know it but they may not be able to readily recall all of it; they have a lot of tacit information. Trust them initially, then verify the accuracy. It is an intelligent decision to not take things on blind faith which a lot of people do. In order to disobey you need facts and they need to be correct facts. Hey – did you catch that you should determine if the statement “our SMEs work very hard” is a fact or opinion?
  • Separate yourself from the “yes” crowd. You know what I am talking about right? Conformists are a dangerous group to be around, and honestly, they inhibit a company from progress. Do not agree just to agree regardless of the pressure being put on you. You can walk away and make an informed decision later. I was once at a client site where I watched an entire group agree with the sponsor as they forced their idea down everyone’s throats. Everyone was too afraid to say no. When it came to me I said no. The response? “Bob the BA? I will remember you.” I knew they were headed for failure but were not ready to make the commitment for change. I was fighting too many “yes men”. I intelligently disobeyed and started working on the solution without approval because I knew this was going to be a timing thing. A few weeks later when they came to their senses everything was ready to go. Yes, they did remember Bob the BA but not because I disagreed.
  • If you think it has to be done that way rethink it! Challenge yourself. Reflect on how you thought about things during the day. Could you do it differently? I spend a lot of time reflecting on my “sins” of the day. Areas where I could have made a difference by speaking up or simply doing and asking for forgiveness later because I knew I was right and could back it up. I don’t dwell on my missed opportunities too much. I simply need to reflect, recognize and resume the journey.
  • Learn to live with saying “no” comfortably. So not an easy thing to do! Most of us live in a world where we say YES! It is a service attitude, a pleasing mentality. What if we looked at saying no as a service to our company? The idea that “no” means we are potentially saving the company money, improving processes, and removing roadblocks which is a great thing!

At the end of the day, a Badass Business Analyst needs to be intelligently disobedient because we care and we know that it is the right thing to do. Don’t go crazy and start saying no to everything. Take a step back and recognize what is the right thing to do. There is certainly a lot more to say on intelligent disobedience, and certainly a lot more lessons to be learned about its effectiveness. I am betting there are a lot of people out there that have had great success and likely some failure with being intelligent disobedient. Experience is a great way to learn – want to share how you have been intelligently disobedient?

*republished from February 2015

Don’t forget to leave your comments below.

The Collective Memory of the Team

If you’ve any experience in Agile approaches for software development, one of the common arguments surrounds documentation. Mostly it centers on software requirements, but it also extends to other forms of documentation, for example, design or user-centered documentation.

Many Agile teams struggle with documentation. My experience aligns with folks leaning one of two ways:

  1. Either they continue to write requirement documentation (and literally ALL documentation) as if they were still operating in a Waterfall environment, or
  2. They write user stories that are so terse as to be hardly useful in describing the customer’s expectations. And they often stop writing anything else.

In other words, they go to the extremes of documentation instead of finding a healthy, lean, and communicative balance. One of the reasons for this seems to be our view of documentation as being the sole repository for product and team knowledge. While that’s true, I also like to remind Agile teams that there is another viable form or place for that knowledge – which is the team’s memory. Since many of the Agile ceremonies are whole team events, I like to ask teams to use their collective memory as part of their product information and knowledge archive.

This article intends to explore that notion just a bit more deeply.

The Team’s Collective Memory

I think the intent of Agile documentation, in general, is only to write what has value for the team towards creating valuable software. There is the realization that all documentation has two purposes, either it:

1. Serves as a communication device as the team is building an architecture, feature, or capability; or
2. It serves to document something for future consideration.

If we’re worrying about our current sprint or the next few sprints, then conversations are equally important to writing things down. And by this I mean whole-team conversations.

In one recent article, I disagreed with a fellow coach who was leveraging a backlog refinement technique that only included Product Owners and a sub-set of their teams. The rationale was driven mostly from an at-scale, Enterprise level perspective. But my key argument against it was that the team would be missing the future context that ongoing discussion, engagement, and story distilling would give them.

Not only from the short-term point of view but more importantly from a longer-term perspective. It helps the team to think about, design for, and anticipate their future. It’s also quite motivating…to know where you’re going.

Why Collective Memory Matters 

An important part of the collective memory is learning from our history. In Extreme Programming, there is a term called Yesterday’s Weather. Initially, yesterday’s weather reflected estimates and actual, so the point was to consider past work (estimates, actuals, interruptions, complexity, etc.) when estimating future work.

But I believe the concept is broader than that. Everything an Agile team does in its journey is fodder for yesterday’s weather. For example:

  • Similar stories – we’ve done something like this before. In fact, there are 8 stories in the backlog that look very similar to that historical story and this one. Should we handle them the same? What about at the same time?
  • Gotchas – last time we did something like that, it really didn’t work out very well. In fact, it literally “blew up” in our faces. Let’s not do that again…or let’s approach it a different way.
  • Knowing over doing – you know, you were right the last time when you said we needed to spike that story. Is this one similar? And would a little prototyping increase our knowledge over simply guessing?
  • Help with just enough – we encountered a story very similar to this a few sprints ago. It helped us a lot to define business rules for the discounts. Is this similar to that? Do we need that information before we can accurately estimate it?
  • Similar, but – oh, this is like that other story BUT only 50% of the testing effort and the development is about 2x more work. How many points did we assign to it before? And how long did it actually take?

I find that the more we bring our ever-increasing collective memory to bear in our user story conversations, 3-Amigo discussions, and backlog refinement, the better the results. Not only results from a delivery point of view, but also from a solution integrity and impact perspective.

Collective Memories Help Form Reference Stories

Another part of your collective memory is forming what I usually call reference stories. These are user stories that you use as examples to help your estimation. Whether you’re using Fibonacci-style, T-shirt style, or no estimate style estimation or something else, having a historical view to stories of different sizes (examples) can really help your estimation and planning.

In this case, reference stories can be:

  • Actual stories where the estimate turned out to align well with the actual (results).
  • Sometimes it’s helpful to have reference stories for the “types” of work you do: front-end, back-end, DevOps, UX, whatever.
  • You’ll need reference stories that align with your estimation values. For example, find a nice “medium” front-end story and use that as a comparison for other mediums

I also talk about the recalibration of your reference stories. If, for example, you find that your size Fibonacci-8 stories typically turn out to be Fibonacci-13’s or 3’s, then you may want to recalibrate your Fibonacci-8 story in some way. But be careful not to recalibrate too often – as it impacts the validity of your teams’ velocity going forward.

The Power of Personas

I’ve found that the more we can describe the role, the better the implementations become. But not only the implementation details but the entire process we use for developing the story. In particular, the questions and the conversations amongst the team members become much richer.

Because of this, I often try to strongly influence Agile teams to develop client or customer personas as a means of supplementing their collective memory. In simple terms, I want to teams to from “As a User” thinking to “As a Persona” thinking. This related article speaks of making that transition.

The final point is to view your personas as emergent and active understandings of your users. That is, you should be actively modifying, extending, and embellishing your personas as you gain ongoing insights. In this way, they augment your collective memory.

How to Establish Collective Memory

And one final point in establishing your collective memory is something that pre-dates Agile. What, you might ask? Note-taking. I find that many Agile teams forget to take notes as part of their work. For example, backlog refinement meetings are a wonderful place to jot down critical notes that capture the discussions, options, agreements, and flow of work.

As a ScrumMaster, I usually ask for a team member to volunteer to be the “scribe” in each meeting – usually rotating the role. The scribe tries to capture the discussions in whatever tool the team is using to maintain their stories and backlog.

Before the team moves on from the story, the scribe reviews what they heard and the notes they’ve captured. Of particular interest to me is “next steps” in the maturation of the story. If they’ve missed something important, they’ll add it to the stories context before moving on.

Often when I discuss this approach, someone accuses me of “not being Agile”; that I’m forcing the team to write too much documentation. My usual reply is that this is FOR the team and intended to supplement their collective memory as an aspect of their Agile documentation efforts.

Wrapping Up

I guess it all boils down to my expectation that each mature Agile or Scrum team continuously develops their collective memory surrounding documentation, agreements, experiments, user stories, plans, virtually everything – that it’s a viable approach to augment how much “writing” they do day-to-day.

It’s also a compelling argument for keeping your teams together as long as possible. Clearly your collective memory is also related to the team’s cohesion and longevity.
I hope this article has piqued your thinking about Agile documentation – both the written and the remembered kind. Now if I could just remember how I wanted to end this…

Stay Agile my friends,

Bob.