SA WORKSHEET

4. Alternate Solutions

Tying back the final homework to the first, its highlighted again that issue lies in the low productivity of the

knowledge workers as seen by the organization. Therefore, the under mentioned alternatives tend to address that

concern as an umbrella term and relate the stated objectives and alternatives in that light. Adaption of any

alternative(s), by the management is/are not only expected to increase the organizational value but value as seen by

the employees as well.

4.1 Alternative #1: Introduction of Scrum within the organizational dynamics:

The team at the present is not working on any predefined set system for churning out the builds but a single person’s

i.e. Project Engineer (PE) plan to accommodate the customer needs while still maintaining the illusion of being lean

and managing the pressure on the team in a best possible way. Unfortunately, only so much could be done by the PE

and in some cases his/her team tagging with the TPM. Therefore, there is need for introduction of the agile centric

process within the team, which has over the years proved to be addressing the knowledge worker’s low productivity.

Scrum in this case is suggested to be introduced within the team. It’s based on the principal of empiricism, not as a

product development technique but as a product development management framework for addressing the complex

adaptive problems, envisioning incrementally iterative development and improvement at its core, which is exactly

what the team is lacking at the present. This option is expected to address the stated objectives of reducing

micromanagement within the organization and delegating the decision making to the grass root level, with just

enough touch of the management to keep the team streamlined yet not overpowering the individual autonomy of

the knowledge worker which is at the core to his/her productivity for the organization. Additionally, the same is

expected to have a positive effect on the knowledge sharing practices of the team, where the pressure on the team

wouldn’t be as much as it is right now therefore reducing the attrition rate and extending out the opportunities

within the team to grow as knowledgeable workers rather than striving for fancy designatory titles to be associated

with their names.

The implementation of the scrum, being empirical in nature, differs throughout the organizations but the core values

and designations of the expected hierarchy/roles and the principles of transparency, inspection and adaptation
remains the same. Thus, with each component of the scrum serving a predefined and specific role, the predictability

could be improved, and the risk could be mitigated.

4.1.1 Consequences

The team at the present is working without any specific structure of the team therefore lacking therein the factor of

agile mentality, which shall be the most important for the field they are dealing with. Metaphorically Scrum

equivalent to that of writing a book but not in a go rather dividing the book into different chapters each of defined

maximum length and committing to delivering one chapter at a time, so that the valuable feedback received from the

stakeholders of the book could be incorporated at a stage where that expectation could be carried out throughout

the rest of the book contrary to having the whole be readjusted were it to be written in a go and presented

afterwards. Thus, its comparable to divide and rule concept in this fashion, but from a positive viewpoint.

Application of the same is going to bring with it three important pillars of scrum i.e. transparency, inspection and

adaptation. Unlike the present, where the team dynamics is only decided by a person or two at maximum and flown

to the rest of the team, transparency here calls for the availability of all the required information to the team

members as they relate to the information, which does include the inclusion of individual contributors during the

planning phases of build. Thus, there would be same understanding of what needs be accomplished which defines

the value for "Done" as something that every member knows as to what the required deliverable at the end of the

sprint is. Inspection and adaptation would both based on the mentality of having the real time data to be used as

feedback for having a positive effect on the velocity, where velocity is the metric used for assigning a weight to an

item in the sprint backlog. Thus, introduction of scrum within the team not only limits the number of titles allotted to

the team to be majorly three i.e. Product Owner (PO), Scrum Master (SM) and development team but also brings

with it some of the most important following characteristics, which aligns with the stated objectives of organizational

restructuring and improving retention practices: -

 High degree of self-organizing and therefore autonomy

 Cross functional team so as to not be dependent on any one person for his/her skills rather at least two people

are equipped with a skill set to help facilitate the sprint success, were there be any absences from member

thought to be a guru for his/her field.

  There are no individual titles for team members of the developmental team other than the developer.

 There are no sub teams within the developmental team

 Individual developmental team members may have specific expertise, but the accountability lies with the team as

whole, therefore bringing the team mentality.

4.1.2 Advantages/Disadvantages:

Objective, Metric and Target Assessment

To reduce micro management This alternative is directly affecting the objective, for scrum explicitly limits the
Metric: Number of responsibilities for role of the management when deciding how much work is going to be done by
management to 5 major points the developmental team, but it delegates that decision to the team by involving
Target: Reduce until next month to 5 them in at least the sprint planning. Furthermore, Scrum Master (SM), apart
major responsibilities from many other responsibilities is the management's eyes into the
developmental team and vice versa, therefore limiting the management through
a formal bridge to not let them micromanage, therefore disrupting the team
dynamics. This gives them the ability to concentrate on much of their remaining
job scope.
To increase employee autonomy Employee autonomy is at the heart of Scrum. Therefore, the designated roles are
Metric: Avg # of roles and responsibilities restricted to 3 i.e. Product Owner (PO), Scrum Master (SM) and Developmental
Target: To reduce to 5 major and generic Team, while responsibilities of each are mentioned as Appendix A, thereby
immediately depicting autonomy
To improve knowledge sharing practices Knowledge sharing is a consequence of the adopting scrum for the team
Metric: Avg # mentors/mentee for each strength is strictly limited. The team strength has to be no less than three and no
employee greater than nine, were the PO and SM also performing the developmental
Target: Increase by 20% by end of quarter work. Reason being that less than three put the sprint in jeopardy due to a
relatively greater amount of work needed be done and greater than nine
requires a relatively higher amount of coordination, generating complexity for
the empirical process management. This gives a lot of opportunity to the team
members to work cross functionally and thereby avail the opportunity for
mentorship. As it would be a month-long time boxed event at max, the goal of
20% is easily achievable.
Increase customer involvement in planning The Sprint planning is the platform to decide as to what could be done in the
Metric: Avg # of customer attendance upcoming sprint and how would it be done. It's a scrum team wide collaborative
during build planning meeting divided to have no more than two hours a week over the sprint course,
Target: To increase by 50% until next RLmaking it a total of eight in one-month long sprint. It is at this point, that
Delivery customers shall be invited in here to give feedback and be included in these
activities, though it shall not get to jeopardize the essence of the team meeting
where the development team gets to decide what all could be included in the
backlog for the sprint. The inputs used in the sprint planning are the product
backlog, past performance and projected capability of the developmental team
and the latest product increment. The SM ensures the event with providing
coaching to the team for sticking to the allotted time-box. The PO lays outs the
product backlog and defines the success of the sprint by addressing as to what
product backlogs would make up the sprint's success. The developmental team
forecasts the product backlogs, thereby forming the sprint backlog and from it is
carved out the sprint goal. Sprint goal is basically a high-level purpose of why the
sprint is being done in the first place, thereby defining a framework to work in
by absorbing the high-level purpose of, now the sprint backlog. It is pertinent to
mention that it is solely the developmental team, who decides as to what
product back log makes up the sprint back log, obviously with the underpinning
guideline from the PO about the descending business value. The team shall only
include those items from the product backlog to the sprint backlog that are
"ready", meaning as in they are independent, actionable, has a point value
attached to it and a clear definition of the criteria that would render it "done",
thereby defining "done" as seen in scrum. This is the exact point where
customers’ involvement would be most beneficial for the maturity of the
requirements and their projected completion is a knowledge that customer
knows the best.

While there are a lot of advantages associated with scrum as described above, the implementation debate could end

in employees resisting the change if it is perceived that the change is thrust upon them. Therefore, that is one of the

biggest disadvantage associated with the implementation. Obviously only the working methodology would be

restructured within the organization but what could therefore result from this, which would be the biggest

disadvantage to the team as a whole is the deprecating value of “Appreciative Inquiry”, that would be much needed

within this transition. If this were to happen, the most looked forward to aspect i.e. carrying forward all the positive

practices of the team would be left behind, and the team would thereafter need to start from the scratch, which may
 well enough result in failure. In a nutshell, there a need to take the whole team onboard with the decision else good

intentions may well enough result in organizational fatality.

4.1.3 Risks (for alternative #1 solution approach):

Risk Impact Prob of Risk Rating Mitigate

Occurrence
The most important risk High 70% High The best way to mitigate the risk is take on a build
associated with the planned after mutual coordination with the customer, that
alternative is the transitionary
forms an extension to an already developed
phase from the present
working structure to the functionality and that too not a complex one. This
desired which may result in would result in less implementation and testing
the schedule slippage against
efforts for the team and rather give them enough
the customer expectations.
They in essence are not time to familiarize themselves the scrum process, so
concerned with the internal they can fully understand and grab the essence of the
organizational dynamics but
same
value generation for them.
The scrum in its true entirety Moderate 80% Low There is no one size fits all rather tools towards the
may not be achieved to be end, that are to be used as required even mix and
associated with the team for
match. Being empirical in nature, the optimal point
being called scrum following
team. As part of the first- where agile practices would be the most value added
generation agile method, the to a situation, can only be seen were they to be
roles in scrum are prescriptive
deployed and tested. But it shall be noted that even
when seen on the scale for
prescriptiveness vs. though if scrum is not implemented in it prescribed
adaptiveness. Therefore, any sense, the organization may well enough mix and
deviation from that prescribed
match a couple of two methods for example Scrum
set would mean as to Scrum is
no being followed. Supposedly and Kanban. Scrum defines the roles for you, while
a team were to say they are you are free to choose roles in Kanban as it
using Scrum but doesn't use assimilates itself into the defined organizational
the daily stand-ups as
prescribed. They would then structure under the pretext of arming the people with
not be using scrum but based the purpose and essence of the role and switching
on any of the remaining hats as and when needed.
practices of the scrum, were
they to be followed in their
real sense, would let them
claim as to they are doing
something scrumish
4.2 Alternative 2: Introduction of Kanban within the organizational dynamics

4.3 Alternative 3: Induce a 3-month formal training of employees before they join the organization for the

first

Appendix A

Product Owner

Product Owner(PO) is a scrum team member responsible for: -

1. The commercial success of the product and who holds the vision about the where to take the product to.

2. Understanding the customer needs and wants and have them be translated into the product backlog

3. Management of the backlog which include clear expression of the product backlog items, their ordering to

achieve the organizational goals and missions, assigning the business value to the product backlog, ensuring the

visibility, transparency and next plan of action for the development team from the product backlog perspective

4. Writing the user stories

5. Performing release planning

As part of the same empirical mindset of inspect and adapt, PO is present in the Sprint retrospective as well to

suggest insightful thoughts

Scrum Master (increased responsibility due to acting as a bridge)

Scrum Master (SM), is a servant-leader of the scrum team unlike the name, which may tend to suggest his/her

managerial bossy role in the team. SM is the management's eyes into the developmental team and vice versa. The

responsibilities of the SM include but not limited to: -

1. Mentoring and coaching the team on the aspects of the scrum theory, practices and rules.

2. Facilitating and suggesting the management the effect of their decisions on the work progress of the

developmental team.

3. Understanding the product planning in empirical environment.

4. Helping the PO with better techniques for the backlog management

5. Facilitating the daily scrums to the point of having time boxing be implemented, the participation be restricted in

between the developmental team and the removal of the discussed impediments.
6. Facilitating the time boxing in the sprint planning, sprint review and sprint retrospective.

7. Mentoring the developmental team in cross-functionality and self-organizing.

8. SM is the scrum team member, participating in the sprint review as the accountability figure for the scrum

processes.

9. SM must be working with the developmental team in making the artifacts be more transparent

The team member

The team member has been explained in the Question 2 under the pretext of the involvement of the same as part of

the developmental team in scrum. There although are some characteristics of the which are worth highlighting in

here: -

1. Each team member is part of the team, no matter what special skills he/she may be having.

2. There are no special titles or designations awarded to the individual within the developmental team as all are

called developers regardless of the expertise, as they are working under the paradigm of the cross functional

team.

3. The team member as part of the development team is responsible for the increments, consequence of the sprint.

4. Team member as part of the development team is responsible for having the for forecasts of the product backlog

be done to result in the sprint backlog and further devising the sprint goal.

Apart from this all the characteristics of the developmental team are applicable to the team member as an individual

in the scrum paradigm.