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.