Subscribe to Methods & Tools
if you are not afraid to read more than one page to be a smarter software developer, software tester or project manager!
Software Development Blogs: Programming, Software Testing, Agile Project Management
Subscribe to Methods & Tools
if you are not afraid to read more than one page to be a smarter software developer, software tester or project manager!
This week I spent more time hangout out with people, which means less time is available for my blog. Sorry about that! (Also, I have a book to finish…)
People are in need of different answers. They need answers to questions about how to implement better management with fewer managers. Creative networkers cannot rely on bosses to grow healthy organizations for them. They need to know how to manage things together.
I firmly believe that networked organizations own the future.
Recipes exist to get ideas, not to be followed to the letter‚Ä†
The recipe for a project is described by its¬†Capabilities. The technical and operational requirements need to support those capabilities, but defining those up front and following them to the letter restricts the creativity of the project team, just like it restricts the creativity of the chef.¬†
‚Ä† Epicurious web site comment on¬†Vichyssoise recipe
The common practice of starting with requirements leads to the common complaint that ¬†requirements change,¬†we don't know what we want yet, our users aren't very good at defining requirements so we'll let them emerge. While these are common, they are usually a symptom of a missing piece of information.
We don't know what ¬†capabilities ¬†are needed and what is the¬†Concept of Operations that those ¬†capabilities will implement, the project as likely failed before it starts. If we do know the¬†Capabilities and the¬†Concept of Operations, we can then measure progress of our work effort, not in the passage or time, consumption of resources (including money), or the production of¬†stories or ¬†story points (which are unit-less and therefore pretty much meaningless to those paying the our work), but in ¬† Measures of Effectiveness, Measures of Performance, and¬†Technical Performance Measures..
Concept of Operations
Let's start with a formal defininton of the¬†Concept of Operations
What this tells us is that we need to start with what DONE looks like. DONE is not a set of features. DONE is not stories or story points. DONE is not modules, databases, bent metal. DONE is the ability, the¬†capability to do something of value in echnage for the money we've spent.
The assessment of a¬†capability is it's Measure of Effectiveness. These are¬†operational measures of success that are closely related to the achievements of the mission or operational objectives evaluated in the operational environment, under a specific set of conditions.¬†We need to define these upfront. The Measures of Effectiveness:
They are not emergement. They are descriptions of¬†success. When we treat them as emergent, our project is chasing a moving target and is headed to the ditch.
Next are Measures of Performance. They ¬†characterize physical or functional attributes relating to the system operation, measured or estimated under specific conditions.¬†The Measures of Performance are:
Next comes the Technical Performance Measures. These are attributes ¬†that determine how well a system or system element is satisfying or expected to satisfy a technical requirement or goal. The Technical Performance Measures:
Notice we have not mentioned coding, development methods like Scrum or XP, teams, paired programming of anything to so with building code. With these items in place, all those activities have no reason for being, other than to consume money and pass time. None of those items having anything with moving the project toward DONE, other spend money and pass time. Oh, you'll get a pile of stories implemented. Are they the right stories? How would you know. You'll perform lots of Test Driven Design. Is is the right design. How would you know?¬†
Oh your customer is going to prioritize those stories and features. How are they going to know in the absence of knowing what DONE looks like.
Capabilities Based Planning
This has been presentde before, but now it has a reason - the¬†Concept of Operations.
Capabilities based planning (v2) from Glen Alleman With the ConOps and CBP, we now have what we need to assess the development processes.¬†
We Know the Answer To That Rights?
Managers all over the world are faced with a critical challenge to their role. They ideas about management and their management style is being challenged. And this is even more important because many managers have reached a position of in their career where they thought they could "take it easy". Nothing could be further from the truth.
Today the role of managers in all industries is shifting. And in no industry more than the knowledge industry.In this video I explore why this is happening and where we may be able to look for solutions. I also present a concrete set of consequences that will affect you as a manager from the trends we are witnessing in the knowledge industry. Do you want to know more?
Sign-up here to read a white paper I wrote about the sources of disruption for managers and management in general. In it I explore where the key threats to the current management roles are coming from.Ready to explore what you as a manager can learn from The Science of Chaos?You came to the right place! :) Mystes in Finland organizes a workshop about Chaos Science applied to the challenges of managing small and large knowledge work organizations. You can visit their site to know more about the workshop and to sign up. Places are limited. In that workshop I will touch on the following topics:
Much of the discussion around making improvements in processes fails to address the governance aspects of a business or organization. Instead it focuses on the¬†personal aspects. Agile development of a software team, without the corporate impacts. The desire to¬†stop doing something without an actual replacement, under the guise of¬†we're exploring. Our the mention of the term¬†intent of the commander without understanding that filling out that intent requires complete capabilities to act in in the absence of direct supervision.
My project management maturity was changed forever at Rocky Flats, under the management of senior leaders with experience and skill formed in the US Navy. The book¬†Making the Impossible Possible is the story of that project and the learnings that can be applied in any high risk, complex, high reward domain.
Making the impossible possible from Glen Alleman The term¬†Intent of the Commander is actualized in the concept of the¬†Plan of the Day. Here's an actual plan of the day for shipboard life. This notion of¬†plan of the day was applied late in the Rocky Flats program. Before that ¬†we had¬†Plan of the Week and then Plan of the Month. The approach is very simple. What do we plan to get done at the end of this period (day, week, month? Write that down, establish some measures of performance and effectiveness for those ourcomes. Measure them, take corrective actions if they don't match the expectations. Repeat until done.
The following was originally published in Mike Cohn's monthly newsletter. If you like what you're reading, sign up to have this content delivered to your inbox weeks before it's posted on the blog, here.
I'm a child of the '60s, but only in the literal sense. I was born in 1962, so while I was alive during much of the excitement of that decade, I spent much of the decade playing "cowboys and Indians" and other non-politically correct games of the era. But I grew up in Southern California, and the vibe of the '60s lasted well into the '70s there. Further, I had a fair number of friends who had older brothers, some of whom I met only occasionally, but who were very much part of the hippie counterculture.
I remember one of these brothers-of-a-friend quite clearly. When I was 10 years old, he showed me a book called Be Here Now. Even then, I wanted to be a writer and this book really struck me as I paged through it. First, the book was square--books weren't supposed to be square unless they were picture books for babies. This book was for adults. At least I thought so. But it wasn't typeset like a normal book--it looked more like a poison pen letter; you know, like a ransom note with the text cut from newspaper headlines to make new words. There were drawings, but not drawings relegated to nice little boxes on the page. The drawings and the text were jumbled together.
It wasn't until I was 18 though that I actually read the book. I found a copy at my college library and read it. The New York Times called the book a "counterculture bible." And it was as common in the 1970s to see copies of that book around as it is today for programmers to have the Gang of Four patterns book.
I can't say the book's contents had any influence on me. It's a guide to Hinduism for Westerners who wish to become yogis. Not my thing. But the title of that book has always resonated with me: Be Here Now.
I think the ability to be here now is something too many of us are losing. We can't just be in the moment and in the place. Everyone has to be constantly on their cell phones, or checking email or Facebook on their laptops while supposedly making progress on something else. (I will admit to having paused once while writing this to investigate the bonk of a new email arriving. But I've so far withheld the temptation to look a second time.)
I witness the inability to be here now while training or doing consulting. I remember a particular client a couple of years ago where I was teaching a Certified ScrumMaster class. The boss had warned me that people there were busy so they'd have their laptops with them if needed. I spent much of the first day unable to make eye contact with a single person in the room. Not one person was truly in that room.
I really worry about this. I have daughters who are 14 and 18, and I often think about the work world they'll be entering. My wife and I have tried to instill in them the hippie mindset to be here now. Will others in their future companies share that? What will the short attention spans we are cultivating do to innovation? To productivity? To collaboration?
In the true spirit of the '60s, I'm going to leave this philosophical rather than trying to identify three steps agile teams can do to overcome short attention spans. I want to be no more practical than to ask each of you to be here now a bit more often, a bit longer, and a bit more intensely each day.
When we hear about all the methods of managing projects, the PMI Body of Knowledge, PRINCE2, home grown and commercial ¬†solutions - always look at them in the light of these 5 Immutable Principles and the 5 Practices then implement the principles.
Principles and Practices of Performance-Based Project Management¬ģ from Glen Alleman
Last week, it happened again. On Facebook I posted a screenshot of the huge checklist that I use as a quality assurance gate for my book chapters. Some people commented that this looked quite disciplined.
Frankly speaking, I don‚Äôt see what‚Äôs so special about my discipline. If you want to be agile you have to be disciplined!
I don‚Äôt see how it can be any different.
If you are thinking of agile as part of a program, each team has to have its own approach to agile. Why? Because each team has its own risks and problems. You don’t need to standardize agile for anyone. If you treat people as if they are adults and explain the principles that you want (working software all the time and expose the interdependencies), provide training or whatever other resources they need, you are likely to get what you want.
That’s why I wrote Design Your Agile Project, Part 1 for teams who are collocated, and can use any approach to agile. Design Your Agile Project, Part 2 is for teams who have many challenges, but are collocated, and can work through those challenges. Design Your Agile Project, Part 3 is for teams who are geographically distributed and have to think about what to do.
In the program, what you need is for each team to deliver, all the time. The program wants as close to continuous delivery as possible. You can reduce the interdependencies—or plan for them. You can certainly expose them.Feedback is Necessary
Did you see Jason Yip’s tweet (@jchyip) the other day, where he quoted this, “”Large organizations…lose their resilience simply because the feedback mechanisms…have too many layers of delay and distortion.”
This is why you cannot standardize on anything for any team in a program. Why? A program needs resilience. It needs to be able to release early and often. Just because it’s a program does not mean it does not need to be able to obtain feedback.
Each team must know the principles:
Teams use agile and lean principles. Management treats the people on the teams as if they are adults. The teams look at their own issues and design their own approach to agile/lean, always keeping in mind the idea that they need to deliver early and often.
Now, let’s talk about what happens when you want to meld these teams into a program.Each Team is the Heart of the Program
You might think that things roll down from the program manager or the core team. Not in my world. This is where each team’s autonomy, each team’s ability to make its own decisions about how it implements its approach to agile or lean is key.
The teams are the heart of the program. All of the teams: the core team, the technical teams, the teams that the core team represents.
This is a change from traditional process thinking. It’s a change from traditional program management thinking. This kind of thinking requires that the teams know how to do agile already, and are new to the program, not to agile. This kind of thinking also means that the program manager is a servant leader.
In a program, you will have interdependencies. You want to minimize them. How do you do that? By reducing batch size, the size of each feature. By coordinating the features with a program roadmap. And, by looking at the value of each feature, not its cost (estimate).
That means the teams need to become good at delivering, not estimating. It also means the product owners need to become very good at creating ranked backlogs for the teams, and changing them. It means that the program needs a roadmap that can and does change.
Remember, agile is about the ability to change, because the teams get to done at regular intervals, whether those intervals are iterations or because the teams work in flow.What If the Teams are New to Agile?
What if you want to have a program with teams that are new to agile or lean? You can do anything on your program. You need to assess your risks. Let’s look at the Cynefin framework to see where your risks might place you, if your teams are new to agile.
If your teams are new to agile, and they are all in one physical location, and they know the domain of the product under development, i.e. you are only changing how they are developing, maybe you are just in the Complex part of the framework. You are changing the culture of the program.
However, if you have new-to-agile teams, who don’t know the product domain, who are geographically distributed or dispersed from one another, and you want to transition to agile, do you see that you might be in the Chaotic part of the framework? That you have no way of knowing the risks?
That is much more difficult.
Let me provide you an example. Imagine that you are working with developers in Europe who have a 15-person development team. They have only programmers on their team. They have never worked with testers. Why? They have never seen the need to do so. They have been successful, according to them, up until now.
You are in New York, where the product management is. You know the product domain. The developers? Well, maybe not so much.
Several years ago, I consulted to a company that had this precise organization. They were going to “revolutionize aerospace.” Only the product managers understood the aerospace information. The developers had no domain expertise and they were several timezones away. The developers had worked together before, but had never worked with testers. They had never seen the need. They had never worked on a regulated product before.
When I suggested they had “unknowable unknowns,” and that their risks were higher than they thought they had, the senior management laughed at me. I told them yes, agile was fine, but I thought they should use one- or two-week iterations with kanban boards to expose their bottlenecks.
They ignored my advice. The company went with four-week iterations, spent a pile of money, had no product to show after 18 months. Oh, the developers bandied words such as “refactoring” and “TDD” and “BDD.” What they did was BDUF (Big Design Up Front) because they had no idea what they were doing. The company went under.
What do you do when not everyone knows what “agile” is, when you create a new product, when you are introducing that much cultural change?
Don’t panic! You work in ways to reduce your risk.
Stay tuned for Part 5.
In a recent post titled #NoEstimates - Really? there was an interesting comment.
Clearly, the business value of any feature or project can not be known with much certainty in advance of it being implemented. Still, for the purpose of keeping the analysis simple for now, let‚Äôs table this issue for a bit.
This is not the case in a governance based organization or a Capabilities Based Planning organization, where the "valuation" of the resulting product, service, or purchased or built product is part of the planning process.
It's a "build to valuation"
Knowing - to some probabilistic level of confidence - what¬†business value or¬†mission fulfillment the project or product will produce is the core of any decision making process. Knowing the cost of the value is about making decisions, analysis of alterntaives, or assessing the¬†trade space.¬†
With the "estimated" value and the "estimated" cost for that value, a decision can be made in what is called "analysis of alternatives" in our software intensive domain.
Only by having both estimates - value and ¬†cost of acheiving¬† that value, their most likely numbers and the probabilistic range of those numbers (measured usually in dollars), can we make that "analysis of alternatives," or "trade space" needed to Govern both the business and the project and products that enable the business to meet its goals.
So there are popular myths around the estimating of cost and value discussion, and a few that are just flat out bogus:
There are endless reasons for why projects fail. Some are correct, some are bogus, some are down right nonsense. Into this list I'd like at add my opinion, informed by hands on experience on software intensives programs in defense, energy, bio-pharma, commercial products, and enterprise IT.
It starts and ends, with the
Failure to know what¬†DONE looks like in units of measure meaningful to the decision makers
The starting point for the description of¬†DONE is the clear and concise statement of the Needed Capabilities for the resulting project that produce value for the stakeholders. These capabilities are stated in Measures of Effectiveness.
These capabilities state what the results from the project will do for the business or mission when they are available. The planned availability date is part of their capability. Only then come the requirements, then planning for the delivery of the technical and operational components that enable these requirements. Then several more¬†enablers of projects success are needed.
All these activities, outcomes, processes, methods are encapsulated in the paradigm of Systems Engineering. The picture below are the notional elements of Systems Engineering. This picture is from the FAA Systems Engineering Handbook. This handbook is for the National Airspace System (NAS), a software intensive program to upgrade the exiting software, hardware, and processes.¬†Other agencies and business have similar pictures.
What Does All This Mean?
When we hear¬†our customers don't know what they want. Or,¬†our customers don't know the target budget for the work they are asking us to do for them. What they are saying is¬†I don't know what DONE looks like in an tangible way that can be used to measure the performance of the project.
So one of two things has to happen when this is the case...
So when we here that famous - infamous actually - phrase let's explore. Ask a serious question, and demand a serious answer ...
Who's pay for us to explore to discover what we should have already know?¬†
Don't get an answer? Run away from that project, it's going to be a failed project.
Speaking on Techncial Performance Measures and conducting workshop on same topic with Mr. Kranz and Tom Coonce of IDA.
The right question for any suggested improvement, change, or suggesting we¬†stop doing that¬†need to produce an answer to ...
Does this suggestion increase the probability of project success?
This means tracing the suggestion to the outcome of the project being better, faster, cheaper, or some other tangible measure of improvement.¬†
What does project success look like?
The delivery of agreed-upon capability within established resource constriants, e.g. funding, schedule, facilities.
Five factors are used to assess the success
So Now What?
When we hear about something new, anything new, how can we test it that suggestion against business needs, mission needs, governance, or strategy. This starts with establishing the domain in which the suggestion might possibly work. Then proposing the framework in which it has worked or might work. Then a proposed way to assess the possible benefits of performing the sugegsted solution.
Wisdom begins when we learn the difference between "that makes no sense" and "I don't understand".
Mary Doria Russell
It is that difference that is needed to assess when a idea passes the¬†smell test.¬†
These participants play off each other, react to emergent streams of melody, contribute their own special talent to the music and pretty much work in a a self directed manner over the course of the performance.
While I'm not a fan of analogies, this is a useful one for the purpose here. There are certainly domains where the¬†Jazz analogy describes what is going on in the trio in the picture to the left.
But what about other music? Music that is just as creative, just as moving, just as impactful to the listener. Beethoven's Ninth Symphony's Ode to Joy with the poem from¬†Friedrich Schiller¬†1785 work is an example.
Words that have moved nations and populations.¬†Following Beethoven's Ninth was a movie we saw over the weekend that described this result.
In the Ninth, each performer has a score to follow, led by the conductor, but also by the concert master and the ¬†senior players in each section. The vocals are also led by a senior performer.
In the software business there are likely similar domains and projects. Ones that can be improvised and ones that require conductors, a concert master, and players who follow the score.
In both cases - and this is where the analogy falls apart - is the players are highly skilled, experienced in the art, having played the basic themes 1,000 of times over before improvising or following the score.¬†
The jazz performance is not made up as it goes. OK, fusion is, but that crap makes my head hurt. Melodies,¬†rules for cords are practiced for 10,000 hours (Gladwell), relationships between the players have magical connections not available to mere mortals. The Jazz Trio and the¬†Berlin Philharmonic are populated with highly skilled and experienced professionals. We've all heard our children play in the school band and know what that sounds like. All the platitudes in the world about agile axioms are of no worth without the necessary capabilities to actually get the work done properly.
Applying the notion that agile software development is like¬†jazz¬†makes as much sense as saying¬†I can sit in the 3rd chair of the trombone section¬†(my high school band position) and play my contribution to Beethoven's Ninth without a Curtis Institute degree in performance and 10 years experience (my aunt was a professional pianist in the late 1950's from Curtis).¬†
It's not gonna happen - in both analogies - without the prerequisites of professional performance capabilities. Otherwise the result sounds like we're back in High School Music class with Mr. Meach (my teacher).
So how long will it take us to be capable performing to a level needed to not ¬†smell like we're high school kids in the marching band? I don't know let's make an estimate.Related articles Analogies, the Good, the Bad, and the Ugly The "Real" Root Cause of IT Project Failure
Many of you will know Roman Pichler as the author of Agile Product Management with Scrum. For the last few years Roman has been working on various ideas to support envisioning and ideation. I’ve asked him to write a guest post here describing his Vision Board and how it connects to Scrum’s product backlog. I’m sure you’ll find his ideas very interesting.
Scrum is a great framework for building a product with the right features. It encourages the use of a vision shared by the product owner, the ScrumMaster, the development team, and the stakeholders, and it provides a product backlog that allows the team to move towards the vision by creating product increments.
Unfortunately, there is little guidance on how the backlog is derived from the vision. Once we have an idea for a new product or new features, how do we know which user stories we should include in the backlog? And how can we tell who should be at the sprit review meeting to help us understand if we are building the right product?
In the worst case, we could implement the wrong stories, get feedback from the wrong people, and build a product nobody wants and needs.Four Questions
I have found it very valuable to answer the following four questions before stocking the product backlog:
Without knowing who the users and customers are and why they would employ the product, it’s impossible to write meaningful user stories. Similarly, we don’t understand what should make the product special and stand out, it is difficult to make informed decisions about the product functionality, the user interaction, the UI design right, and even the key architecture and technology choices. And without being clear on the business goals and the product’s business model, it will be hard to justify the investment and attract a budget.Enter the Vision Board
The Vision Board is a simple yet effective tool that helps agile teams capture their vision and systematically answer the four questions above. The following picture shows the Vision Board, and I explain its sections below. You can download the tool for free at: romanpichler.com/tools/vision-board/
Vision Statement is a concise summary of your idea that describes your intention and motivation.
Target Group describes the market or segment you want to address. You should state who the users and its customers are likely to be.
Needs describes the product’s value proposition: the problems and pain points the product removes, and the benefits or gains it creates for the users and the customers. The section should make it clear why people will want to use and buy your product.
Product summarises the three to five features that make your product stand out. These are likely to correlate to its unique selling proposition, and they should address the needs identified.
Value explains why it’s worthwhile for your company to invest in the product and how the business goals can be achieved. Sample goals are increase revenue, enter a new market, reduce cost, develop the brand, or gain a technological advantage.
Let’s take a look at an example to make this more concrete.A Sample Vision Board
Say we want to create a new game for children to help them enjoy more about music and dancing and learn about the topics. Then corresponding Vision Board could look like this:
The board above captures the overarching vision. It states children aged 8-12 as the intended users of the game and their parents as the customers. It lists three reasons why the kids would want to play the game, the key features of the product, and the business goal and how the business model could work.
The good news is the Vision Board above helped me to think through the market the value proposition and the business model of the new app. The bad news is it contains lots of untested assumptions that would make it a gamble to use the board to derive the product backlog. What’s required instead is to systematically identify and validate its assumptions.Validation with the Vision Board
Validating the Vision Board starts with identifying the most crucial assumption, the assumption that must be tested now to avoid late failure – finding out too late that the problem is not worthwhile solving. Once you have identified the appropriate assumption, decide which method is best to address it and who should be in your test group.
Some of my favourite techniques for testing Vision Board assumptions are direct observation – watching target users and customers get a job done, for instance, observing how children play music games on the computer today – and problem interviews – talking to members of the target group about how they accomplish a job today, for instance, what’s good and bad about playing computer games, particularly those related to music and dancing.
Once you have run a test, collect the relevant data and analyse it. Then use the newly gained insights to change the board either radically or incrementally. An example of the latter is to adjust a need or to replace a key feature. But a radical change – called a “pivot” in Lean Startup – profoundly affects one of more sections of the Vision Board. The vision stays true but the path towards the vision changes. For instance, changing the product to an app that teaches children dancing by encouraging them to try out the moves themselves would be a pivot for the dance game.From Vision Board to the Product Backlog
Once you have validates the key risks and critical assumptions on the Vision Board, use it to create the initial product backlog and discover the right stories, interactions, and UI design, as the following picture illustrates.
With your initial backlog and the Scrum team in place, you are ready to start sprinting.Summary
Before writing user stories, coming up with user interface ideas or the user interaction, make sure you understand who the users and customers are, why they would use and buy your product. Find out what makes your product special, what your business goals are, and how you can meet them. As Joel A. Barker puts it: “Vision without action is merely a dream. Action without vision just passes the time. Vision with action can change the world.” You can learn more about working with the Vision Board and download the template for free at: romanpichler.com/tools/vision-board/
There is a continuing discussion in the agile community about delivering¬†value in the order set by the customer. Along with this discussion is the use of the word¬†DONE. A popular phrase is no requirement or piece of software can be considered¬†DONE¬†until it is put to use.¬†
This is a software developers point of view of course. But there is another view of software based products. It starts with the¬†Measures of Effectiveness for the resulting product. These Measures of Effectiveness are:
Operational measures of success that are closely related to the achievements of the mission or operational objectives evaluated in an operation environment, under specific conditions.
This measure of¬†DONE is not directly related to code, testing, requirements or anything like that. It is related to how¬†Effective the software is in delivering the capabilities needed to fulfill the mission or business case.¬†
The individual requirements and pieces of code that implement them can be - or should be - traceable to these capabilities. For each Measure of Effectiveness, we then need a Measure of Performance. These measures characterise:
The functional or physical attributes relating to the system's operation, measured or estimated under specific conditions.
These are also not direclty related to producing code, running tests, or other direct software activities.
All the software design, testing, integration, etc. supports the creation of the¬†ability to produce these Measures of Performance and Effectiveness. For the end user, all the development work is behind the scenes. What the customer actually bought was the ability to do something useful. To put a capability of the software system to work accomplishing a business need. Make money with this capability of course.
So What Does All This Mean?
It means that if you start at the bottom - with the software development processes - you're likley not going to see what the real picture is. This picture is that the customer paid for capabilities, measured in units of effectiveness and performance.
When we start with methods, paradigms, even cockamamie ones like not estimating the cost of the work effort needed to produce the capabilities, we loose the connection to why we are here. We are here to produce software that provides a capability. Likely more than one capability.
So when we hear words like -¬†we can manage projects without knowing the cost¬†or¬†we'll let the requirements emerge, or¬†the customer doesn't really know what they want, so we'll get started so they can decide along the way, ask how you are going to recognize¬†DONE, before running out of time and money?¬†
How Do We Discover the Needed Capabilities?
Once we've decided that capabilities are in fact the place to start, how are they gathered. Here's the top level set of activities.
Once we have these, we can start to elicit the technical and operational requirements that will fullfill these capabilities.
These requirements can be emergent, they can evolve, they can be elicited incrementally and iteratively. But what ever way to¬†appear they need to have a home. They need a reason for being here. They need to enable a capability to be available to the user.¬†
The PDF version of my new book will be free. Soon!
Now that the writing of my third book is nearing completed (estimated release date of the free PDF version: 3rd week of May) it seems I will have some more time to talk about it.
Tomorrow (Tuesday) I will appear in a Stoos Sparks webinar episode, to discuss remote collaboration, together with Dawna Jones, Lisette Sutherland and Elinor Slomba