Overall, SharePoint can be utilized to challenge the “status
quo” thinking. SharePoint empowers teams to continuously improve via process,
people and behavioral changes.
Some traits that are usually exhibited when change is
involved with SharePoint:
·The new process has users scared – so hand
holding and direction on the value of SharePoint is needed.
·Users feel that SharePoint is a time wasted, nothing
gained technology – so it needs to be sold via learning sessions (classes,
videos, handouts, etc.).
·After time, users will realize the value and the
environment ecosystem of SharePoint will be healthy and productive.
The following are some key items to
consider when using SharePoint as a platform for change:
1)Know what SharePoint can do and how much can get
done with out of the box as well as custom functionality
2)Know how much work – can get done based on cost,
scope and schedule with SharePoint
3)Know what can released during regular hours and
what needs a change control or e-mail communication to users (example a
solution deployment that re-cycles application pools)
4)Know what can be completing taking into
consideration – ideal time (how long item will take without distractions)
5)Have a definition of what done means in regard
to a site or functionality request
The following are some key items to consider
when using SharePoint as a platform for change:
1)Let proper team members know of change so that a
plan for how to communicate change to organization can be created
2)Define how SharePoint will be utilized in the
organization. Will its main purpose be document management, content sites or utilization
of key and core workflows
3)Account for governance – know what users will be
allowed and not allow to do. Make the governance plans readily available in a
wiki or series of blog posts.
4)Account for at least a one hour to 90 minute
overview of SharePoint functionality that users will need to know (upload
documents, use lists, how to search, how to use managed metadata, etc.)
5)Develop and fine tune – processes for how best
to manage work and requests in SharePoint by utilizing request forms for
requirements so that an Agile model can be followed by creating from such
requests the needed stories and tasks for what was being asked.
When SharePoint is utilized with agile, the following are
some key tips to utilize during a sprint review agenda:
1)Welcome everyone and state that during this time
slot the SharePoint increments completed will be demoed.
2)State what SharePoint aspects will and will not
be demoed. Usually it is good to have test data in the sites, libraries, lists
and workflows that are part of the demo.
3)Demo the functionality in either a test or
staged production environment.
4)Discuss the new functionality and answer
questions surrounding the delivered increment.
5)Present upcoming backlog items as far as the
features and functionality surrounding SharePoint.
6)Conclude and review what was achieved during the
sprint review and make sure that the product owner will enter and adjust
priorities in the backlog.
In regard to SharePoint a paradigm shift is present as a lot
of the time newer processes are needed for the system to be successful. Thus,
adopting these traits will be good to possibly utilize:
Have a plan – in this
regard, it’s having a scope for the SharePoint launch – this should include not
only a schedule for launch but a launch for each teams/departments new
sites/subsites. When launched proper training of basic functionality
(uploading, alerts and views) should be given.
Value Driven –
sell the platform via town-hall meetings, videos, e-mail blasts and proper
on-line documentation. SharePoint empowers users which can’t be un-sprung if
users don’t know how to utilize the system or know what it can do.
When it comes to what project methodology to utilize in
regard to SharePoint, waterfall is indeed one method.
To use Waterfall with SharePoint the following steps are
followed:
Gather system
requirements – which for SharePoint this usually involves what is needed
for a site/subsite, workflow or piece of functionality (custom web-part, list,
calendar, etc.).
Software requirements
– for SharePoint sake this could involve what features to turn on/off as well
as what functionality to build.
Analysis – look into
SharePoint from a 360 degree overview in order to meet requirements via how
users work today. This involves knowing what works and doesn’t work for users
after talking to them.
Program Design – in
SharePoint speak this would involve the applicable page layout and needed
imagery.
Coding – a developer,
administrator or analyst – would then build the SharePoint functionality.
Testing – users would
utilize a created test script to test and signoff on what was built.
Operation –
functionality is put into production and when changes are needed – the process
steps are repeated as needed.
Overall – SharePoint and agile scrum are a good fit for many
reasons – the common aspects of Epic -> Feature -> Story and Task are
given an overview below of how they fit together in a SharePoint project.
Epics - SharePoint
agile scrum allows teams to formulate epics (which would encompass a major
release) – overall, epics maybe good for a new installation, upgrade, or
cumulative patch of SharePoint.
Features – in SharePoint
agile scrum, a feature (working functionality usually part of an epic) may consist
of creating a custom web part or creating a new workflow for a change control
process (these can be the features that are part of your new install).
Stories – these are
the aspects that need created/built which will allow users to accomplish what
they need to do in the said system. Stories are usually written in the context
of:
As a <>, I
need<>, so that I get <>. Where the text between the < >
would be filled in by the users or an analyst working with a user.
A SharePoint example of a story would be:
As an end user, I need a button which when checked populates
a list so that I get changes from the change control system from the day
before.
Tasks – as part
of a story – tasks will be needed so that the aspects that make up the stories
asked are created and built.
SharePoint example:
Custom
list is created with proper fields
External content type is created
for change control status field
Form is designed with button lookup
to change control system
Thus – core agile scrum methods can indeed work well for
SharePoint and tweaked and defined based on one’s business needs.
