OAuth for Custom Connectors

Problem:  I have an APIM end point that has both the subscription key and OAuth2 setup for security and I need to connect Power Apps.

There are basically two parts to this problem, setting up your Power App to use OAuth and then also passing in the subscription key on every APIM end point request.

• This post assumes that both the APIM App registration and the Client App have been registered on Azure AD.
• Check with postman can access the end point as shown below.  Postman will authenicate and use the bearer token (OAuth) and the subscription as shown below to test

Client ID: 5559555-555a-5558-5554-555d4
Auth URL: https://login.microsoftonline.com/555fd555-555f-5554-5551-555b444c3555/oauth2/v2.0/authorize
Token URL: https://login.microsoftonline.com/555fd555-555f-5554-5551-555b444c3555/oauth2/v2.0/token
Refresh URL: https://login.microsoftonline.com/555fd555-555f-5554-5551-555b444c3555/oauth2/v2.0/authorize

We now know the APIM is working with OAuth and the subscription key.

Configure OAuth from Power Apps:

• Once Postman can get valid 200 responses using OAuth2 and the subscription key, setup the custom connector.  I could not get the Azure AD connector to work so i used the OAuth connector as shown below: 

Add a policy that will add the subscription key to every https request to the APIM/resources as shown below.

Updated 2 Feb 2020 - Example of custom OAuth code flow authentication for a custom API's using AAD security.

Note: Deploying Custom Connectors in solutions always seems to be an issue.  It is a good idea to keep all connection references in a separate Power Apps Solution.

Flutter vs Xamarin vs React Native vs PhoneGap

Overview:  As a solution architect and CTO I need to choose the right approach to help our clients select the correct technology and approach to delivering solutions.

Flutter vs React Native vs Xamarin

My History of Building Mobile Applications:

• Originally, building mobile apps required building two code bases generally for Android and iOS in their own language.  Xamarin also allows you to write in C# for a specific platform.
• Next came a single code base that compiled down into each native platform (Droid and iOS), then we would customize for each platform.
• I like Xamarin Forms as I want native apps with a single code base (C#).  One can also write separate code bases for each of the 2 main mobile platforms. 
• React Native is built using Facebook's ReactJS library.  React Native like Xamarin Forms uses a single code base that compiles a iOS and a Android app.

• Note: An alternative around this time was to use HTML5 with PhoneGap and deploy to both mobile platforms, native controls could be used but this was once again a split in the code base.

• Flutter is the newest of the options.  Flutter is from Google and uses it's own DART language, it then can be compiled into various formats including iOS and Android.  Flutter goes back to the single code base that pushes native apps to multiple platforms.  Including the Web.  It is fast, looks good, great native interaction.

More Info: 

Flutter vs React Native - 

Alex Zubkov - 6Aug 2020

Basics of Flutter

Overview:  Flutter is a UI toolkit built by Google used to create native mobile applications (and web sites (Hummingbird)) using a single code base.  Historically, I have tried to keep a single code base in the front end using Angular, KO or ReactJS for my websites and used PhoneGap to build pseudo native apps on Android and iOS.  This allows me to have a single code base and also deploy to Droid and iOS with minor tweaks on PhoneGap.

Tips:

• There is a Flutter add-in for Visual Studio Code.
• Flutter uses "Dart" as it's programming language.
• Dart is a strongly types object orientated language that compiles into JavaScript for websites, and "natively" for iOS and Droid.
• Also can compile code for native Windows, Mac, Chromebook.
• Everything is a Widget (layout widget, elements e.g. image, text, or a gesture widget (listens for actions like a tap)),
• Add widget together to make a custom widget,
• Widgets are either stateless e.g. picture or stateful e.g. textbox
• import the material.dart to provide basic building blocks

The more I see of Flutter, the more I like it.  It is quick to build mobile apps and looks fantastic.

Cons:

• Pretty new & hard to find skills
• Slightly bloated on a native app - not noticeable to end users

Basic Environment setup:

1. Surface Windows 10 Pro
2. Visual Studio Code
3. Flutter SDK
4. Android emulator (I didn't setup iOS)
5. Android device to load the package to try it out on a phone

Emulator Running using Flutter

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)

Azure DevOps User Storing Tips

C# to connect to SFTP Server

Overview:  This is a quick way to connect to an SFTP server programmatically.

Steps:
1. Create a C# project in Visual Studio, I used VS2019 and .NET core in this example.
2. Add the SSH.NET Nugget package to the project as shown below

3. The code snippet below is to simple to explain, you not they I'm using the SftpClient class from the Renci.SshNet Nugget package to do the Sftp file transfer.

Azure blob storage supports SFTP, you can use cheap/redundant blob storage and accepts SFTP - secure, cheap way to setup the server side of SFTP.

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

Azure DevOps User Storing Tips

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.

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:

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

Azure DevOps User Storing Tips