No-Code Project Management
No Code Projects do not give you an excuse to abandon project management
We have all heard about “waterfall” Project Management, Agile Project Management, and Hybrid Project Management, but how do you manage a No-Code Project where the development is more like configuration and might, in the most complex scenario, require advanced formulas, multiple layers of mappings, and workflow?
You won’t find a lot written about these sorts of projects in the traditional project management journals and blogs, but I can tell you from my own experience, these projects need to be managed in a structured fashion.
In several of my other posts in BlueProject (for example Made Up Agile), I’ve shared my displeasure when organizations and teams try to stuff whatever project they’re doing into an Agile structure, and I still don’t think it makes sense to blindly decide your project should her managed using Agile principles just because everyone seems to be doing Agile right now.
I do believe, however, that many No-Code projects can be managed using Agile techniques, specifically using the Agile Scrum Way of Working (See my post on Project Methodology in 2020 (Part III): Disciplined Agile? for an explanation of Ways Of Working (WOW)). I would argue that with No-Code Projects you can expect many of the same deliverables that you would expect out of a typically code intensive Agile Scrum project. There will be some obvious exceptions to this since, for example, Continuous Build Integration using automated build processes, etc. will not be relevant, at least in a literal sense. That said, you should definitely have a strategy of version management and ensuring that you can rapidly deploy the latest version of your solution.
For a typical No-Code project, you can follow a very Scrum-like process flow as described below:
- Define simple Solution or Product Features using User Stories and Epics, and I also recommend at least simple Use Cases (more discussion on this below).
- Features get added to the Solution (or Product) Backlog.
- Sprints are Planned and Feature Implementation estimated as Features are added to the Sprint Backlog.
- Sprints are Executed and Sprint Reviews are conducted.
- And Features are Implemented and deployed to the current version.
You can also add Sprint Retrospectives, and Ceremonies, etc., if you like, but the basic flow, above (items 1–5), is the minimal set of activities you should ensure you never compromise.
No-Code Scrum sounds a lot like code-intensive Scrum, doesn’t it?
Use Cases to the Rescue
Perhaps the one major limitation of using Scrum for No-Code projects is that in code-intensive Scrum projects there will almost certainly be component design activities. These design activities tend to drive out a better understanding of functional, data, and technical requirements. In No-Code projects this may not be the case at all. As a result, the quality of what is produced by No-Code Projects can vary widely.
This is where Use Cases can really come in handy as a way to better structure Feature deliverables. In particular the User Goal Level Use Case (see Alistair Cockburn’s excellent book on the topic: Writing Effective Use Cases ) is a great way to flesh out more detailed functional requirements that you would have had to understand to design a module to do something, but such understanding might not be a prerequisite to configuring something on a No-Code project. So make it a prerequisite. Start writing simple Use Cases to confirm an understanding of what you’ll be implementing.
No Code, but Good Project Management Still Required
So yes, No-Code Projects can be very freeing. I have seen for myself how creative my clients can be when they are not forced to negotiate with someone very technical who may not understand their business very well, and may not (for both legitimate and illegitimate reasons) always embrace their thinking outside the parallelogram.
The problem with no-Code project work is that it can seem so simple to build certain things that, at times, there doesn’t seem to be much point in managing things like a project because it’s just a formula or it’s just a workflow we need to map out….At least until the requirements are slightly more complex than you thought and you’ve spent almost a week finding the best way to implement something, and you still have to test it!
Agile Scrum should be one of the first things you think about on that next No Code Project of yours.
Get new BlueProject Posts delivered directly to your email box. Sign-up for the BlueNotes Newsletter.