Collaboration, Power Apps, Power Automate and Power Automate Desktop are not phrases that fit together perfectly right now. Steps are being made to introduce collaborative commenting across the power platform as well as Git version control but at the time of writing, the options for Collaborating on the build steps of a Canvas App based solution are limited.
Working together on an app is a common need but one that takes some careful thought to get right. In this post, I'll share how Connor Deasey and myself grappled with 3 of the key challenges in planning a Power App for our team to use.
Step 1 - Deciding to use an Agile approach
WHAT and WHY? are 2 of the first questions to ask when planning an app. It's where most teams will start. Comprehensive planning and up-front requirements work can be done if you know exactly what the app needs to do and those needs are unlikely to flex or change. However, I come from a background where adapting to changing markets and demands is the norm. Adopting a more Agile approach to planning seemed like the right fit.
In my experience - I don't lay claim to this phrase by the way, but it is more often true than false - "Plans rarely survive first contact".
So instead of spending masses of time deciding what we would build in the app, why each element was important and where it should be positioned, Connor Deasey and I spun up our version of 'Sprints'.
Our approach was to find out 'enough' about the major use cases to load up our Product Backlog with core items we needed. They were ordered in such a way as to represent key goals along the way to delivery.
Once we had done that, we set out our first goal for the next 2 weeks - to "launch a working (if somewhat rough) app prototype". This would be our MVP (Minimum Viable Product) that we could use to gather feedback and iterate on top of quickly.
We found this approach worked very well for us. It allowed us to collaborate as much as we needed with people who would use the Power App and proceed at pace whilst not getting bogged down in too much detail every step of the way.
Any features or decisions we encountered that were not part of our current Sprint backlog, we placed into the Product backlog to be reviewed and refined before the next sprint. We could then dynamically decide what the next sprint might look like before planning the iteration.
As we were learning all the time - and experimenting - this approach worked very well for us. It kept us flexible to new suggestions but also gave us a clear focus for the time-period we were aiming at for our releases.
Step 2 - Creating a Look and feel for the app
Whilst it's important to have a clear idea and vision for the overall app feel and form. Spending too long designing the app could be wasteful. So again, leaning towards our agile roots, we mocked up how we thought the app could look. In the past, we have used Adobe XD but for this example, because the screen real-estate was quite limited, we just used an online collaboration tool called Miro (more on that later)
Pro tip
Spend Time Planning the UI
If you want to dig more deeply into planning, prototyping and using tools to support your User Interaction planning, here's a link to a great live stream one of our team did which focussed on interaction design. Enjoy! https://www.youtube.com/watch?v=DZYoOf1NuF8
Our premise is always to 'let the data breath' so we didn't over clutter our initial screens.
This unlocked a build challenge - how to span a form over multiple screens. Our solution to that is covered in the Solutions Day session on 18th Jan 2022.
Once we had the basic form and color pallet, we had enough to start the build process.
One thing we learned - again re-enforcing the idea that some planning is great but a lot can be wasteful - is that although our ideas were solid to begin with, there is nothing like putting a working version in front of users to gather feedback. When we did this, lots changed and was improved but that was expected and welcomed as we refined and improved our vision.
Step 3 - Planning the work using Miro
Connor and I planned to work on the app together. However, there were multiple components and multiple crossover points in the design (between our data store - SharePoint - power Apps and Power Automate). We also knew that 2 people cant work easily inside a Power App concurrently right now so our options for co-authoring were limited. We could pair in the build but in reality, we felt that wouldn't provide as rapid a learning opportunity for us both as we wanted.
So we decided the best approach would be to split our workload based on components of the overall architecture.
To help us with this, we jumped over to Miro.com (one of my favourite collaboration tools).
As you can see from the inset image, our approach rested on getting a rough layout for the architecture of the app. From there, we could discuss the pieces and decide how to approach it.
Remembering in the first iteration, we were focussing on a basic end-to-end operation for the app, we set about creating our first thin slice.
We agreed to work on areas based on the colors of the post-its and marked work as complete when we had done enough. This isn't the traditional 'Kanban-style' board teams often used but it worked for us.
Instantly, we could see where we were up to in the sprint, decide if we had gone off track at our stand-ups and progress together making important decisions as we progressed.
As you can see, whilst we didn't follow a traditional waterfall or scrum framework for our planning, we chose what would work well for us and allowed us to proceed at pace. We selected the tools that gave us 'enough' and proceeded based on the principle of showing often, being open to change and iterating quickly.
The result was that inside 2 sprints, we had managed to build and test pretty much all of the functionality we needed for the app. We had tested our assumptions in mini-sprint reviews and got it to a point where the whole team could use it and continue to provide feedback. That's the beauty of being a citizen developer!
If you want to find out more about our app, how we built it and some of the challenges we overcame, head on over to our Solutions day session on January 18th 2022 to hear from us directly. (On-Demand recordings will be available if you didn't catch us there!)
