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.  Basically, 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 a lot more people to deliver working quality software.  Scaling scrum is an option and there are a couple of frameworks to help.

Scrum of Scrums
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.  This is the simplest form of Scrum scaling and requires a 15 minute meeting that I follow the: What we did, what we are going to do and 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 is 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 3 teams requires a stronger Scrum based framework like Nexus or SAFe.  Keep "Scrum of Scrums" meeting small with a technical scrum team member from each of 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)
This is not an answer to Scrum scaling, I worked with a big four consultancy firm using SAFe and while it is useful and forward thinking, it really does not work well with dedicate Scrum teams. it is a way for an organisation to be ready for Scrum.  SAFE focuses on Agile software, Lean product development and system thinking.  Basically it is for an organisation to be more Agile but it is not applicable to Scrum except in contrived cases generally where senior management are trying to make a perfect answer to problems they do not comprehend.  I disagree with the author saying SAFe is for a way of scaling scrum, for me SAFe is not a way of scaling Scrum, but i think the article is a good read.
Note: Organisations can jump on the Scrum framework and try 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 own 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.

LeSS (Large-Scale Scrum) framework LeSS 

Disciplined Agile Delivery (DAD) extends Scrum

Nexus
Nexus is for scaling scrum teams, I have never used it but I like the thoughts and these guys know there stuff.  I really like the idea 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 ensure all the pieces come together for the deliverable's.  Mixed with Scrum of Scrum meetings, the number of teams can be increased and for very large products having a central architecture/integration team is a great idea to reduce dependencies and ensure alignment from the various Scrum teams.

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/programme is large, a dedicate architecture team that is responsible for build releases, integration of work streams and overall architecture and using daily scrum of scrums to deliver allow for larger Scrum based projects.

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

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();
msg.To.Add(new
 MailAddress("someone@somedomain.com", "SomeOne"));
msg.From
 = new MailAddress("you@radimaging.co.uk", "Paul Beck");
msg.Body
 = "This is a test message using <b>O365</b> Exchange online";
msg.Subject = "Test Mail";
msg.IsBodyHtml
 = true;
SmtpClient
 client = new SmtpClient();
client.UseDefaultCredentials
 = false;
client.Credentials
 = new System.Net.NetworkCredential("your user name", "your password");  // Generate a key so pswd does not change or if account uses MFA
client.Port
 = 587; 
client.Host
 = "smtp.office365.com";
client.DeliveryMethod
 = SmtpDeliveryMethod.Network;
client.EnableSsl
 = 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.