There’s a lot of talk about software delivery methodologies these days. To those not constantly reading the latest 400+ page textbooks on methodologies, it can be quite hard to keep up.
Agile methodologies such as Scrum can be great, but to work optimally they require a fair amount of education for all stakeholders involved, which is not always practical. Waterfall is considered by many as old hat, but lots of successful projects are still delivered this way. Hybrid methodologies can also work and can work practically and commercially. What is more important, across whatever methodology you use, are the techniques you use as part of these methodologies to define solutions and deliver real business outcomes.
There is a technique that I like to use which is ideally suited to Dynamics 365 and the Power Platform. It’s a great technique because:
- It helps you gather real requirements aligned to the technology. We shouldn’t pretend to understand what someone else is imagining about a technology they have never seen before and try to make it fit.
- It starts you thinking about the end-game very early in the process.
- It helps you learn new technologies and capabilities as they are released.
- By virtue of this techniques name, you are setting the bar quite low, so risk of embarrassing yourself is minimal (although conversely, partial failure here may be a very good thing).
- It can provide valuable insight into estimates for future tasks.
It’s called the Shitty First Draft, hereby referred as an SFD.
What is an SFD?
Anne Lamont wrote about SFDs from a purely literacy and non-software perspective in her book ‘Bird by Bird – Instructions on writing and life’ (excerpt)
“People tend to look at successful writers who are getting their books published and maybe even doing well financially and think that they sit down at their desks every morning feeling like a million dollars, feeling great about who they are and how much talent they have and what a great story they have to tell; that they take in a few deep breaths, push back their sleeves, roll their necks a few times to get all the cricks out, and dive in, typing fully formed passages as fast as a court reporter. But this is just the fantasy of the uninitiated. I know some very great writers, writers you love who write beautifully and have made a great deal of money, and not one of them sits down routinely feeling wildly enthusiastic and confident. Not one of them writes elegant first drafts. Alright, one of them does, but we do not like her very much. “
If you are involved in software development, you may have heard of the concept of a Minimum Viable Product (MVP). An MVP is a piece of working software that delivers just enough functionality to production to satisfy early users and which provides feedback for future product development.
Similarly, an SFD is a piece of software that, when demonstrated in a non-production environment or used during an analysis phase, delivers just enough functionality to get users thinking about what their real requirements are. It provides an opportunity to get users past the first bump on the Kubler Ross Change Curve, so that users can move past the shock and denial phase. It helps people to think about all their spreadsheets and existing systems and painful processes. The act of completing and demonstrating an SFD should (try to) spark motivation and become a springboard for defining requirements and delivering robust functionality aligned to the power platform.
When should an SFD happen?
Ideally, it should happen after a high level of requirements gathering has taken place, especially when you are working with users who have never been exposed to the Power Platform or Dynamics 365 applications before.
With the Power Platform and Dynamics 365, we are not building products from scratch for end users. New users specifying requirements shouldn’t have the same control they may have had when specifying requirements for previous completely bespoke implementations.
It’s important for end users to be shown the art of the possible as early as possible. Some people call it smoke and mirrors, others call it vapor-ware, but to me, the ability to show early is one of the key strengths of the platform. Why should you spend a day doing a Balsamiq Mock-up or a Visio of a Dynamics 365 or Portals screen to go into a lengthy word document, when you could build a similar (semi) working Power Platform prototype in the same time.
Why are SFDs useful?
Those of you who have worked in pre-sales may well be great at doing SFDs already. However, for those of you who also need to deliver working software in production some weeks or months later, an SFD is also vitally important to ensure that you work out the optimum method of how to deliver business benefits to your customers. An SFD should help you think about screen and User Interface and about how you need to define your entity data model. It should help you define a roadmap and provide you with questions for future follow up with key stakeholders.
My Guidelines for Power Platform SFDS
- Don’t go in completely blind. If you have a new client, do an initial high level of research on their business activities. This might be reading a requirements document or talking about high level goals and business drivers with key stakeholders. Ask for existing spreadsheet or screenshots or access to existing systems of record.
- Once you have some high-level context, just start building or configuring. Use a pre-canned Dynamics 365 trial at demos.microsoft.com to get started very quickly.
- Write down what you don’t know as you go. This is a key output.
- Set a time limit – typically between 3 hours and 3 days depending on your level of experience or maturity.
- Try configuring something you’ve never tried before – for example a flow or new feature. It should be a learning experience for you too. New features are being added to the Power Platform all the time.
The SFD excludes:
- Any clean-up. If you do something wrong like add a wrong field, leave it there unless it’s a blocker or move it to the bottom of the screen.
- Isolation. Arrange to show it to someone and talk through it. This could be a colleague or a friendly customer.
- Any negativity. If it truly is shit, scrap it and move on, rework and learn from the experience.
What happens next?
The output of an SFD may be:
- A blueprint of good decisions you made that will work in production.
- A list of bad decisions you made that don’t work.
- Licensing considerations – looking at the components you have used aligned to the total number of users.
- Users will have informally received initial familiarisation training.
- Another draft
How many drafts should I do?
This will depend on your overall delivery methodology. For waterfall projects, you may have learned enough to deliver a design document that you can stand-over with confidence, which will de-risk what may have otherwise been a risky build phase in a fixed price project. You may need a second draft or some subtle tweaks. For Agile Projects you might follow it up quickly with further drafts.
If you are lucky however, as Anne Lamont says, you may even achieve clarity in your second draft and brilliance in your third!
Brian Illand 
This is a really good argument for why/when to use PowerApps in the early phases of a project. Thanks for introducing me to the Kubler Ross curve.
My wife is a teacher and politely calls it a “sloppy copy”. 😉