Showing posts with label scrum. Show all posts
Showing posts with label scrum. Show all posts

Friday 8 September 2023

Notes for running Agile Power Platform Projects including DevOps

Overview:  General overview notes on setting up Power Platform projects/programs.  Before I get into the mechanics, my overriding goal is to have high functioning teams, and be a member of high functioning teams.  "Create an environment where team members can do there best work".  for instance, I visit and work with a lot of businesses and I many teams that are in an "Artificial Harmony" state (pretend all is well with the world). Everyone says it's wonderful but it's a snake-pit with relationships and fear.  Teams members need to be happy, open to conversations, accept risk and aware mistakes are going to happen.  Basically, these teams need to be identified and trust build, this often involves an adjustment to a particular mid-level manager.  The worst offenders tend to be offshore teams, and there are amazing teams and people so this definitely is a generalization. The teams tend to be hierarchical as opposed to flat or matrix. it's terrible for software projects.  Look out for Technical leads, ISV Project managers, Deliver Leads, they can breed the wrong tone/attitude across multiple team members and teams.  Check out Amy Edmondson's book the Right kind of wrong: the Science of failing well.  Anyway, rant over.   

Learn from mistakes, simple mistakes, remove them ASAP, strategically think automation, if we learn mistakes ensure they don't happen on the next project or sooner.  Encourage transparency, and open communication.


Here are my notes for setting up ADO and guidance for Agile PP projects....

Agile Artifact Hierarchy:

Epics > User Stories (max 5 days work) > Tasks 

                                                                  > Bugs

Epics > Spike

Guide:

  • User Stories mush be written in the format: As the <role> , I want to <feature> so that <benefit>., and have 1 to many Acceptance Criteria using Gherkin 
  • Ability to add a release note to User Story, Spike, Task or Bug.
  • Automate pipelines from unmanaged to UAT Managed.
  • Min three env (Dev-unmanaged), and UAT/Prod-both managed), use ADO pipelines or Power platform pipelines
  • Adding annotated images is great for improved communication.  Recorded voice narrated mp4 walk thrus are also great for proofs, and explaining issues.
  • US, bug, Task, Spike artifact items, each has a Release note tab.  So if a User Story needs more than 1 solution package changed, use child tasks and add the release notes to the User Story.

Flow of bugs and User Stories:

  1. New (Anyone)
  2. Approved (Product Owner (PO)) 
  3. Ready - (PO)
  4. Committed - (Team Member/dev)
  5. Dev - In Progress (dev)
  6. Dev - Complete (dev)
  7. Dev - Show QA (dev & QA)
  8. UAT - Ready to Deploy in UAT (dev)
  9. UAT - Deployed Ready for Testing (QA)
  10. UAT - In Tested Manaual (QA & PO)
  11. UAT - Complete Ready for Deployment to Prd (QA)
  12. PRD - Deployed
  13. PRD - Sanity Check (can include automate smoke testing)
  14. PRD - Done
Example Status's
Other states:

  • Removed
  • Duplicate
  • Not Applicable

Release Notes for Power Platform packages need to include the following fields in ADO against artefacts:

  1. Package Name (dropdownlist), 
  2. Current Package Version, 
  3. New Package Version (Default TBC), 
  4. Change Note,  
  5. Deployed Status (dropdown list: NA, UAT, PRD), 
  6. Pre deployment steps, 
  7. Post Deployment steps
Example of ADO Release Notes assigned against tasks, bugs, and user stories.

Quick fixes/urgent bugs/Emergency changes:

  • Try make release cycles as short as possible, and only do emergency changes if absolutely required.
  • Take a snapshot copy of dev/label, for each proposed production deployment - unmanaged env - part of ADO pipeline, this allows us to build Dev, and UAT env for the specific emergency change.
  • Take a snapshot of UAT - managed env - part of ADO pipeline
  • Deploy to PRD from Emergency UAT.
  • Developer integrates emergency change into Dev from the Dev Copy.  And follows the full path.
Team/Teams:
  • Try keep teams as small as possible.  I prefer 1 team to multiple scrum teams unless their is a clear distinction/break.
  • Product Owner (PO) needs to be available all the time and answer immediately.  To me they act as the business and the traditional BA role, and are responsible for the product backlog.
  • Scrum masters.  Your job is to ensure the team members are happy and confident to take risks and work, Scrum ceremonies are merely a way to help out.
  • Team members are mainly pro and citizen developers, if I use dedicated QA testers in the scrum team, they need to be responsible for the AC with the PO.  They tend to be analyst/developers.
  • Automate, automate, automate.  there are fantastic tools including low code test tools, use them.  Ensure you have automate smoke tests, regression tests, and performance tests for each DTAP env.
  • Have short coding standards and naming conventions, error handling patterns and enforce them, have a defined ADO process, have a pipeline for deployments, automate tests and continuously update.  Have a Monitoring strategy i.e. Azure Monitor, log via AppInsights on a Log Analytics workspace.  Each env logs to it's own Azure Log Analytics.  Does each Log analytics belong to their own workspace?  I pref Non-prod, and prod workspaces. 
  • Teams/Slack, okay just Microsoft Teams, remote work make happier team members and gives people more time, use it.  But encourage camera to be on, email is not a defence (ever), people must IM/chat/ping and call each other.  
  • Encourage meeting up, join with social inclusive events at once a month to once a week.  Encourage people to work together online including peer programming.  

Sunday 20 August 2023

Common Scrum Team improvements

 WIP

Problem: Bugs must not change scope - common to see a bug and it morphs into improvements, other changes.  

Fix: Raise new bug. Don't keep amending and adding new features.

Problem: Team testers/automation testers do not understand the requirement.  Cause by the User Story (US) or bug being ambiguous and Acceptance Criteria (AC)

Fix: Ensure User Stories are in a standard format i.e. "As a <>, I want to <>, so that <>.".  Ensure Gherkin is used for AC (Scenario, Given, When, Then, and preferably more than 1 AC per user story.  Could have: Annotate diagrams to clearly convey artefact information.  Also a narrated recording for bugs.  This could be the person recording the bug, the person that fixed the bug as proof to increase understanding. 

Saturday 19 October 2019

Evidence Based Management for Scrum

Evidence Base Management (EBM) is an management framework that uses evidence and metrics.  Execs & Middle mgmt don't get insight and normal forecasts.  EBM framework to help management move the company.  The mgmt can use evidence to drive the business forward.  Inspect and adapt using evidence.  I like to keep everything simple and move towards a more complex mature set of measurements as the easiest metrics to implement provide early value to the project.

"Evidence-Based Management is a framework organizations can use to help them measure, manage, and increase the value they derive from their product delivery."  Scrum.org

Examples Types of metrics you may want to measure:
  1. Velocity
  2. Sprint Burn downs
  3. Versioning - versions of product or bugs requiring multiple fixes
  4. Code Coverage & Code Analysis
  5. Missed bugs/escaped bugs - bugs missed in a release
  6. Issues/Failed Deployments
  7. Team happiness - capture metrics in Sprint Retrospective from the team
  8. Financial measure - cost to delivery
  9. Average User Story completion time per team (identify outliers and average for each team.  Do from started status to completed status).
  10. Average story points per team, factoring in the number of team members over multiple sprints (don't compare teams as their unit size is not consistent across teams; if you do try standardize, the teams will give more points to fake outperforming other teams).
Help management nudge the teams and company in the right directions.  To get these metrics, need to explicitly determine what the goals are, so can figure out KPI and we are measuring this right things.  Ensure the management goals are SMART (Specific: Well defined, clear, and unambiguous) or use OKR framework to define goals to figure out the metrics to collect.  Ensure the metrics are important to the goals of the company or team.   Consider using
"Objectives and key results (OKR) is a goal-setting framework that helps organizations define goals — or objectives — and then track the outcome."  cio.com

Common KPI's:  
  1. Escaped Defects
  2. Defects in the last 14 days
  3. In Progress Features and User Stories per team
  4. Team velocity
  5. Stories completed vs stories committed
  6. Tech debt (know issue, items skipped)
  7. Team burndown charts
A couple of columns and dashboard widgets for summarizing progress in DevOps:
  1. Progress by User Story Total minus remaining rolling up to features.
  2. Progress by Work Items in a feature - get user stories, tasks, spikes that make up the feature and shows % of artefacts completed within the feature.
  3. Epic Progress - each epic show the number of features and number of feature completed e.g. 3 of 11 feature completed.
  4. Number of "In Progress" feature or User stories per scrum team - very useful to check a team is using and updating artefacts proactively.
  5. Priority committed and done using priority or WSJF.
Three goals of KPI's in Scrum:
  1. Measure deliverables
  2. Measure team ability to deliver business value
  3. Measure the scrum team itself

Wednesday 11 September 2019

Scrum - Part 5 - Certification PSM 1

Overview:  The two main bodies that do the most credible Scrum certifications: Scrum.org (PSM) and scrum alliance (CSM).  This post is my notes from Professional Scrum Master (PSM) 1 exam preparation. 

Note: Certifications teach the mechanics/ceremonies, the number 1 role of a scrum master is to ensure their team is happy.  Ensure team members are heard, happy, feel safe and are open to taking risks on the project and be encouraged to do so.

The key to PSM1 is to read the Scrum guide several times (it's short), it's short but you need to understand it as you answer to it's specifications not what other guides or books recommend.  It's a framework and the certification is for the Scrum framework only.  There are a lot of great resources out there including on Scrum.org's website.  The open assessments are excellent.

My PSM1 Scrum Certification Notes:

Three Roles, Five Events, Three artifacts, Five Rules (REAR)
Three Roles:  1) Product Owner (PO), 2) Scrum Master; 3) Development Team Member
Five Events: 1) Sprint - 4 weeks 2) Sprint planning – 8hrs 3) Daily scrum/stand-up – 15min 4) Sprint Review - 4hrs 5) Sprint Retrospective - 3hrs
Three Artifacts:  1) Product Backlog 2) Sprint Backlog 3) Increment
Five Rules: 1) Done 2) Time-box 3) Sprint Cancellation 4) Team size 5) Effort.
  • The Scrum Framework is based on Empiricism = Learn from our experiences.  Three pillars uphold every implementation of empirical process control: 1) Inspection 2) Adaption 3) Transparency.
  • Five Scrum Values: 1) Courage, 2) Commitment, 3) Focus,  Openness, and 5) Respect  (CCFOR)
  • On any project, there is one product backlog, and one Product Owner (PO), regardless of how many Scrum Teams work on a product/project.
  • Only the PO has the authority to cancel a Sprint before the Sprint is over.
  • The Product Owner is responsible for managing the Product Backlog, which includes that the Product Backlog is visible, transparent, and clear to all, and shows what the Scrum Team will work on next.
  • The Product Owner decides what makes the most sense to optimize the value of the work being done by the Development Team.
  • In order to effectively be the product value maximizer, the entire organization must respect the PO's decision authority via the PBL. Dev team only works on PO’s instructions via Product Backlog Items (PBI’s).
  • All Product Backlog Items must:
represent a requirement for a change to the product under development, and
have all of the following attributes: description, order, estimate, value. (DOEV)
  • DoD – Definition of Done is created by the Development team members.  Estimating is done  by the Dev team on each PBI.  Ordering and Value of PBI’s are owned by the Product Owner.
  • The Product have one Product Backlog, regardless of how many teams are used.  Product Backlog Refinement = Product Backlog Grooming.
  • Sprint goals are the result of a negotiation between the Product Owner and the Development Team. Sprint Goals should be specific and measurable.  Each sprint needs a Sprint Goal.
  • The heart of Scrum is a Sprint, a time-box of one month or less during which a "Done", useable, and potentially releasable product Increment is created. This applies to every Sprint.
  • The duration of a Sprint is fixed and cannot be shortened or lengthened.  A sprint is over when the time-box expires.
  • The product increment should be usable and releasable at the end of every Sprint, but it does not have to be released.
  • A new Sprint starts immediately after the conclusion of the previous Sprint.
  • Development Teams are cross-functional, with all of the skills as a team necessary to create a product Increment.
  • The Development Team uses the Daily Scrum to inspect progress toward the Sprint Goal and to inspect how progress is trending toward completing the work in the Sprint Backlog.
  • Development Teams typically go through some steps before achieving a state of increased performance. Changing membership typically reduces cohesion, affecting performance and productivity in the short term. 3-9 Development team members.
  • The Scrum Master enforces the rule that only Development Team members participate in the Daily Scrum.  Scrum Master ensures Dev team know how to run daily scrums.
  • A Scrum Master is a servant-leader for the Development Team. Facilitation and removing impediments serves a team in achieving the best productivity possible.
  • The Scrum Master ensures that the Development Team has the meeting, but the Development Team is responsible for conducting the Daily Scrum. The Scrum Master teaches the Development Team to keep the Daily Scrum within the 15-minute time-box. The Scrum Master enforces the rule that only Development Team members participate in the Daily Scrum.
  • Sprint Review has two aims: 1) Review the dev increment from the sprint 2) Adapt the Product backlog.
  • Scale Scrum using the Nexus framework.  All teams use a single Product Backlog, Single Product Owner shared across scrum teams.  DoD(“Done”) mutually agreed by all Dev Teams on the product.
Disclaimer: A lot of this information comes from Scrum.org.  This post is my notes and how I thought about the PSM 1 certification.  If you disagree or see any errors, please post a comment or contact me to update. 

My other posts on Scrum:
Agile for SharePoint
Scrum for SharePoint - Part 1
Scrum for SharePoint - Part 2
Scrum - Part 3 - Scaling Scrum 
Scrum - Part 4 - Kanban and Scrum 
Scrum - Part 5 - Certification PSM 1 (This post)

Wednesday 4 September 2019

SCRUM - Part 4 - Scrum with Kanban

Overview:  Kanban is a good lean framework for delivering software projects.  I like to lift parts of Kanban into my Scrum teams.  Kanban focus on flow/process improvement which can be useful to leaverage.

Kanban boards - It's common to use Kanban boards so your team can use the sprint states for PBI's to merely show progress and helps identify PBI that are struggling to get to a done state.  I pretty much always use additional tools when doing sprint.  Another common example id story points (it is not part of Scrum but useful for PBI estimating).
Kanban allows items to be added at anytime and this is not the way to go with Scrum that has a fixed set of PBI for the duration of the sprint.  Often the Scrum team gets support tickets if they are a product team development team.

Problem: So for instance, at a SaaS provider the team had to do 3rd line support tickets that came in as a urgent priority.  The team were using Sprint and it wasn't working for delivering planned work enhancements.  Everything was jumbled and deadlines were getting missed. 
Resolution:  30% of the 2 week sprints were placeholders that could enter the Sprint during the sprint.  This worked really well and actually started at 40% and was reduced once the team got confidence.  This allowed grooming of the support tickets so only proper 3rd level support tickets were entering the sprint.  It takes commitment but this worked well to solve the specific problem.

Basically in the same team use Scrum for product development and Kanban for support.

Agile for SharePoint
Scrum for SharePoint - Part 1
Scrum for SharePoint - Part 2
Scrum - Part 3 - Scaling Scrum
Scrum - Part 4 - Kanban and Scrum (This post)
Scrum - Part 5 - Certification PSM 1

Thursday 29 August 2019

SCRUM for SharePoint - Part 3 - Scaling scrum

Introduction:  Scrum teams work best with relatively small teams (3 to 9 people) made up of high-quality individuals.  Scrum teams are made up of: a Scrum master, a product owner and up to 7 team members.  But in large enterprises or Software companies that deliver a large product, there is a need to use many more people to deliver working quality software.  Scaling Scrum is an option, and there are a couple of frameworks to help.  Agile and Scrum struggle to scale, this post outlines possible pathways to scaling scrum.  

PM's vs PO's: In smaller firms and projects, the Product Owner(PO)/Product Manager (PM) are often the same role.  In larger projects these are both key roles but with a very different focus.  PM are outward looking, know where the market is going, what do our customers want.  The PO's focus on what are the piece we will build internally.  For scaling I generally favor PO's have 1 or maybe 2 teams at the most.  I always want a single source of direction from PM.  So you can have 3-4 PO's for a single PM.  And often PM is a function consisting of several PM's. 


Scrum of Scrums (2-3 Teams)
By adding an additional event daily for key people from each Scrum team called a "Scrum of Scrums".  The meeting requires key stakeholders from each team to attend so that the integration between teams picks up dependencies, and ensure cleaner, easier integration.  Scrum of scrums is the simplest form of Scrum scaling and requires a 15-minute meeting that I follow: What we did, what we are going to do, and blockers from all attendees format.

Scrum of Scrums helps reduce the integration unknowns and ensure various teams can solve dependencies in a timely fashion.  The problem is there are diminishing returns as more teams get added, and this works well if there are 2 or 3 teams working on a single project and these teams self-organise.  In my opinion, more than three teams require a more robust Scrum-based framework like Nexus or SAFe.  Keep "Scrum of Scrums" meeting small with a technical scrum team member from the scrum teams.  I do them exactly like a daily stand-up Scrum meeting with technical items moved to the backlog.

Scaled Agile Framework (SAFe) (3 or more Teams)
My experience with Scrum scaling using SAFe while I worked with a big four consultancy firm and with several clients.  SAFe is the most popular approach for scaling Scrum.  SAFe is valuable, and like all these frameworks, it comes down to being implemented well.  SAFe is not easy to get working well.  Within product business with fixed scrum teams, it can work better.  It is a way for an organisation to be ready for Scrum and coordinate large projects to guide direction.  The product managers to product owners are often at sea with what they are trying to achieve.  SAFe focuses on Agile software delivery, Lean product development and system thinking.   The author here outlines that SAFe is for a way of scaling Scrum.  Program Increments (PI) are how direction is agreed for the next period (often a quarter).  Scrum owners get backlog items and then plan 4-5 sprints to get their portion of features/backlog items done.  SAFe only tends to work in my experience if "Organisation Readiness" (scope of work for the PI is reasonably clear and the priority of features is agreed, and the teams are ready to understand their sprint work items) is done before PI planning.  The diagram below shows the centre as Scrum teams and the other SAFe ceremonies' outer layer.  Beware, PI planning is challenging.





Note: Organisations can jump on the Scrum framework and try to make all teams scrum teams.  This can be great and is generally a good sign; however, beware of managers/management comparing teams spring volatility thru story points.  All the teams tend to increase their story points when compared, so they look like they are improving and beating other teams.  Focus on delivering quality in a trusted, rewarding team.

Note:  Using the same Scrum in every team is not ideal.  I like to let each team decide their rules and find their way.  The culture win from team members is where Scrum's value lies.  I like to leverage other frameworks like Kanban and story points.

Note:  I do like to have repeatable CI/DC tasks to be agreed across Scrum teams, even though the team may take longer, it works better from expertise and consistency in software delivery.  The point here is tune to match you requirements.


SAFe Levels
Source Alan Reed (with thanks)

Program Increment (PI) planning - 2 day event.  Day 1, have draft features and User Stories.  Al stakeholders are aware.  Day 2, team breakouts, confirm understanding and what can be achieved, finalist what is in th ePI, what are the risks and have confidence vote.

Nexus (3 or more Scrum Teams)
Nexus is for scaling scrum teams; I have never used it, but I like the thoughts and these guys know their stuff.  I like the concept of an integration team.  I have used this idea with floating team members with high degrees of specialization in CI/CD.  Having a central integration team ensures all the pieces come together for the deliverable.  Mixed with Scrum of Scrum meetings, the number of teams can be increased and for huge products having a central architecture/integration team is a great idea to reduce dependencies and ensure alignment from the various Scrum teams.

LeSS (Large-Scale Scrum) framework LeSS 

Disciplined Agile Delivery (DAD) extends Scrum

Summary:  Scrum works well for small Agile teams; once going over a single team, use daily Scrum of Scrum meetings to scale to two teams.  If the product is large, a dedicate architecture team that is responsible for build releases, integration of workstreams and overall architecture and using daily Scrum of Scrums to deliver allow for larger Scrum-based projects.  
  1. Small - Use Scrum (1 team)
  2. Medium - Use Scrum-of-Scrums (2-3 teams)
  3. Large - Use SAFe or Nexus (3 or more teams)
SCRUM Blog Series:

Wednesday 28 March 2018

TFS Scrum for SharePoint Projects

Great information on TFS for Scrum, Agile & CMMI from Microsoft.  My preference is to use Scrum with a couple of twists from Agile and external tooling.
https://docs.microsoft.com/en-us/vsts/work/work-items/guidance/choose-process

Tip:  I use User Stories extensively in SCRUM and with TFS all the testing and automation fits in brilliantly.  CI/CD is a choice between TFS build and TeamCity.  Also, my acceptance criteria are always written using gherkin language to ensure consistency.

Below are a few posts that are a couple of years old outlining Agile and Scrum for SharePoint projects:
Agile for SharePoint
Scrum for SharePoint - Part 1
Scrum for SharePoint - Part 2
Scrum - Part 3 - Scaling Scrum

Sunday 7 April 2013

Agile Software development for SharePoint


Overview

SharePoint 2013 brings new software development challenges to organizations.  Anyone architecting solutions involving SharePoint is faced with more critical decision points than ever before.  Traditional approaches to requirement gathering used on SharePoint projects, often include a long winded structure analysis phase.  It is expensive and difficult to get the relevant analysis clarified and Agile offers a different approach to working out what you are trying to achieve. 

The familiar IT Project Management Triangle gives one a clear visual representation of the constraints facing projects.  By using Agile management of projects can remove beaurocrartic redundant steps and focus on delivering what the customer is looking for.  This post provides an overview of using Agile methodologies such as SCRUM to help alleviate some of the problems we face when working with SharePoint 2013 development projects.


IT Project Management Triangle.
I am looking at SCRUM and Agile practices from a practical SharePoint delivery perspective.  SCRUM, like all methodologies, has it’s time and place.  SharePoint 2013 has many visual quick win so it is easy to get visual ideas in front of the end client very quickly in an iterative approach.

Supplementing project management with Agile practices and techniques to move a project towards successful delivery should overrule any historic dogmatic approaches.  

Methodologies

For simplicity, I break down the various software development methodologies into two main camps:

• The traditional approach that the Systems Development Life Cycle (SDLC) falls under and
• Agile Methodologies (SCRUM being the most common framework of Agile, other frameworks include Agile Kanban, Extreme Programming). 

SharePoint projects are all too often run using traditional approach that can result in “analysis paralysis”.

Agile methodology is implemented normally using an Agile Framework such as SCRUM which is by far the most popular framework.  As with anything, context is all-important.  The approach and techniques need to make sense to your organization and the project.  A good technical lead or Solutions Architect picks and borrows specific parts of different framework or methodologies when providing SharePoint solutions in order to give the best return for effort. 

Agile Manifesto, know the four values and 12 principles. 

4 Values:

  1. individuals and interactions over processes and tools;
  2. working software over comprehensive documentation;
  3. customer collaboration over contract negotiation; and
  4. responding to change over following a plan.

12 Principles:

  1. Satisfying customers through early and continuous delivery of valuable work.
  2. Breaking big work down into smaller tasks that can be completed quickly.
  3. Recognizing that the best work emerges from self-organized teams.
  4. Providing motivated individuals with the environment and support they need and trusting them to get the job done.
  5. Creating processes that promote sustainable efforts.
  6. Maintaining a constant pace for completed work.
  7. Welcoming changing requirements, even late in a project.
  8. Assembling the project team and business owners on a daily basis throughout the project.
  9. Having the team reflect at regular intervals on how to become more effective, then tuning and adjusting behavior accordingly.
  10. Measuring progress by the amount of completed work.
  11. Continually seeking excellence.
  12. Harnessing change for a competitive advantage.


SCRUM however, is gaining momentum as the defacto project management framework and should be a tool in your arsenal for SharePoint development.  Agile principles tend to skip some of the more formalized phases of SDLC and I am not suggesting that planning is superfluous; the trick for the technical development team is do not let process get in the way of building your product.

Experience has shown it is likely that you will face significant challenges in trying to implement SCRUM.  The team stakeholders may resist, your organization may resist, and the techniques may not be appropriate.  A simple and practical tip for overcoming these challenges is to try to find someone that can work you through the SCRUM process on suitable projects.  By bringing Agile practices to SharePoint development projects you can aim to reduce time, deliver what the client really needs and make software development more rewarding.  You don’t need to use every facet of a methodology, start with the easier options that will immediately add value.  As your SCRUM team maturity evolves add more pieces. 

Tip:  Microsoft Team Foundation Server (TFS) 2012 has 3 project management templates, one of which is the SCRUM template and this is a good place to start with minimal project management overhead.  The nice thing about TFS 2012 is you can easily amend these templates to suit your needs as your experience grows. 

Traditional approaches such as the SDLC often have a lengthy requirements gathering phase.  This long winded analysis phase is often ingrained into IT folks psyche that people find hard to break away from.  Projects involving a lengthy requirement gathering phase can easily suffer from excessive documentation if there is poor governance.  This documentation can be erroneous, contradictory, outdated, incomplete, challenging to follow and result in documentation overload. 
As a metaphor, SharePoint analysis is like the children’s game “Chinese whispers” or “Telephone” where one person whispers a message to another person, which is passed through a succession of people until the last player announces the message to the entire group.  This lost-in-translation is all too common as excessive noise in documentation or the analysts gloss over the expert’s main point.  Whereas a developer performing analysis generally picks up when something needs detailed explanation as they are “solutioning” the project as they directly communicate with the expert.
The more people in the chain, the more potential for errors in the relayed messages. Moreover, these business processes are often extremely complex, so that the actual intended meaning of the relayed message is lost.  SharePoint is a complex platform and even on the biggest of projects, the success of the technical delivery will often come down to a few key individuals.  Increasing team sizes does not often help and after a certain size becomes a real hindrance.  Agile teams work best when they are relatively small (SCRUM recommends team between 5-9 team members).  If the project is too big, get better quality people; don’t make the commonplace management mistake of adding more resources blindly.

Not all projects or SharePoint teams are ready to work within Agile methods however current commonplace SDLC approaches have problems we hear about repetitively such as change to software cost money and the SDLC is extremely inflexible, Agile based projects lend themself to change. 

Another argument is that that traditional methodologies can be used to give you fixed price quotes.  Vendors operating on a fixed price basis tend to promise the world and try cut every corner to deliver on time (and I hear the vendors screaming already “that is how the other vendors work not us”). 

Nevertheless, many of us realize that software consultancies operate work on the simple maxim ‘sell high, ship quickly’.  Once a software consultancy is in, the inevitable changes that will need to be made will cost the earth.  SCRUM can also run away but with the demonstrable iterations it quick to identify when you are off track and remedy the situation.  Agile methodologies use a time and material model whereas most financial budget decision makers prefer a fixed price (despite this being almost always wrong and they don’t seem to learn).     

Internal software teams often run over in time, deliver the wrong product and buggy solutions due to promises made based on poor initial guestimates.  SDLC can work if managed properly, Agile allows for better feedback controls to verify you are going in the right direction.

SharePoint projects often lend themselves to a ‘time-and-materials’ model as opposed to the ‘fixed-cost’ approach.  If you are unhappy with a project’s development, remove the vendor without the full budget being used up before discovering this project will be successful.  With SCRUM the team have to show you the deliverable product at the end of each sprint (2-4 week delivery phase) and replacing a team members is possible between sprints.

ALM for SharePoint 2013

SharePoint’s developer tooling has matured throughout the iteration of SharePoint.  Tooling is primarily based on Visual Studio and TFS.  ALM covers many roles with the team including project managers, testers, architects and stakeholders.  In this section I mainly focus on ALM for the developer.  Third-party tools assist with building the solution, communication within the team and technical guidance that easily plug into TFS and VS.  An example is CKSDev for Visual Studio.

Tip:  Visual Studio 2012 and TFS 2012 have a large number of purposes.  Always start with the basics of ALM and continue adding the more sophisticated features as your ALM maturity increases.   Source control is definitely the first important feature of TFS.  The next step would be bug tracking.  Build automation is about when you know you are really starting to get going properly with ALM.  With builds your developer isolate code is now integrated into the solution allowing verification of that the individually developed parts fit together.

TFS 2012 comes in 2 on-prem. varieties, don’t bother with the express edition.  It is free but limited to 5 users, if you are this small rather get a hosted TFS 2012 solution or use TFS preview.  TFS has an excellent web user interface portal, which is user friendly for team members that don’t necessarily use Visual Studio to enter Product Backlog Items (PBI’s).  TFS contains the following key components: source control, work items (PBI’s, tasks and bug tracking in SCRUM terminology), build automation and reporting. 

Visual Studio 2012 comes in 4 flavours as a developer you can use the Ultimate, Premium or Professional edition.  Depending on your MSDN subscription use the most feature rich edition you have available.  There is also a Test edition version of Visual Studio 2012 that is not suitable for development.

A good opinion on development machines is that each developer must have a completely standalone environment hosted on visualized PC/laptop infrastructure.  VMware workstation is a good option to provide this virtualized environment to developers.  The chapter in this book on DTAP and automation strongly examines setting up the SharePoint developers’ development environment.  Using automation builds are triggered by developers or are schedules using FSP policy, these builds can include smoke test or full testing scenario allowing for high levels of confidence in that the build work correctly.

Microsoft tooling for SharePoint is good and wide ranging.  Starting with Visual Studio 2012 there are item templates for achieving common tasks.  The community writes many Visual Studio Extensions such as CKSDev.  Consider adding this to the developer machine base builds so when the image is rebuild or the images are distributed the developers are up and running quickly.
Code needs to be in a source code repository such as TFS 2012, using the SCRUM template is the good option.  At the most basic level it allows for easy management of the project using the SCRUM template with the appropriate reports with a source code repository and bug tracking facility.
Assembling all the constituent parts of your SharePoint project using the build functionality available through TFS allows you to have confidence that it all works together and can be deployed into production accurately. 

Build tab within the SCRUM template.
 Build process templates are used for automating the build in TFS.  The figure below shows the default templates.

Built in Build Process Templates
Daily automated builds are a good idea to ensure code is working against your automated tests.

Tip: Don't build your daily automated SharePoint 2013 environment from scratch. Rather use snapshots or cloned images for the base images and merely deploy and test your code through automation.  Chris O’Brien has good information on Continuous Integration for SharePoint check out his blog. 

PowerShell is your friend.  Automate everything in the build.  This allows team members to get the latest code and setup the appropriate databases quickly - the invested time pays for itself almost immediately.  The developers will often use a baseline content database so they know that they have the correct test data.

ALM allows for easy migration onto your Development, Testing, Acceptance and Production (DTAP) environments.  Automated of deployment pieces bring efficient delivery through to the production environment.  I can't stress enough that you need more environments than development and production.  Even the smallest project should have at least three separate environments and remember to keep the production and staging (also referred to as pre-production or acceptance testing) in sync.

Summary

SCRUM is a commonly used Agile framework for delivering projects.  SCRUM lends itself well to a lot of SharePoint projects as it allows for focused collaboration.  Product feedback is on-going and the team demonstrates the project sprints in multiple short iterations to the business which ensures the projects direction is focused.  SharePoint 2013 is a complex product and having smaller teams with superior resources can greatly improve returns. Agile does not mean no documentation, it advocates using a bottom-up self-managing team that is organized.  Agile is not anarchy but allows us to focus on business problems creatively utilizing all team members aiming to work together to manoeuvre SharePoint to meet business needs.  Agile and SCRUM try move away from overdrawn project analysis phases.

Microsoft has a 1st class stack of ALM tools for SCRUM comprising of Visual Studio 2012 and TFS2012 that hook nicely into SharePoint 2013 development projects.  TFS is not just for developers, it can be used by the whole team.  TFS has source control for your code as well as a plethora of features to help your SCRUM based projects such as the SCRUM template, reporting/ project management, requirements and acceptance gathering artifacts, the ability to automate your solution via the build process templates and testing.

Agile for SharePoint (This post)
Scrum for SharePoint - Part 1
Scrum for SharePoint - Part 2
Scrum - Part 3 - Scaling Scrum
Scrum - Part 4 - Kanban and Scrum
Scrum - Part 5 - Certification PSM 1

Monday 10 September 2012

Scrum for SharePoint - Part 2

See Part 1

Technology: I am using Team Foundation Server 2012 Release Candidate.  I believe the best tools for the scrum team are offered through Visual Studio. VS 2012 has all the features and VS2010 can't do specific tasks such as create projects however I've found using VS2010 to work well.  The template used in TFS is the Visual Studio Scrum 2.0 template.   Also see http://channel9.msdn.com/Events/TechEd/NorthAmerica/2012/DEV212

Ways to work for TFS:  VS has the most comprehensive feature set for working with TFS 2012.  You can also use the TFS web UI, the SharePoint Foundation UI that is hooked up to TFS or excel and then import the data.


Creating PBI's: The screen shots use TFS2012 RC & VS2010.  I have annotated the screenshot to help with input of PBI's.  Not the priority is set from 1-1000 (default is 1000 which is the lowest priority).  I like to use Mike Cohan's planning poker (uses a relative Fibonacci sequence number to assign relative effort weight).  The scrum team vote on estimated effort after an understanding of the user story is complete.  Optional. Free tool to use for planning poker   Try this, a friend of mine built this while playing around for Scrum Poker Planning. 

The scrum master has to accept the PBI and for me to do this I need 3 pieces of information namely: the user story, acceptance criteria & additional detail short clear information such as an annotated Balsamiq mock-up.  Obviously the product owner  may negate the need for additional information but often they need to get this information from someone else in the business and I find mock-ups invaluable for clarifying to all people visual requirements.  Lastly, ensure that the team understand INVEST principles for  (Independent, Negotiable, Valuable, Estimat-able, Small, and Testable) for each User Story/Requirement.

Acceptance criteria is needed for each PBI.  This would be good to have in the Sprint planning meetings.  This is the format I recommend (gherkin language).
Scenario:
  Given
  When
  Then

An example I have is
Scenario: Employee requests leave
  Given an employee has sufficient leave available in the year
  When the employee schedules leave (holiday)
  Then the employee is informed his request is valid and his manager is informed of the request.

Acceptance Criteria – “What is Acceptance Criteria? Put simply, it's the criteria that defines what "Done" means for each PBI. Acceptance Criteria is critical to the success of a Scrum team, as it becomes the handshake between the Product Owner and the team -- it helps define what the team is committing to.”  http://www.nomad8.com/files/acceptance_criteria.php
"Pre-established standards or requirements a product or project must meet" Google's definition of acceptance criteria.
Normally acceptance criteria focuses on functional user stories but you also need to cover NFR's such as performance.  Negative acceptance criteria is often overlooked when creating AC's and do the AC's before development starts, you can always change them later.
An alternative to Gherkin for writing the acceptance criteria is to use checklists to ensure the User Story does what the business stakeholder wants and the developer has developed it correctly.

(Story Board)

The TFS 2012 Scrum template provides a good overview of the current sprint.  Team favorites are dropped from TFS queries to provide useful insights into the project.


Key Meetings:

1. Daily Stand-up (max 15 minutes):  I like to perform these at about 10:00 every day in the morning.  Each person tells the group: done/achieved in the past 24 hrs, what they are doing in the next 24 hours and brings up any blockers/obstacles/impediments.  I like to take notes as the scrum master and as the team falls into place.  I let team members run the daily stand-up scrum meeting in random turns once we all know how to do them and it seems to work well with communications in the team and I take summarized notes and I use the format:  Date, Time, Attendees, Each attendee summary & general meeting notes:  e.g. Adam and Paul were late for the meeting, blockers were not recorded, Kanban board was not updated....
Rules: Start at 10:00, be concise (part items that are taking to long and get the people to talk after the meeting), all participants to stick to the format: last day, today and blockers.  It always ends at 10:15 and leave the area.  Listen to the appoint meeting scrum master and they need to stop ongoing discussions.

2. Demo Meetings:  Date, time, attendees & roles, problems & suggestions.  Do at the end of sprint, tend to be 30 minutes to 90 minutes per demo each sprint. 

3. Sprint Review Meeting: Done at the end of a sprint cycle after the sprint is over.  Ensure each PBI is reviewed.  Often used with demos to validate each PBI and this allows the Product Owner to evaluate the PBI's fulfillment and make changes if necessary.  Important but can be skipped by the whole team as long as the PO does it and is happy.

4. Sprint Retrospective Meeting: Optional meeting to identify improvements that can be made.  I use this meeting after the Sprint Review at the end of the 1st 2 or 3 sprints and then only periodically as the project progresses.  Tip: Use the format: Glad, sad, bad game.  https://app.scatterspoke.com for managing Retrospectives.  An alternative is to the approach: What went well, What didn't and What needs to happen.


I've seen many different formats for running retrospectives, and a good default option for me is "mad, glad, sad". I also like the Danish baking Retrospective that I saw recently.  
Azure Devops Danish Baking Retrospective Board

A nice feature I was shown recently was to "Include a Team Assessment".  I'd use it every 3-4 sprints assuming we are using 2 week sprints, the results are a great indicator of confidence and the teams position.
Team Assessment in DevOps Retro board 

5. Sprint Planning Meeting:  Have a sprint goal.  Done at the start of the sprint cycle.  The scrum team and the product owner identify items from the product backlog to go into the sprint.  The last part of the meeting is to create a sprint backlog to implement each item selected from the product backlog.  I also like to have a grooming of stories in the previous sprint to ensure the whole team know what is likely to come along and tech can feedback to the PO/stakeholders.

Agile for SharePoint
Scrum for SharePoint - Part 1
Scrum for SharePoint - Part 2 (This Post)
Scrum - Part 3 - Scaling Scrum
Scrum - Part 4 - Kanban and Scrum
Scrum - Part 5 - Certification PSM 1

Sunday 1 July 2012

Scrum for SharePoint - Part 1 Introduction

Overview: Scrum is an Agile methodology that is useful for SharePoint projects as it allows for discovery/refinements of requirements as opposed to formally knowing all the functional requirements of a system upfront.  Each project lends itself to specific methodologies however, an Agile approach is often more suitable for SharePoint projects.  For larger, more formal projects I like MSF but traditional SDLC methodology run projects also work well.  Scrum is one Agile methodology and probably the most commonly used.  As with all projects I recommend following a methodology but lend from other and take out what isn't working to get the optimal process.

Scrum for Dummies:  Scrum consists of 3 types of team roles: the product owner/s, scrum master and the rest are team members.  Tam sizes should be less than 7-8 people (if bigger use scrum of scrums).
1.) The Product Owner is responsible for creating user stories.  These are specified in the form: As the <role> , I want to <feature> so that <benefit>.
2.) From the User stories I create Product Backlog Items (PBI's), Scrum is broken up into sprints (usually 2-4 weeks).  The sprint kicks off with a Sprint planning meeting that involves the entire team.  PBI's are broken down into tasks, tests and bugs.  During the sprint planning, the team members commit (renamed to forecasting in 2016) to the PBI's in the sprint and creates a "Sprint Goal".  I usually set apart 3-4 hrs to complete the Sprint Planning session at the start of each sprint.
3.) Daily scrum meeting takes 15 minutes facilitated by the scrum master.  Each team member states what they accomplished in the last day, what they will be working on in the next day and any blockers.  When the team members start a discussion, shelve it and they can have a separate meeting outside the scrum to avoid over running on the scrum meeting.  Do scrum meetings standing it helps make the sprint/team finish on time.
4.) At the end of each sprint, there must be a potential deployment.  Hold a scrum retrospective, this is to work out the team velocity (are the PBI's and features being achieved) and work out how productivity can be improved.
5.) Documentation:  Scrum is not document intensive but aims to get features right not finish at a specific point.  The documents generated by scrum are:
5.1) User Stories and corresponding Acceptance Criteria
5.2) Meetings (Daily scrum minutes/decisions, sprint planning agreements/outcomes & retrospective minutes)
5.3) Whiteboards (architecture diagrams and user story refinement)
5.4) TFS recorded data 
5.5) Communications (emails about decisions, supporting information, this could also include pptx from presentations, user reviews).

TFS:
  • SharePoint has a lot out of the box and using Scrum allows for better technical decisions whereby team members often identify OOTB solutions which hopefully eradicates the common developer mentality of using .NET to do existing SP functionality.
  • There are Templates for Scrum download and base your project off them.
  • Microsoft offer a great free services called TFSPreview (http://www.tfspreview.com/) which is a SaaS offering TFS 2010, doesn't have all the features but it is amazing and best of all it has a built in Scrum template so I'd always start with this and if you feel you are being to restricted you can always go for a on premises option. VSTS (cloud service) is the current name for TFS preview Oct 2017.

Agile for SharePoint
Scrum for SharePoint - Part 1 (This post)
Scrum for SharePoint - Part 2
Scrum - Part 3 - Scaling Scrum
Scrum - Part 4 - Kanban and Scrum
Scrum - Part 5 - Certification PSM 1

Saturday 31 July 2010

Best Practice Sharepoint 2010 coding tips

1.> SharePoint Dispose Checker Tool - Run the SP Dispose Checker Tool on all custom code you write.
SPSite & SPWeb object has a big load and we need to ensure dispose is always called. 2 easiest ways to ensure Site and web objects are always disposed are shown below:
SPSite site;
try
{
site = new SPSite("http://demo1"); // Create the SPSite object
...
}
finally
{
if (site != null) // Check if the SPSite object exists
{
site.Dispose(); // Clean up the SPSite object as it has not be disposed of
}
}

Alternatively I prefer to use using statements
using (SPSite site = new SPSite(http://demo1/))
{

.... // SPSite.Dispose method will be called always
}
Run the SPDisposeCheck tool on all code before deploying outside of you development environment, this can be automated into VS 2010.
2.> Have at least 3 environments i.e. don't send code from the developers machine straight into production. Sandboxed solutions alleviates this risk to some degree but use a UAT, pre-prod, QA environment. Your deployment environment must mimic production as closely as possible i.e. ensure there is a separate SQL DB, all versions of software are identical, load balancing is setup. Have documented change control. Try perform changes through scripts not manual changes if possible. Web.config changes need to be replicated to all servers on the farm so doing the change manually is not the best option. Change the web.config via code to ensure it is done through the configuration database so they are changed on all web.config's in the farm.
3.> Error handling, catch errors as specifically as possible, die gracefully and appropriately, log the errors, check the production error logs periodically.
4.> Deploy code using wsp solutions. Ensure code is not in debug mode when compiled, it runs slower and potentially can crash/holdup your production environment. Implement CAS, deploy to bins if possible and apply CAS security policies to custom coding. Perform peer code reviews, it ensures coding standards are being followed, developers learn from each other, bugs are often picked up pre-testing and it increases team members knowledge that reduces maintenance costs.
5.> Develop using source control no matter how smal the dev project is. Preferably TFS 2010 but VSS 2005 is even fine, failing this use CVS, IMB/rationals ClearCase for source control. Also have bug tracking with TFS the integration is excellent between the bugs and the source control. I.e. use TFS if possible.
6.> SharePoint projects are often very good candidates to SCRUM or other agile methodologies. Use them if it's appropriate. Traditional formal SDLC / waterfall approaches tend to work well on the larger SharePoint projects.
7.> Use the developer dashboard.
8.> Unit testing - don't test SharePoints API, test your custom code. In MOSS Type Mock isolator was a great product for SharePoint I presume this is still the way to go. Andrew Woodward is a good blogger on SP unit testing.