archive-nl.com » NL » I » IMPROVEMENT-SERVICES.NL

Total: 128

Choose link from "Titles, links and description words view":

Or switch to "Titles and links view".
  • Rope Management | ImprovemenT
    will be very costly to rectify downstream a dramatic phenomenon we all know too well from the waterfall model for software system development Hence the chain management model has a number of striking disadvantages The transfer moments are predefined in most cases with strict output and input criteria This will not only hamper a swift response to changing circumstances but will largely exclude the advantage of growing insight The end result will comprise the quality flaws and misinterpreted requirements piled up after every stage Late discovery of wrong presumptions could even be a fatal blow for the whole project The collaboration of the parties involved will harbor suspicions against each other resulting in many formal verification moments This control attitude will not only slow down the process but contributes significantly to the total cost of the end product Workers are focussed on their contribution only and don t feel the responsibility for the overall product This limitation of scope will be at the expense of craftsmanship and will reduce the usability of the final deliverable To cut a long story short chain management is not a team sport In a self empowered team the weakest link will be taken care for by all the team members Not the weakest player but the strongest team member will capture the pressure This type of collaboration is not like a chain but has more similarity with a rope all parties are involved from the beginning to delivery of the end result Application of rope management will of course utilize the diversity of skilled workers to a much larger extend Every player knows the overall goal and will therefore be motivated to contribute to the final product Craftsmanship and individual talents will be fully appreciated promoting a high quality end product In contrast with

    Original URL path: http://www.improvement-services.nl/blog/?p=421 (2015-12-05)
    Open archived version from archive

  • Scrum under Siege – Revisited | ImprovemenT
    planet yet First of all the phrase pitfall is replaced by issue As some commenters noticed a list of pitfalls would suggest if you manage to avoid them all you would arrive at the perfect way of doing Scrum Doing Scrum The Right Way assumes an all or nothing scenario to master Scrum and essentially ignores an essential principle of Agile itself Be Adaptable Hence many answers to these kinds of issues are situation specific Triggered by several comments on the original post I have decided to add two additional issues Ineffective handling of impediments A focused removal of impediments is key to success with Scrum It is my experience that especially new Scrum teams are reluctant to call a hindrance an impediment Sometimes I need to point out a few times that anything that slows down the team is by definition an impediment If a 1 day task is in the in progress column for more than 2 days there is an impediment Period Resistance and lack of co operation As depicted in the enclosed picture the arrow points to the surrounding of the Scrum team Of course resistance and lack of co operation within the Scrum team would

    Original URL path: http://www.improvement-services.nl/blog/?p=394 (2015-12-05)
    Open archived version from archive

  • What is ‘Working Software’? | ImprovemenT
    of the implementation Why is complexity important Because the level of complexity is directly related to the effort needed to test the feature Hence when the implementation is unnecessarily complex money has been or will be wasted during testing of the feature The good news is that there is a relatively easy yet solid way to determine the complexity This is the good old cyclomatic number a single ordinal number related to the number of independent branches in the software module The cyclomatic complexity is a reliable indicator for the maintenance effort and quantifies the number of white box tests that are required to obtain sufficient coverage Benchmarking suggests to keep the cyclomatic number of the majority of functions below 10 or 20 But software will work whether the cyclomatic number is 10 100 or even 500 The required test effort and the cost of maintenance are usually not part of the demo And to be honest most stakeholders are not interested either For me this is hard to understand since excessive complexity has a direct negative impact on development and exploitation cost of software The only plausible explanation I have heard so far is that the total cost of ownership will eventually land at someone s else plate Is working software the primary measure of progress I have reason to believe that I belong to a minority when I question the literal interpretation of the phrase working software In a recent conversation Jeff Sutherland made the statement that it is totally unacceptable not to have working software at the end of a sprint Teams that fail to do this are not worthy of trust I agree that working software is an important measure of progress And the strong emphasis on working software is an understandable response to the activities

    Original URL path: http://www.improvement-services.nl/blog/?p=344 (2015-12-05)
    Open archived version from archive

  • Dealing with Last-Minute User Stories | ImprovemenT
    encouraging results At least Scrum did what Scrum will always do it will surface the major inefficiencies and bottlenecks in the current way of working Merciful and quick User stories falling from the sky One important issue that was brought forward by one of the teams during the retrospective was the discontent with the unforeseen addition of new high priority user stories to the product backlog sometimes even during the last day of the running sprint As a consequence the team was confronted frequently with completely new user stories during the sprint planning meeting Especially when realization of the new user story would require a specialty or application of innovative technology the team couldn t give a reliable estimation for the effort involved within such short notice Understandably the team had problems to catch up with their obligations for the upcoming sprint when confronted with complicated user stories that developed out of nowhere Toward a healthy trade off between customer interests and team efficiency Of course I discussed this issue with the product owner together with the team His obvious explanation was the continuous substantial customer pressure Everybody agreed that the customer has priority but I was also under the impression that the product owner made the trade off quite routinely I sensed a blind spot causing the ad hoc and hectic way of working continually fueling itself I explained to him that a boost in efficiency and delivery performance by the team would probably help to lift this weight from his shoulders which at the end would make everybody a lot happier A fruitful compromise the Sprint Forecast Meeting Together we arrived at a compromise half way every running sprint the product owner and the team would sit together for about an hour to discuss the new stuff The

    Original URL path: http://www.improvement-services.nl/blog/?p=305 (2015-12-05)
    Open archived version from archive

  • The defeat of Parkinson’s Law by Scrum | ImprovemenT
    problem and damages the team s ability to meet business needs The cure lies in following agile principles I believe that Parkinson s Law is related to certain psychological factors in the working environment especially lack of trust and respect Given the right circumstances the vast majority of people will create many opportunities to succeed and many situations to collaborate in order to get the job done Trust openness respect and courage are the core values of scrum leading to greater productivity and stakeholder satisfaction than blatant pressure As listed below scrum has many build in mechanisms which not only ignore Parkinson s Law but actually reverse it 1 Focus on tangible features In general Parkinson s Law is lurking when planning is based on stand alone tasks rather than features In scrum the driver for project planning is not a collection of tasks but a backlog with user stories prioritized by the business representative A focus on complete functions to be demoed by the team at the end of the sprint will discourage working on tasks that not contribute to the immediate business value of the deliverables 2 Time boxing with variable scope Within scrum the overall schedule is subdivided into a number of separate time boxes with each part having its own deliverables deadline and budget This approach provides frequent checkpoints and opportunities for corrective action you don t have to wait months for something to be completed only to find out that it s deficient or even obsolete With timeboxing the deadline is fixed but the scope may be reduced This focuses work on the most important tangible deliverables and inhibits the proliferation of less relevant tasks There is no time for extras or unnecessary complexity 3 Teams decides about the workload In Scrum the development team determines how much work can be accomplished in the upcoming sprint Even for unplanned absence it would be legitimate for the team to reduce its original commitment Persisting with the original amount of work despite reduced resources starts a vicious downward spiral of poor quality technical debt and team burn out Bottom line is that you don t force the team to accept more work than can be done The team will ensure that sustainable pace is tuned to available resources and capabilities Some managers see above may suspect that this is an opportunity for Parkinson s Law to kick in and that the team deliberately reserves more time than needed In all the years I m working with Scrum teams in a large variety of domains I have never seen this happen On the contrary especially beginning Scrum teams have the tendency to over commit 4 Teams can re estimate tasks to be done Once the tasks for a sprint are estimated Parkinson s Law may catch up You may argue that the work on the sprint backlog then expands to fill the time available However this is not the case due to the sometimes forgotten opportunity for the

    Original URL path: http://www.improvement-services.nl/blog/?p=242 (2015-12-05)
    Open archived version from archive

  • The Agile Mindset: part of the 21st Century Skillset | ImprovemenT
    work and life in the 21st century These skills are grouped into three major categories Learning and Inno vation Skills which include creativity curiosity imagination critical thinking problem solving communication and collaboration Information Media and Technology Skills which involve effectively using managing and evaluating information from digital technology and communication tools Life and Career Skills which include flexibility and adaptability self direction teamwork appreciation of diversity accountability and leading by influence Striking similarity with the agile skillset It would be forcing an open door to mention the resemblance of these skills with the agile mindset In order to assemble a great Scrum team I guess these would be the personal competences you would be looking for wouldn t it Needless to say that I wholeheartedly welcome this initiative to promote the agile way of thinking and working For me this is also an indication that the agile way of working is not just another hype or methodology but should be seen as part of a much broader response to the plan and control paradigm that predominated our society the last decades As I have experienced personally our education was based on the idée fixe of a makeable world At least

    Original URL path: http://www.improvement-services.nl/blog/?p=214 (2015-12-05)
    Open archived version from archive

  • erikphilippus | ImprovemenT | Page 2
    like in RCS the Product Owner and the Product Backlog with User Stories will have desastreus consequences for the application of the method Apart from an underlined critique with respect to missing Scrum essentials the main question in this Dutch article is the rationale for RCS The reasons for the drastic deviation from Scrum are not provided which in itself raises questions In addition statements like Communication is more complex than software development or Scrum is too much focussed on itself doesn t make it easier to take RCS seriously Please make up your own mind Perhaps you have answers on the question why Scrum in its original and mature form would not be suitable for communication specialists just like Scrum is applied to a large and growing number of other non software domains Posted in Scrum Practices Rope Management Posted on February 28 2014 by erikphilippus Effective collaboration will become one of the most important assets for organizations to become and stay successful in complex dynamic and unpredictable environments The traditional model for the cooperation between and within organizations is based on Supply Chain Management which is in essence a non Agile approach to any business alliance Since all parties involved will deliver their contribution in sequence the chain is only as strong as its weakest link Moreover flaws made in the beginning of the chain will be very costly to rectify downstream a dramatic phenomenon we all know too well from the waterfall model for software system development Hence the chain management model has a number of striking disadvantages The transfer moments are predefined in most cases with strict output and input criteria This will not only hamper a swift response to changing circumstances but will largely exclude the advantage of growing insight The end result will comprise the quality flaws and misinterpreted requirements piled up after every stage Late discovery of wrong presumptions could even be a fatal blow for the whole project The collaboration of the parties involved will harbor suspicions against each other resulting in many formal verification moments This control attitude will not only slow down the process but contributes significantly to the total cost of the end product Workers are focussed on their contribution only and don t feel the responsibility for the overall product This limitation of scope will be at the expense of craftsmanship and will reduce the usability of the final deliverable To cut a long story short chain management is not a team sport In a self empowered team the weakest link will be taken care for by all the team members Not the weakest player but the strongest team member will capture the pressure This type of collaboration is not like a chain but has more similarity with a rope all parties are involved from the beginning to delivery of the end result Application of rope management will of course utilize the diversity of skilled workers to a much larger extend Every player knows the overall goal and will therefore be motivated to contribute to the final product Craftsmanship and individual talents will be fully appreciated promoting a high quality end product In contrast with working in a chain effective and simple solutions for complex problem will emerge within the team Since it is based on the agile mindset rope management will make the chain much stronger than the sum total of the strength of all participants Although rope management may appear as chaotic and confusing to the traditional manager from the first impression I m convinced that it will overcome the chain management model despite its tempting explicitness and clarity This is illustrated by the growing interest in DevOps which is a rope management approach to integrate software development and IT operations Posted in Agile Mindset Scrum under Siege Revisited Posted on September 18 2013 by erikphilippus In an earlier post I summarized a number of threats to Scrum The article was also posted to the Linkedin Certified Scrummaster discussion group Based on the comments I like to make a few extensions Perfect Scrum Not on this planet yet First of all the phrase pitfall is replaced by issue As some commenters noticed a list of pitfalls would suggest if you manage to avoid them all you would arrive at the perfect way of doing Scrum Doing Scrum The Right Way assumes an all or nothing scenario to master Scrum and essentially ignores an essential principle of Agile itself Be Adaptable Hence many answers to these kinds of issues are situation specific Triggered by several comments on the original post I have decided to add two additional issues Ineffective handling of impediments A focused removal of impediments is key to success with Scrum It is my experience that especially new Scrum teams are reluctant to call a hindrance an impediment Sometimes I need to point out a few times that anything that slows down the team is by definition an impediment If a 1 day task is in the in progress column for more than 2 days there is an impediment Period Resistance and lack of co operation As depicted in the enclosed picture the arrow points to the surrounding of the Scrum team Of course resistance and lack of co operation within the Scrum team would be a major issue However it is my experience that in most cases it is a misalignment with the rest of the organization that represents a significant threat Moreover Scrum is not a exclusive party for developers only the whole organization has to adopt and attune to Scrum in order to have the full benefit of Agile way of working Posted in Scrum Practices What is Working Software Posted on September 18 2013 by erikphilippus During the sprint review the realized feature is demoed to the stakeholders and the software runs successfully through the happy path It works exactly as specified and no defects exist So working software is delivered by the team In most cases nobody will look under the bonnet to inspect the implementation of the feature it is working right Working software over comprehensive documentation According to the agile manifesto working software has more value than comprehensive documentation I have always interpreted this statement as make sure that you collect relevant feedback on critical parts of the system at an early stage to allow for timely adjustments In other words stop writing bulky documents in your submarine only to find out the world has changed after you have surfaced As an agile trainer and coach I have always provided this annotation when discussing the agile manifesto just to make sure that the phrase working software would not be misinterpreted by developers During my 35 years in the software industry I just have witnessed too many projects that were jeopardized or even failed by an exclusive focus on functionality Experience learns that ignoring vital architectural principles and neglecting crucial software quality demands can have disastrous consequences Typically these flaws are not immediately visible but will surface downstream the project or after fielding the software system Of course it makes sense to bring to the team the focus of working software instead of writing dust collecting documents for months Although the primary goal of software development is to create software it would be an unfortunate mistake to assume that working software is the only thing that matters Low complexity the forgotten part of the business value of a feature To underline the statement that there is more than just functionality I would like to present an aspect of business value that is not directly visible the complexity of the implementation Why is complexity important Because the level of complexity is directly related to the effort needed to test the feature Hence when the implementation is unnecessarily complex money has been or will be wasted during testing of the feature The good news is that there is a relatively easy yet solid way to determine the complexity This is the good old cyclomatic number a single ordinal number related to the number of independent branches in the software module The cyclomatic complexity is a reliable indicator for the maintenance effort and quantifies the number of white box tests that are required to obtain sufficient coverage Benchmarking suggests to keep the cyclomatic number of the majority of functions below 10 or 20 But software will work whether the cyclomatic number is 10 100 or even 500 The required test effort and the cost of maintenance are usually not part of the demo And to be honest most stakeholders are not interested either For me this is hard to understand since excessive complexity has a direct negative impact on development and exploitation cost of software The only plausible explanation I have heard so far is that the total cost of ownership will eventually land at someone s else plate Is working software the primary measure of progress I have reason to believe that I belong to a minority when I question the literal interpretation of the phrase working software In a recent conversation Jeff Sutherland made the statement that it is totally unacceptable not to have working software at the end of a sprint Teams that fail to do this are not worthy of trust I agree that working software is an important measure of progress And the strong emphasis on working software is an understandable response to the activities of the ivory tower architect and to prevent the infamous BDUF But these kind of ardent and sometimes even dogmatic statements cannot hide the fact that agile does not have a good answer for how to handle service level requirements all the ilities including the aforementioned complexity If working software is unmaintainable would that be still a reliable measure of progress On the other hand agile acknowledges the importance of quality software has to be high quality and quality is not negotiable In the Scrum Guide however the word quality is only mentioned three times in a completely unspecified manner And I also found this cliffhanger if you have a good definition of done the quality won t suffer Software quality as part of the definition of done The question remains what exactly is meant by quality and how do you ensure it If asked most developers will provide an outline of agile practices that will ensure the quality of their code such as pair work peer reviews refactoring test first continuous integration etc Although applaudable approaches the quality can only be assured when quantified by actual measurement The numbers will tell the tale So my point of departure would be to specify the relevant quality demands as part of the default definition of done It is up to the team how to arrive at the requested quality level At sprint review the team has to demonstrate that software functions not only work but also adhere to the agreed upon quality specification The measurement of quality is in general not a big deal e g most development environments are capable to automatically measure the cyclomatic complexity when software is checked in Agile Design Upfront A last remark from an old hand you can t hack quality in The foundation for quality is in the overall design not in individual user stories If architecture is perceived as something organic which will emerge just in time within self organizing teams quality will pay the price Posted in Scrum Practices Dealing with Last Minute User Stories Posted on September 3 2013 by erikphilippus About 2 years ago I was in Paris for some time to help a software development company to introduce and roll out Scrum Apart from the cultural differences even as a liberal Dutch guy I was surprised by the intimacy of the salutations each morning a major challenge was the hectic and feverish working atmosphere due to the volatility of market demands in their domain Consequently continuous task switching and changing priorities of requirements appeared to be the order of the day Massive overtime also And grumbling too in French Anyway with some trial and error the first 2 week sprints were completed with mainly encouraging results At least Scrum did what Scrum will always do it will surface the major inefficiencies and bottlenecks in the current way of working Merciful and quick User stories falling from the sky One important issue that was brought forward by one of the teams during the retrospective was the discontent with the unforeseen addition of new high priority user stories to the product backlog sometimes even during the last day of the running sprint As a consequence the team was confronted frequently with completely new user stories during the sprint planning meeting Especially when realization of the new user story would require a specialty or application of innovative technology the team couldn t give a reliable estimation for the effort involved within such short notice Understandably the team had problems to catch up with their obligations for the upcoming sprint when confronted with complicated user stories that developed out of nowhere Toward a healthy trade off between customer interests and team efficiency Of course I discussed this issue with the product owner together with the team His obvious explanation was the continuous substantial customer pressure Everybody agreed that the customer has priority but I was also under the impression that the product owner made the trade off quite routinely I sensed a blind spot causing the ad hoc and hectic way of working continually fueling itself I explained to him that a boost in efficiency and delivery performance by the team would probably help to lift this weight from his shoulders which at the end would make everybody a lot happier A fruitful compromise the Sprint Forecast Meeting Together we arrived at a compromise half way every running sprint the product owner and the team would sit together for about an hour to discuss the new stuff The product owner would elucidate recent additions allowing team members to get their mind around new user stories to be realized during the next sprint This meeting was formalized and added to the arsenal of regular scrum meetings Already during the preparation of the next sprint the usefulness of the sprint forecast meeting was clearly visible Afterwards the use of the sprint forecast meeting has proven itself many times Retrospective benefits Apart from the positive effect on the overall performance of the scrum team this provides also a clear picture of the benefit of the sprint retrospective As I have observed several times the retrospective is among the first artifacts that are forgotten or eliminated from scrum Hopefully I have illustrated here the shortsightedness of such an unfortunate intervention Posted in Scrum Practices The defeat of Parkinson s Law by Scrum Posted on August 29 2013 by erikphilippus How long do you think it takes to paint the Eiffel Tower Based on historic data a team of painters would need circa 200 days to finish the job What if they would have 250 days or 175 days instead of 200 The answer to each of these questions may be the same it is not unlikely that they actually would need 250 or 175 days This phenomenon is known as Parkinson s Law Work expands to fill the time available for its completion This interesting statement was made by Cyril Northcote Parkinson a British historian and author in 1955 Parkinson s Law is based on observations rather than on scientific evidence Nevertheless many managers strongly believe in Parkinson s Law in the sense that they try to cram more work into a given time period than can be done They schedule aggressively in an attempt to squeeze blood from stones under the pretext under pressure everything will become fluid this is a literal translation of a Dutch proverb mostly used by old school managers The underlying idea is that everybody will be kept busy but the actual result is that the target completion date cannot be met there s simply too much work to do There are serious negative repercussions from this short sighted interpretation of Parkinson s Law When a team is under heavy pressure to over deliver you can be sure that they will cut corners The first thing that will suffer the consequences is the quality of the work leading to massive technical debt Unfortunately the immense cost of non quality is still the best kept secret in our profession but that s another topic Moreover team members will react by padding their task estimates which only masks the problem and damages the team s ability to meet business needs The cure lies in following agile principles I believe that Parkinson s Law is related to certain psychological factors in the working environment especially lack of trust and respect Given the right circumstances the vast majority of people will create many opportunities to succeed and many situations to collaborate in order to get the job done Trust openness respect and courage are the core values of scrum leading to greater productivity and stakeholder satisfaction than blatant pressure As listed below scrum has many build in mechanisms which not only ignore Parkinson s Law but actually reverse it 1 Focus on tangible features In general Parkinson s Law is lurking when planning is based on stand alone tasks rather than features In scrum the driver for project planning is not a collection of tasks but a backlog with user stories prioritized by the business representative A focus on complete functions to be demoed by the team at the end of the sprint will discourage working on tasks that not contribute to the immediate business value of the deliverables 2 Time boxing with variable scope Within scrum the overall schedule is subdivided into a number of separate time boxes with each part having its own deliverables deadline and budget This approach provides frequent checkpoints and opportunities for corrective action you don t have to wait months for something

    Original URL path: http://www.improvement-services.nl/blog/?author=1&paged=2 (2015-12-05)
    Open archived version from archive

  • Agile Mindset | ImprovemenT | Page 2
    Confucian doctrine is based on the belief that from the right name the right reality should follow rather than assuming as we do in the West that names reflect reality During the Chinese Cultural Revolution the Red Guards destroyed all public signs which contained any reference to the reactionary bourgeois past New street signs with revolutionary names were mounted in many streets in Chinese cities These actions were fully in keeping with the rules based on the Rectification of Names Therefore the renaming imposed by the Red Guards not only left an age old feature of Chinese culture intact but actually re emphasized it First order change The renaming of street signs is a classic example of a so called first order change Likewise first order change in a church could mean changing the hours for services renovating the building choosing new choir robes etc First order change involves any kind of change that changes an existing process from one form to another form but leaves the original purpose and standard in tact It is a change that is consistent with prevailing values and norms meets with general agreement and can be implemented using people s existing knowledge and skills Second order change Second order change is a disruptive change which challenges the existing culture and organizational paradigm including current expertise and competencies A change becomes second order when it requires people to learn new approaches or it conflicts with prevailing values and norms Second order changes require leaders to work far more deeply with people in the organization The eventual outcome of such a paradigm change is a transformed or renewed organization Nothing endures but change Heraclitis 535 BC 475 BC I believe that the migration to an agile way of working involves a paradigm shift It challenges the traditional belief that a project will be successful only when you re able to predict its progress and outcome right from the start Hence the agile mindset acknowledges change as a fact of life and provides skills that allow for adaptation rather than prediction So second order change is what we should mean when we talk about transformational change from a fixed mindset toward an agile mindset As discussed in a previous post an agile mind is not something you acquire I think it is best described as a rediscovery I might be addressing different ways to evoke the agile mind in future posts please find below two invitations to leave the beaten path by means of an appetizer Re evaluate critical feedback The litmus test of a changing mindset is the shift of the internal dialogue The fixed mindset creates an internal monologue that is focused on judging This means I m a loser This means I m a better person than they are While the agile mindset is indeed sensitive to positive and negative information it is attuned to the implications for learning and constructive action What can I learn from this How can I improve In other words a person with an agile mindset has fallen in love with feedback You are invited to perceive honest constructive feedback as a rare and precious gift especially when they are critical or painful Co create a place where is is safe to fail The agile mindset promotes learning at every opportunity through both success and failure However to be able to learn from failure we must feel safe enough to fail Hence we need to find ways of creating safety as a platform for the adoption of the agile mindset Within this context safety is multi faceted and shared responsibility Help to create safety for the developers the managers the organization as well as for the customer You are invited to develop a gentle attitude toward failure both by yourself and others Posted in Agile Mindset Can you acquire an Agile Mindset Posted on August 18 2013 by erikphilippus The resilience of pine cones Years ago I travelled in the beautiful Yellowstone National Park One night we were woken by a park superintendant since there was a huge forest fire nearby There was no immediate danger so I walked with the supervisor to watch the impressive fire on the other side of the lake He told me a quite interesting story about the pine trees It appears that the pines in Yellowstone are a fire adapted species They have two types of pine cones One is like most other pine trees it opens up as it matures and releases its seeds But they also have another type of cone which can remain on the tree for many years It is glued shut with a waxy coating It takes the heat of a fire to melt off the resin so that the cone can open and release its seeds naturally reseeding the burned area Why am I telling this story Because I think it s a powerful metaphor for the adoption of an agile mindset Please allow me to explain Unknown Unloved When a person is challenged his or her intuitive response is to trust previous experience and to apply learnt behavior This attitude feels comfortable and is perceived as less dangerous than experimenting with new behavior Especially in insecure situations we have a natural tendency to apply proven technology Of course this is completely understandable from an evolutionary point of view But what happens when we re provoked to adopt the agile mindset Dominant learning style The agile mindset comprises competences that are related to right brain skills such as intuition creativity spontaneity etc In my view the agile mindset requires the two sides of the brain work in tandem to enable the owner to function as a well rounded personality effectively utilizing both verbal and nonverbal forms of intellect However as indicated in my previous post we live in a society that is influenced by the traditional dominance of the left brain modes of thought which includes analysis logic reasoning etc According to Nobel laureate Roger Sperry modern

    Original URL path: http://www.improvement-services.nl/blog/?cat=8&paged=2 (2015-12-05)
    Open archived version from archive



  •