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:

Sunday, 11 August 2019

Send email using O365 in an Azure Function C#

Create an Azure Function and the basics for send an email are below:

MailMessage msg = new MailMessage();
 MailAddress("", "SomeOne"));
 = new MailAddress("", "Paul Beck");
 = "This is a test message using <b>O365</b> Exchange online";
msg.Subject = "Test Mail";
 = true;
 client = new SmtpClient();
 = false;
 = new System.Net.NetworkCredential("your user name", "your password");  // Generate a key so pswd does not change or if account uses MFA
 = 587; 
 = "";
 = SmtpDeliveryMethod.Network;
 = true;

Tip:  Azure SendGrid is a great service for sending out emails.  Amazon have SES (Simple Email Service).

Sunday, 4 August 2019

Scheduled Tasks Options

Problem: Fire off code on a regular interval.

Hypothesis:  Generally code needs to be triggered and that is either thru an action such as an HTTP trigger or time based e.g. every 30 minutes run a job.  Overf the years I have seen many time based trigger mechanisms such as:

Scheduled Windows Tasks that are set to execute on a time base pattern.  Generally ends up calling a command.  Benefits are that nearly any IT department will have a VM or allow scheduled tasks to run.  

Control-M from BMC is  the next step up, basically allows for tasks to be scheduled and the jobs are monitored and can trigger alerts.  So with a scheduled task, you would need to check manually or write code to do the checking and alerting and storage.  JAMS fills a similar gap as Control-M in some organisations.  There are several competitors that have been around for years so always best to check with the client what there policy is for timer jobs.

Hangfire is for .NET and is more advanced and programmable so a good option for background tasks.

Team City - sledge hammer to crack a nut.  Tasks can be scheduled and fired off.  Useful for complex orchestration tasks with dependencies.   Jenkins and other CI/CD tools are in this group.

Old SharePoint had Timer Jobs - can't see this being of any use.

Azure Functions using a Timer Trigger for my is my first choice unless I am restricted at the client for some reason.