Lean PPM – step 13: Documentation consumer type 3: SW engineers, subject matter experts, technical experts

SW (SoftWare) engineers and experts do not have an interest in documentation. SW engineers as well as experts have an interest in the final solution, especially in a solution that fulfils the needs of the business or users. Unluckily many organizations prevent successfully that SW engineers communicate with the subject matter experts. That’s exactly what agile and lean processes try to address – to tear down communication barriers to the minimum.

SW engineers working in software development have an elaborated set of documentation means built in into Scrum. Epics, user stories, source code, acceptance tests, prototypes, a technical environment support the design, implementation, build, test and deploy cycle with versioning and release management (at least hopefully – if not, well you know now where you have aspects to improve. To be straight – this is where we at digitec Galaxus as well do have room for improvement).

Subject matter experts (example: actuaries in reinsurances), technical experts (example: hearing experts in the development of hearing devices) all have very special tools and environments. Actuaries often use Excel. I have seen monstrous solutions built from man dependent Excel workbooks driving business critical risk management solutions implemented by actuaries in reinsurances. Nobody else except the creator understood these complicate solutions. I once had the job to migrate such a solution into a scaling Java solution – what a nightmare. The most important individuals in this project were Prolbares (see above) that translated the requirements of the actuaries, hidden in the Excel beast, into something executive managers (“why is it so expensive to rewrite an Excel worksheet in Java??!!”) and SW engineers (“as a reinsurance key accountant I want to …”) understood.

Point is: Between SW engineers and experts (and managers) there is a distance that Prolbares try to reduce or even to eliminate - with distance defined as well as physical distance as mindset distance. In true agile environments elimination is the aspired state. What is important in respect of documentation: SW engineers and experts both have their specific way to deal with documentation.

With this requirements of SW engineers and experts for documentation are:

• The very specific type of work requires the support by very specific processes and tools (Excel for actuaries; epics, user stories, acceptance tests, source code and a build/deploy environment for SW engineers).
• The least amount of documentation is the best – no matter of the documentation is required as information source to start my work or as information sink required by anybody else in the organization.
• SW engineers and experts are not interested in documentation. They are interested to get their job done and to create results and to deliver.

Maybe I am a bit hard to list only these three requirements – but I am not unhappy with these interests of SW engineers and experts. I am always happy if people have an interest to deliver. It is the responsibility of the (leadership part of the) management that SW engineers and experts want to deliver something the organization benefits from.

Lean PPM – step 12: Documentation consumer type 2: project leads, business analysts, (requirements and software) engineers, or likewise folks

Prolbares (= project leads, business analyst and requirements engineers) express a lot more needs in documentation. Prolbares are around on all abstraction levels of requirements (see the requirements abstraction model RAM by Tony Gorschek and Claas Wohlin). Prolbares work from business goals, high level business processes down to tiny technical details. Prolbares are involved in the full lifecycle of designing and implementing desired changes (see “The life cycle of an initiative”). In the design process of a change they are responsible to elicitate, design, communicate, consolidate and confirm requirements of a change. In this context “change” is anything from a small continuous improvement in an existing system to a discontinuous innovation in form of a new product or service.

In respect if documentation, Prolbares are like chameleons. Some like to write novels, some hate writing any documentation, some like modeling, some prefer to paint pictures; some are more user experience oriented, some rather are technicians; some feel comfortable on the abstract levels of requirements like business goals, processes and features, some love tiny details…

Naturally the requirements of Prolbares for documentation are magnifold:

• In the initial part of the lifecycle of a change they have an interest about the current situation. Source code and acceptance tests are a good source of the current state of a piece of software – but unluckily, as mentioned in my last blog – this is often only part of the truth. Manual and organizational procedures do not have a source code. Documentation could be treated as the source code of a manual and organizational procedure.
• Prolbares consume and create many artifacts and share these with her team(s) like meeting notes, requirements specifications, prototypes, decisions, technical description, whatever is needed in the refinement of intiatives, epics and user stories.  Most of this is waste when the change is done. Most of it, but not all. Some pieces out of this huge amount of information is valuable for the first step – to remind on the current situation any time in the future when the next change is in the road.
• Because of the chameleon alike nature, finding anything that suits all Prolbares is like finding the holy grail. So we had to find options that satisfy the majority of the Prolbares.

Prolbares are hard to place within an organization. Reason is that Prolbares typically are not full time members in any team. If integrated into the IT organization (i.e. Scrum teams) they spent 50% of their time with stakeholders and business. If integrated into business, they spent 50% of their time with IT, and – if not – they loose contact to IT, what results in defects in the quality of requirements (conversation, confirmation, feedback loops). At digitec Galaxus business analysts are our Product Owners in the Scrum teams. 

If Prolbares act positive in an organization, they care for the whole (optimizing the system and not preferring a specific department). They act as mediator, moderator, translator between business and IT to balance needs and wishes. They support ideas to become visible; mature ideas into change projects and finally towards real implemented (continuous or discontinuous) innovations together with all involved departments, subject matter experts, external partners, management and whoever has stakes in the change.

This is the reason Prolbares typically have an interest on a higher amount of documentation than all other involved persons and job profiles in an organization. A good Prolbare want to understand the problem under discussion herself. So the write a part of the documentation for themselves. Then they use documented requirements to solve different views and conflicts between stakeholders in the design phase of a change project. Additional they try to create a documentation that best suites all stakeholder in documentation (from executive managers to engineers and technical experts). 

Unluckily often the documentation policies, structures and tools in an organization are not defined in a way to support Prolbares to ease their job. The results we encounter in many organizations. To many documentation; documentation that does not satisfy the needs of consumers; documentation that does not allow to search and find the requested piece of information to successfully work on a piece of work.

In my personal perception to identify an appropriate structure and tool support for this relevant part of documentation is the most critical point. In fact this is the part to support the activities of business analysis, requirements engineering and design in respect of the creation of required documentation. 

Lean PPM – step 11: Documentation consumer type 1: executive managers

Executive managers do not have a lot of time.  They are keen people…

I am sorry to break your flow of reading at this point for a short discussion about executive managers, middle management and systems that doom people to stagnation.

---Discussion about executive managers and locking systems

In my experience over the last 30 years, in most cases executive managers are really excellent people. “Indifferent” managers are mainly locked in the middle management – but not because the individuals are inaptly. Rather middle management is doomed by the system to work in an indifferent way. To change the system, I personally see under the responsibility of executive management. This is where I set my question mark. Maybe executive managers are doomed by the system as well. I encounter a real difference whether executive managers or owners are in the driver seat of an organization. Maybe managers better fulfil quarterly financial reports to satisfy shareholders. I personally encounter that shareholder profit in owner driven organizations is not that high as in manager driven ones, but in the long-term these organizations are more robust, show a sustainable growth, more creativity and innovation and you find a higher ratio of intrinsic motivates employees.

---End of discussion - back to the documentation thread

Executive managers read one page. Executive managers want to see things to progress or the reason why things get stuck. Executive managers take decisions and have an interest to receive appropriate information to take a decision. Executive managers have an interest to reach goals; in the big picture; in the change roadmap; in the alignment of the change roadmap with strategy; in financial factors. Executive managers lose interest very fast if they feel wasting their time. Sometime executive managers have an interest on tiny details – but in this case no documentation helps. In this case an executive manager best is informed face by face by a competent person.

So the requirements of executive managers regarding documentation are:

• Easy to find – best presented in a personal and (automatically) daily used dashboard.
• One Page information (scrolling is waste of time and inadequate).
• Executive managers pull information - except something might fail. In this case an executive manager expects a push about a potential failure so that she can take preventive actions.
• Executive managers do not like unpredictable negative incidents. 
• For sure executive manager like unpredictable success messages.
• As a subject matter experts: You can be sure that an executive manager has never read the detailed report about risks or delays until the issues bubbles up because of some accident
• Executive managers want to see the name of the competent person behind a project/issue/action in case she requires a face2face to receive tiny details (in case of an accident)

There is on important fact to remind: Executive managers typically are no team members. They represent the culture and visionary capital of the organization and own the additional responsibility of a catalyst: if a catalyst works well, the organization works clean and powerful; if a catalyst fails, the organizations state of health drops. Because of this face2face information is far more important as documentation. Documentation rather is used as form of reporting to detect devations from the expected path. The real communication for steering should be done personally in 1:1 or other forms of direct communication. It is a matter of interpretation, shared knowledge and trust.

At least this is my experience aligned with the following principle in the agile manifesto: The most efficient and effective method of conveying information to and within a development team is face-to-face conversation. And the head of the development team of a company is the executive management.

Lean PPM – step 10: Consumers of documentation and their needs

In my last blog I pointed out why there is a need for documentation. What we at digitec Galaxus figured out during the last year working with our Lean PPM system was:

• Who concrete are the target reader of a type of information
• What abstraction level and format does a target reader prefer to use
• What tools and environment does a target reader prefer to use
• What tools and elements do we already use in our Lean PPM that offer options for documentation

Based in these findings we now agreed to establish some rules how we want to deal with the topic documentation. I guess in many organizations the situation is similar, so hopefully my blogs about documentation are useful.

At this point I have to say this is nothing new about documentation in any way. Already before agile and lean these findings were well known. The very basic concepts of documentation are:

• Create a documentation only if there is a consumer that gets value out it
• The documentation must meet the needs of a consumer in respect of amount and abstraction level of information, the format and the tool to use
• If a user searches an information within the documentation, the documentation must support a structure and search so that the consumer will find the information easy and fast.

Sources that address these basic concepts are for example the International Requirements Engineering Board IREB e.V. in its foundation certification, the International Institute for Business Analysis IIBA with its BaBOK, or the differentiation between a product repository and a project repository as recommended by the International Software Product Association ISPMA.

Instead of listening to the needs and requirements of the human sources and sinks of documentation many organizations instead go primarily for standardization and the satisfaction of compliance constraints. From my experience organization should care to develop good documentation practices for the workforce with first priority and with second priority to be compliant to external constraints. In my experience it is always possible to transfer a documentation that follows good documentation practices into a format that as well satisfies external compliance constraints.

Funny that so many organizations and companies disregard the basic concepts as listed above. From my experience the overwhelming compulsion to create standards and satisfy compliance constraints outreaches the objective consideration that an unbalanced harmonization ends up in more drawbacks than benefits. Especially the demonic one-fits-all thinking that still creeps through the management floors – as well in respect of documentation…

A year before today we created documentation at digitec Galaxus following good practices only partially. We used epics and user stories in software development, we tried to avoid exhausting documentation in the requirements and design phase – but we did not follow good practices that support all types of consumers of our documentation. In the last year while establishing our Lean PPM, we discovered basically three different types of consumers. I use the terminology of digitec Galaxus as described my blogs “The value stream of the digitec lean portfolio Kanban system”, “The life cycle of an initiative” and “about project leads and business analysts...”. There is one blog dedicated to every consumer type. 

Lean PPM step 9: Working Software over Comprehensive Documentation

I promised to talk about documentation - quite a while ago, I know - sorry...

Documentation is a very special topics to talk about. I discovered, I have to write more than one blog to cover this topis at least a bit. so lets start:

Just to remember – in 2001 a group of agile individuals phrased the agile manifesto and the twelve principles of agile software that are relevant as ever. With respect of this blog discussion about documentation in our agile & lean world I would like to repeat the interesting statements.

Agile Manifesto

• Working software over comprehensive documentation

Twelve Principles of Agile Software

• Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.
• Business people and developers must work together daily throughout the project.
• The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
• Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
• Simplicity--the art of maximizing the amount of work not done--is essential.

Just to point out: The other statements are as relevant. This subset is chosen in respect of the discussion in this blog.

In an agile & lean organization a core attribute is the continuous flow of development and improvement. An important impact is that many things are “in progress” at different level of maturity. As well many things are “done” and in operative use, like a deployed feature in our online-shop or erp-system.

This is where documentation comes into place. Core questions are: Who needs a documentation? What is the benefit of a documentation? To answer these questions, I present some typical scenarios out of our company

Scenario 1: The checkout process requires a change because of a new feature

Imagine we want to add a new feature like a new delivery option in our online-shop checkout process. The checkout process is a complex business process with many scenarios, dependencies, decisions and business rules behind. The working software unluckily is not a sufficient information source to change this complex process. To remind ourselves on all the decisions, business rules and compliance regulations is important before we change this process. As business people from all departments have stakes in this process (accounting, logistics, product management) source code is for sure the only truth of what is implemented, but for sure not best suited for the business people. So there is a need for some form of documentation beside the source code. Let’s phrase his need as a user story: “As a business reader I want to remind myself based on an easy to search, read and understand documentation what we decided that last time we worked on the checkout process.” Additional, as soon as the new checkout process is implemented the delivery process is changed as well leading to changes in operational process in logistics. This requires that we rollout the operational changes and educate our staff members in logistics how to deal with the new process. Therefore, we need some documentation as well.

Scenario 2: We want to rewrite the ranking algorithm of our products

Imagine we discovered that the ranking of products in our online-shop does not meet the expectations of you as a user searching for products. Ranking of products is a complicated (not a complex) algorithm. Many influencing factors determine the rank of a product. You might imagine some of them like: number of visits, numbers of sales in total, number of sales during a certain period, number of recommendations of customers who bought an article of this product…and some more factors. All these factor go into an algorithm. You can imagine that this algorithm is as complicated and secret as the ranking algorithm of Google in their search engine. In fact is kind of a similar problem. To nail this algorithm done more than one session with the right person on board (head marketing, head engineering, product managers, software engineers, …) is necessary. The outcome of these meetings in the end is kind of a decision table that lists the factors and the weight and influence of each factor in the algorithm. An excel table would fit – but unluckily you cannot discuss on base of an Excel table with a product manager for toys or living accessoires. To summarize: The user story to implement might be easy: As a user I want the products in the online-shop ranked in a way so that I find interesting offerings fast and at top on first view. The requiremrent engineering process to elicitate and specify the algorithm needs documentation in some form – as preparation, as discussion base, as outcome for implementation and test (algorithm, acceptance criteria, test data, …).  And at the time this new algorithm is implemented maybe we want to change it in six months again. Then scenario 1 comes into play.

I hope these two scenarios give you an insight why even in agile development documentation beside the source code is required in some form. Still we all are convinced that the best documentation is the one never written and we try to share information as far as possible by direct face to face communication. We encountered that this is unluckily not sufficient. So we strive to create just that minimum amount of documentation for readers and target groups that is sufficient to follow a sustainable path of development and improvement in our documentation.

Let’s see in some additional blogs what our idea about an agile documentation is – at least what we hope will meet our needs and deliver benefit. We are still on the road to establish a good agile documentation; we already found some good techniques and tools, but we still have lots of room for improvement.

The Swiss Agile Leaders Retrospective

If you never heard about the Swiss Agile Leaders Circle (SALC) – don’t worry.

SALC that is a bunch of individuals (Klaus, Line, Mischa, Peter and myself) out of the agile scene in Switzerland. Although everybody of us has a quite different history and job we share the common mindset and conviction. We share the vision that all these ideas around agile, lean, management 3.0 and so on support the development of organizations in a positive way. Thereby we define positive as: competing successfully in their market and offering a work environment where employees are intrinsic motivated and tell you that is fun to work.

Well, so far so good, and now?

We founded the SALC to share our experiences; and to share our experiences with others; and – in the best case – to seed a community of people that share their experiences on a voluntary base without our active engagement in any way.

To share our experiences is easy. We meet from time to time and have regularly skype session. As well we are present at events. This covers a part of our vision.

To share experiences with others is not that easy. What we did was driving community events like the Agile Unconference that took place Nov 4 2015 or workshops related to a specific topic. We organize these events, invite interested persons and hope there is any interest. Well, the Agile Unconference is a success and fun for us – although it is a lot of work us in preparation. Unluckily, we are not that happy with the workshop format. It is a tremendous piece of work to organize a workshop. The fun on our side was low and we are not that happy with the results.

Time to run a Retrospective…

There is our Retrospective: An image, painted on a piece of paper as we run through our retrospective in the West Park Coffee, 2nd floor feed with Latte Macchiato and Espresso (we needed two rounds of coffee…).

Image of our SALC Retrospective

What we found out: our vision is still valid. We are still convinced that all these ideas around agile, lean, management 3.0 and more develop organizations and companies in a positive way (see above).

We discovered as well that our goals to reach this vision as still to share between us, with everybody who likes to share – and to seed a community that shares our vision.

We discovered as well that the success of the Agile Unconference is that convincing for us that we go for a next run Thu 3 Nov 2016 at the SIX Swiss Exchange, ConventionPoint, Zürich.

We discovered that we are unhappy with the workshops as we run it today. Although we get a positive feedback from one or the other attendee, this format of sharing experience is a bit like pulling teeth. So we decided not to run any workshops in this way anymore.

So we did some brainstorming and decided to run some experiments. Why not acting kind of an agile / lean think tank? We could work with somebody, some organization – on the other hand while working with these individuals we can learn ourselves just the same.

Let’s run a limited experiment. We offer some individuals and organizations half a day or a day for working together on whatever problem or context under discussion there might be – with the prerequisite that is related to our vision and experience. There is no fixed agenda, no fixed topics; it will not be an educational event or training.

Ideally during such a think tank event we all together identify alternatives and options that might work to address the challenges in the identified problem space of the individual and organization. In the worst case we spend an intensive time with each other with the insight that even with the joint effort of engaged persons we were not able to find options how to improve. In the latter case it might be a good idea to rethink the whole scenario…

As you see on the image, we set ourselves three dates for just an experiment: 29 Jan 2016, 11 Mar 2016 and 27 May 2016. We are happy that we found as well a first chance to run an experiment…we will write a blog to give you feedback of the outcome

Lean PPM step 8: about project leads and business analysts...

In some of blogs I mentioned that our organization knows the job position of project lead and business analyst. Especially the job position of a project lead may sound strange in a lean and agile organization without projects. Actually we never discussed these names, we just reused job position names that were around. The names existed when I joined Digitec Galaxus. Nevertheless names for job positions matter. The reason is that everybody in an organization assigns a set of responsibilities with these names. Everybody knows what to expect from a person acting in the job position of X.

Unluckily job position names can as well lead to misunderstandings. In my experience only a part of the persons in an organization are able to distinct between a job position and a role. This sometime puzzles persons if two persons with different job titles act in the same role, for example in the role of a business analyst. In our organization for example persons in the job positions business analyst, project lead, erp specialist and software engineer are regularly acting in this role. And it does not help that the name of the job position is identical to the role name. A typical question is “What, now a project leads does some part of the business analysis, I thought this is done by our business analysts?!” The more interesting point is: where is the difference, what are the responsibilities that are unique to a job position. You have to communicate rather these “unique owned” responsibilities within your organization. This fosters persons to discover the responsibilities of a job position and to receive support fast in case they have a request for this special responsibility.

Now, to discuss the job positions of project lead and business analyst it is interesting to look at the roles and responsibilities of the job positions. What is the common set and what are the “unique owned” responsibilities.

Just to remind to our SAFe like system working with initiatives and fastlane. Initiatives implement desired changes derived from our strategy or based on a demand coming from a department. Larger changes, like building up a new logistic center, introducing a standard software for X are decomposed into a set of initiatives and called a theme. Small software system related changes go through the fastlane channel from departments to engineering. Every department owns its own Kanban board managing its own changes and demand and there is one single organization wide Kanban board holding the initiatives (in SAFe called business and architectural epics).

Now, let’s see what the “unique owned” responsibilities of project leads and business analysts are. And just a word regarding “unique owned”. Our interpretation of owned is that this team of persons in the job position of X care to develop the responsibility in collaboration and communication with the rest of the organization that is involved in these activities. There is no “shut up – that’s the way to do it”. It is rather the way of “this is our recommended proposal for a standard method, technique, procedure or process. A common agreed and accepted standard proceeding will help us to be more effective and efficient. Let’s try to do it this way. In case we can improve it, based on our feedback, we will do so. Please give us feedback”. In the change process of our methodologies we established as well an experiment, inspect and adapt process. Luckily this is welcome and accepted by the majority of persons.

The core responsibilities of a business analyst are:

• Business analysts are the experts for our business processes – best in an end2end view. Together with the subject matter experts (we call them erp specialists, erp stands for our self-developed “enterprise resource planning” system) they take the responsibility to identify, develop and optimize the business processes.
• Business analysts help the departments to improve in alignment with other departments – as a business process typically crosses more than one department. They help the departments to develop ideas for improvements and mature these ideas into initiatives and fastlane issues. 
• In the context of initiatives they support the development of the user stories in collaboration with software engineers, usability experts and with the users working with a new process or a new system. They act in the responsibility of a Scrum product owner for the Scrum teams. In this context they work very close with project leads on definition of goals for initiatives and the measures to reach these goals. This collaboration is part of the alignment between initiatives and product backlogs of the Scrum teams.
• Business analysts care for that changes flow back into the organization. They take the responsibility of end2end tests together with the departments, with engineering and with project leads. Business analysts are an essential part in quality assurance of our business processes and systems.
• Business analysts are responsible for the way we build up an appropriate documentation of our business processes (the business process management process J). We just decided to document our business processes with BPMN. As our systems, processes and the number of involved persons increased over the time (and still are increasing) we have the need for a lean, easy to understand, read and to maintain BPMN documentation. Documentation is worth another blog… J.

The core responsibilities of project leads are:

• The innovation process, i.e. the way departments work with their Kanban system developing ideas for initiatives and fastlane issues. Project leads support the departments as (innovation) process coach.
• The portfolio management process around initiatives including definition what an initiatives represents, how to manage and document an initiative within our supporting software systems like Atlassian Jira and Confluence.
• Project leads overall are responsible to drive the implementation of our strategy working with and developing our roadmap. They care for and remind that initiatives are developed, the breakdown of themes into initiatives, that decision are prepared and taken by the executive team. They ongoing develop the roadmap together with the executive team.
• Together with business analysts, project leads they care for lean goals of initiatives and the identification of measures to reach the goals of initiatives. We try to treat every single initiative as a MVP (minimal viable product) to reach the goals of the initiative. They care for that a review is done in the closure of an initiative against the goals. They care for that learnings flow back into the organization, whatever learning that may be.
• Project leads are responsible to collect the information and feedback from all participants in the demand – capacity game, so that the overall system is not overloaded and the system is balanced and healthy. This includes the preparation and proposals for prioritization of initiatives for the innovation board meetings.

And finally what is common to project leads and business analysts:

• The task of business analysis and requirements engineering is shared. All business analysts and project lead know our business processes very well. This sharing lead to some discussion until we found our common understanding (at least I believe by now we found an agreement as the discussions went down and we have a lot of coffee and fun together). In general business analysts may have a bit a more detailed functional knowledge and project leads care a bit more for the inter-department and roadmap-alignment side of business analysis. But for some initiatives a business analyst may be in the lead, fulfilling everything a project lead does; in some initiatives a project lead does nearly all of the business analysis. But this is OK and accepted.
• We both work with departments to develop new ideas for initiatives and fastlane issues. While projects leads take more the role of a (innovation) process coach and support the departments to life and adapt the process to the special needs of the department without leaving agreed common mechanisms like the two demand channels fastlane and initiative, business analyst support more on the business process side to develop and improve the business processes. But as well persons in both job positions are able to act vice versa.
• Many skills and experiences are shared in our teams. This is the lean and agile way of project management, business analysis, requirements engineering, acceptance testing, stakeholder management – many disciplines you may find in a project management, business analysis or requirements engineering book. We even share our training and education events and care for that we improve our skills on a common ground.

Reading these three bullet lists you may now ask yourself why we distinct the job positions project lead and business analyst. To be frank: This is a historical reason and the status quo is satisfying and currently works for us. 

Other solutions to implement a working system are possible. For example Craig Larman and Bass Vode in their LeSS framework recommend to establish groups of competences, i.e. the testing group or the architecture group. These groups are not organizational groups, these are members of (organizational) teams that share a common competence. Jurgen Appelo comes up with a similar proposal he names guilds. A guild is a group of persons that share competences and skills and develop these competences and skills for the benefit of the organization. 

We at Digitec Galaxus have a mixture. We have “guilds” for example the erp (= enterprise resource planning system) guild or the architecture guild. For business analysis and project leads we have teams as part of the organization. Both mechanisms have the goal to develop competences and skills. Potentially we could as well integrate project leads and business analysts into the other organizational units, but why should we. It would only be a re-organization. 

As the current system is understood by everybody and there is currently no need for a change, we leave it as it is. Re-organizations are always something people are a bit afraid of, because personal threads and fears pop up with re-organizations. Maybe any time in the future we discover that this construct can be improved for some reasons. Well, then we will change it. Maybe any time in the future our organization is that flexible and transparent to every single employee that re-organization rather carries the attributes of new chances and interesting new responsibilities instead of threads and fears.