Organizational Mindfulness - Report Example

? Organizational Mindfulness By Organizational Mindfulness Introduction Mindfulness refers to the utilization of humancognition to solve both organizational and individual problems (Weick and Sutcliffe, 2001). This does not, however, mean that the best solution will result from a mindful response; instead, it means that an organization will be able to pick a solution from a list of options. Therefore, approaches based on mindfulness involve an organization or an individual’s ability to perform in a dynamic environment. Such ability depends, to a great extent, on the way that these individuals or organizations think; how they collect information, their and their ability to flexibly change their perspective in light of a changing environment. There are two types of mindfulness; organizational and individual. This classification is done to provide a clear distinction between the abilities of an organization or an individual. Individual mindfulness entails an individual’s ability to regularly come up with new categories in the interpretation and perception of the universe. Organizational mindfulness, on the other hand, refers to the cognitive aspects used to solve problems on an organizational level (Butler and Gray, 2006). Organizational mindfulness entails the continuous refinement and scrutiny of existing expectations depending on the ever changing environment. Such refinement and scrutiny ensures that uncertainties are handled accordingly (Weick and Sutcliffe, 2001). The following are the components that make up organizational mindfulness. Reluctance to Simplify Interactions – this refers to the ability of an organization to recognize complex processes and situations and find ways to view the problem from different angles (Nagle, McAvoy & Sammon, 2011). An organization that employs this component is able to identify different ways of handling complex issues, and situations that occur during the software development process. This is because all the views and opinions of the participants of the software development team are highly valued (Nagle, McAvoy & Sammon, 2011). For an organization to employ this component during the development, one of the following factors has to be included in the development process; 1. The participants should be free enough to express their ideas and opinions in regard to the development process. One of the participants of the Cork workshop talks of the aspect of incorporating the customer in the development process. When explaining to her colleagues about how the customer makes changes to the development process, one of the other participants questions whether there was a way to avoid all the changes imposed by the customer. He asked, “So there was not stopping that?”(21:07). This participant was concerned with the organizations over flexibility towards the customer. However, he was interested to learn whether the other participant felt the same. Being mindful of his colleague, he did not impose his opinion on her; instead he gave her a chance to express herself. After being given the chance to speak, the female gives her view. She says; “No, actually it’s a very positive thing, that’s to be welcomed because actually it’s put our project in front of the chief executive its put their client’s role within the organization in a higher level of importance and is actually informing the organization better about what they do, so those changes are actually quite nice” (21:08). 2. Analysis of customer requirements or any requirements should be prolonged. This goes a long way to ensure that all participants or stakeholders of a development process are fully aware of the current state of affairs. Discussions that are held during the course of the development process should be conducted in such a manner that all those who do not fully grasp the situation are able to do so by the end of the discussion. This involves clarifying issues to persons who may not understand any technical jargon used. During the workshop held in Cork many issues were clarified for those who did not understand them at first. For instance, one of the participants is curious as to whether the customer is presented with the workflow diagrams. He asks, “…do you tend to send workflow diagrams as part of your use case to the developers?” (14:27). This information is crucial to the development process. This is because such workflow diagrams have to be developed in a manner that conveys the intended message to the customer. In response another participant replies and says, “…we will send some diagrams, yeah” (14:35). In another case, one of the participants of the Cork workshop mentions that time estimates will need to be included in the user stories implementation. One of the other participants, who is not aware of the processes involved in the development of the time estimates inquires as to who is responsible for creating them and what they represent. The participant who had introduced this issue does a good job of clarifying the issue. He says that the time represents, “how long it takes to develop that user story” (9:39). He goes on to say that, “…the story is the BA’s job and the estimate is the developer’s” (10:13). This act of response goes a long way in clarifying any unresolved issues that the other participants may have had. Commitment to resilience – this refers to an organization’s ability and will to solve any issues that occur during the development process including fixing errors (Nagle, McAvoy & Sammon, 2011). This component of mindfulness is concerned with recovery from various types of failure. At a high level, an organization is expected to have different ways of approaching complex situations to avoid occurrences of errors (Nagle, McAvoy & Sammon, 2011). During the workshop held in Cork one of the participants talks about the handling of user stories. He says; “… The basic idea is going, do we agree? Yes. Developer understands requirements, BA understands requirements, requirements finished, and that’s just one technique. I know in your case you talk about fields and so on…” (12:31). This depicts that the organization has found ways of handling the same situation using different approaches. In such a case, if the first approach of handling the user stories is not successful, the organization has a backup approach. The backup approach ensures that there are no delays experienced during the development process. The following factors when employed by an organization ensure that the development process is resilient; 1. An organization should commit to resolve all problematic issues that arise during the development process. Members of this development team were committed to solving all issues that may cause hitches during the development process. In regard to the issue of customer requirements, they came up with approaches that would ensure that would be understood by both the customer and the developers. One of the workshop’s participants says, “…ways like the use case and the workflow diagrams…give a clear indication of what we are actually doing on any of the changes and will also keep our documentation current for updates to existing processes…” (15:05). She goes on to say, “…that’s exactly what we used to do… mark up the screens take to the client walk it through reorganize and then cut the tickets” (15:49). She finishes by saying, “…we used to do them beautifully, visually so it actually represents what the thing would really look like, because it was done by a graphic designer…” (16:08). These approaches ensure that the requirements are fully understood by the involved parties. In the end, this ensures that the right software application is developed. 2. The organization should remain committed to developing the knowledge and skills of its employees. According to the deliberations during the Cork workshop, it is evident that the organization is eager to develop the skills and knowledge of its employees. First of all, the organization conducted this workshop in an attempt to promote awareness among the software development teams. Team members were informed about different operations and practices of the organization that they were not aware of. The workshop created a forum where the team members could share ideas, knowledge and information that would be instrumental in the software development process. Secondly, during the Cork workshop is heard saying, “…we need to a better job at skill sharing and making sure that we don’t have a person who is less for example a GIS expert” (1:03:25). This she says in response to a claim that there are few developer personnel within the organization. The shortage of personnel has been due to transfer of experienced personnel to other organizations and so on. According to her, “there is a benefit to giving different people exposure to different projects and different scenarios” (1:03:45). It is, therefore, important to pass on skills and knowledge to members of the development team. This will guarantee continuity within the organization in terms of knowledge and skills. Preoccupation with failure - this refers to the ability of an organization to identify mistakes and errors and to find ways that these errors can be used to improve the organization’s processes (Nagle, McAvoy & Sammon, 2011). Focusing on errors or mistakes associated with software development ensures that there are no cases of overconfidence or inattention (Nagle, McAvoy & Sammon, 2011). An organization can achieve this component of mindfulness by employing any of the following factors during the software development process. 1. The development team should be able identify and recognize even the small mistakes and errors as having a serious impact on the development process. Mistakes and errors can occur during the development process, recognizing the impact of these mistakes, even though they may seem minor, may go a long way in facilitating the development process. Mistakes or errors do not have to relate directly to the coding process, there are also other mistakes that may lead to misunderstandings. For instance, one participant says, “we are not going to keep to any particular notation, we will just say we are going from customer to user story” (6:04). To this, another participant jumps in to correct the first participant. He says, “…its user stories as prioritized lists” (6:15). Such a mistake might seem minor to many but in reality it’s not. Such a mistake may impact the development process in a very big way. It may cause a misunderstanding in the requirements that may ultimately result into the wrong application system. Therefore, even during deliberations members should be careful to when choosing their words to ensure that misunderstandings do not occur. Sensitivity to operations – this refers to the ability of an individual within an organization to identify the organization’s overall picture in regard to its operations (Nagle, McAvoy & Sammon, 2011). This ability enables employees to be fully aware of the organization’s operations and practices. Such awareness of the underlying practices and operations can be instrumental in the elimination of any uncertainty during the software development process. 1. Members of a software development team should be aware of the operations and processes of that exist beyond their job specification. Being an organization that is concerned with mindfulness team members should be willing to learn operations that are beyond their job specification. During the workshop held in Cork, it is evident that some members are not familiar with the organization’s process. As one of the participants informs the others of the need to have time estimates in the user stories, a female colleague is curious as to what that implies. She asks, “The time from the developing time or the time from when they expect to have it?” (9:35). She goes on to ask whether creation of the estimates is the developer’s or the BA’s job (10:20). This shows an absolute short of organizational processes. This situation is made serious by the fact that she is not aware of the roles of the different team members. 2. Team members are encouraged to question and find out operations that exist beyond their job specification. The above mentioned case can also be said to be a positive thing towards the running of the organization. The female colleague is seen to ask questions regarding the creation of estimates during the development process. On one hand, her actions may depict ignorance on her part towards the organization’s processes and operations. However, she is not shy about her ignorance and chooses to ask. This makes the case appear positive. 3. The software development team members are encouraged to share with the team any information regarding the operations and processes of an organization. The participants of the Cork workshop appear to be very mindful in terms of information sharing. In the above mentioned case, when the female participant inquires about the time estimates, another participant steps in and sheds some light on the issue. He says that the time estimates represents, “how long it takes to develop that user story” (9:39). He continues to say that, “the story is the BA’s job and the estimate is the developer’s” (10:13). These responses shed light on the issues that she had highlighted. In effect even those members who were shy to show their ignorance on the matter, are enlightened. Another participant of the workshop who is curious as to the concept of the user stories asks; “Can we clarify more what will be in the user stories… because I missed what you talked about the user stories and the user example that you went through earlier. Does it say that I the customer wants to log on to the site that will allow me to query all of my teaching records that I have, and I want to be able to do this… with me as the teacher, me as the trainee teacher and me as the person who is managing all these people. So do I have three separate user stories?” (8:08). Another colleague responds by saying, “Well it depends… can you developers work off that…is enough there for your developers to work on” (8:50). He goes on to clarify that, “basically the user stories represents what the customers wants, what they are asking of detail will have to be custom for the developers to be able to go, OK I can develop that” (9:14). After these responses, everyone at the meeting seemed content and so the team leader moved the meeting to a direction. Deference to Expertise – this refers to the ability of an organization to invest in expertise. It also refers to the empowerment of employees within an organization (Nagle, McAvoy & Sammon, 2011). This is because the expertise and skills of the employees are of a high value to the organization. Employees should be given the ability to solve problematic issues on their own initiative. Within the organization it can be seen that there are employees who hold different qualifications. This organization is made up of people from both business and programming professionals. All these employees have different tasks and roles within the organization. Therefore, each of the employees is an expert in respect to their field. 1. Team members within an organization are encouraged to seek help from their colleagues who have more experienced or are experts in their field. Given the fact, there are employees with varied professions within the organization, members of a software development team should be able to seek assistance from other team members who have more experience or are experts in that area. During the workshop held in Cork, one of the participants who is not clear about the issue of time estimates in the development of user stories inquires as to who is responsible for coming up with the time estimates. One of the participants of the workshop who is well aware of the organization’s processes says, “The story is the BA’s job and the estimate is the developer’s” (10:13). This highlights the differences in the roles of the BAs and the developers. In this case, the BAs will have to seek help from the developers to come up with the time estimates of the project. After the developers come up with such estimates, they will pass these results to the Bas. The Bas in turn will pass on this information to the customer and deliberate on them. Therefore, in order to ensure that there is smooth flow of operations during the development process, it is necessary for team members to seek help from their colleagues who are experts in the required field. There are also cases where some members of the development team appear to be against seeking help from the experts. While talking about user stories, one participant says that, “developers want to know what to do not how to do it” (12:35). In this case, the user stories represent the customer requirements that have been collected by the BAs. Therefore, it seems highly likely that they should have some input into the implementation of the user stories. The impact of this negative habit is clearly seen when one of the participant asks, “…so they don’t want directions on the fields, because to me this use case is too fluffy we will get too many questions back on the specifics…” (12:57). Therefore, the lack of involvement of the BAs leads to a less than satisfactory use case. In the end, the customer will not be satisfied with the end product. 2. Members of a software development team should be able to respect each other’s profession. Respect is an important virtue within an organization. Respect allows the employees to better collaborate on projects and eliminates disruptions caused by misunderstandings. Respect among colleagues attending the Cork workshop is evident due to the way each of the participants is allowed to voice their opinion or ask questions. The following exchange between colleagues illustrates the respect that they afford to each other. Participant 1- “developers want to know what to do not how to do it” (12:35). Participant 2- “No, What they actually said was they would like to hear more about how it’s going to be used, they did not say that they don’t want the what to do” (12:43) Participant 1 – “No the To-do List actually said developers said we don’t need to be told how to do it” (12:51). Participant 2 – “…so they don’t want directions on the fields; because to me this use case is too fluffy we will get too many questions back on the specifics…” (12:57). None of the participants dismisses the other’s opinion; instead, they acknowledge them but offer theirs instead. This amount of respect within an organization ensures that a lot of creative ideas may be floated around during the discussions, leading to better approaches of handling different situations. Conclusion To a great extent this organization has gone out of its way to employ mindfulness in the software development process. There are five different factors that make up organizational mindfulness and they include reluctance to simplify requirements, sensitivity to operations, deference to expertise, failure preoccupation and commitment to resilience. This organization has done its best to incorporate some aspects of the above mentioned factors in an effort to achieve organizational mindfulness. Deliberations that occurred among the participants of the Cork workshop revealed that the organization is committed to mindfulness. However, there were instances where the organization seemed to neglect the organizational goals. In most of the cases, the participants of the Cork workshop were not aware of the processes involved. However, the organization seemed keen to pass on expertise and skills to other employees. This ensured that the company was well secure in terms of skills and expertise. The employees were encouraged to express their opinions and views in an effort to ensure that the situation at hand was well understood by all the employees. References Nagle, T, McAvoy, J & Sammon, D 2011, "Utilizing Mindfulness to Analyze Agile Global Software Development”, ECIS 2011 Proceedings, Paper 119 Butler, B S & Gray, P H 2006, ‘Reliability, Mindfulness, and Information Systems’, Mis Quarterly, vol. 30, no. 2, pp. 211-224. Weick, K E, Sutcliffe, K M & Obstfeld, D 1999, ‘Organizing for High Reliability: Processes of Collective Mindfulness’, In Research in Organizational Behavior, vol. 21, pp. 81-123. Read More