Workflow Methodologies as a Developer

This led me to think about the workflow methodologies in the real world outside of a bootcamp. Even before learning about bootcamps, I had saw some buzzwords from my prior job search such as scrum and agile, lean and six sigma (from an engineering background). I think it’s important to know, or at least be aware of different types of workflows, just so you know what you are getting yourself into when you apply for a job that uses a certain type of workflow style.

Here are some of the types of workflow methods I have come across while researching this topic. Note that there will be some small differences in models, but thought process and implementation will be very similar.

Don’t over categorise these methodologies, it can get especially confusing when you end up wanted to compare different workflows for each other. I found it best when I read them all individually and saw them as just different styles of working.

This model is very methodical and linear. The development team will work solely on that stage until it is complete. This model allows easy management of the project, easy-to-follow process resulting in clear communication to stakeholders, and solidifies the chance of achieving the deadline. It’s great for projects that have a similar or repetitive structure.

Analysis: The requirements of the app is documented so that members of the team are on the same page and understand the task. This is mainly discussing how it should function and if it is an achievable task.

Design: The specification is decided at this point, making sure that the requirements will be met. Team members should be aware of what needs to be done and how it should look like.

Implementation: Coding begins! This is where the all the models, logic and any other integrations happens.

Testing: Once written, the application will be tested to make sure there aren’t any bugs in the beta version. It is after this stage onwards that the team may have to go back to implementation stage in order to fix the bugs. The beta testing can be done internally or publicly with users.

Deployment and maintenance: They can go hand-in-hand. As once it is deployed and live, there must be support for the users and clients, patch any code for any bugs discovered by users or internally. Also, to update the application with new features.

The downside to this method is that it is very resistant to change. If there are any changes or problems, especially once you’ve gone ahead to the following stages, it can be very time consuming to go back and change your implemented code to the new requirements. It also takes a lot of time to research and finalise the requirements for the project, they may even change their mind.

The cycle seems quite similar to the waterfall in terms of sequence, the difference is that it is more expected to be going through all those stages again. After you have reached “the end” of a cycle, you may be moving on to implementing another feature that the client wants.

For an Agile team, it can be quite difficult to provide concrete deliverable dates due to their adaptive workflow. There will always something to do if you are embracing change. If change and adaptability in embraced, then it would be very useful for the programmer to be multi-disciplined too, especially if the project team is small. This will also result in a lot of time being committed to the project, usually for the entire process (though it may give the developer a lot more insight to how best to deliver the project).

The next 3 methodologies are Agile methods but each have a different flair to them:

Originally used in manufacturing, it has been adapted to software engineering, taking the Agile philosophy to a super productive level. They focus on 7 principles:

Eliminate waste: No partially done code (waste of time), no extra features or processes (waste of brainpower), no switching tasks or waiting around (waste of time). Get what needs to be done, done.

Continuous learning: Use what the team knows and implement it. Focus on fitness of use of the product. Learn about the user’s experience and feedback, figure out what user’s really want.

Decide as late as possible: Using the learning from the above principle, making important decisions as late as possible will reduce the possibility of making dreadful mistakes with major impact. Once the user has gained a better understanding of what they want, then you can make the final decisions.

Deliver as fast as possible: Again, using the users knowledge and desire, it is important to show them what they want ASAP. They will feedback whether it is really what they want or not. Technology and competitors are also rapidly growing. So there is no time to wait. Go fast!

Teamwork: Instead of having managers deciding everything for the developers, the manager listens to any problems or explanations from the devs. Having members do what they feel they excel at, and/or what they want to do, everyone should have better motivation during projects and thus be more productive.

Product integrity: This focuses on how well the product fits for the user. This includes price, usability, and whether it actually solves the users problem. One way of doing this is code refactoring. Making sure code is clear and simple, focusing on good code practises.

Have overview: For bigger projects, being aware of the whole process allows all the other aspects of the Lean philosophies to be achieved. Having every member understand what is going on gives them a scope and context to what they have to do.

It can prove difficult for a member of the team to be productive if they aren’t aware of the whole project. They could end up implementing a feature that has already been done, wasting time(!).

It could be great for small projects as it would be easier to keep track of all aspects of the project. Focusing on delivering a minimum viable product, it reduces the cost and time invested.

This one is unique due to their meeting and project style. Work is divided into “sprints”, usually a week or two long. At the end of the sprint, there is a meeting (lasting around 15 minutes) held by the “Scrum Master” with a board that has details of their progress. The Scrum Master is there as an intermediary between the development team and “Product Owner”. The Scrum Master helps the team overcome any issues blocking the team from achieving their goals for the sprint. This keeps the team constantly moving and implementing.

The Product Owner is to provide an overall vision for the product, providing priorities for the team. They need to answer questions posed by the team to clear up any queries or confusion. At the end of the meeting, everyone discusses how the process is working and whether any changes should be made for the next sprint.

Having meetings this way provides a good overview of what is going on for other members, members support each other due to the team being fully responsible for delivering the product. This also allows the project to be flexible.

The downside of this is that the team must be very experienced. If the Scrum Master is also stuck, the project may come to a halt. Tasks also have to be carefully defined, otherwise they may have to spend another sprint fixing the previous one.

There is a model called Kanban (In Chinese it literally means “look-board”). It is very similar to Scrum but has it’s differences.

It might have been a scary read for aspiring developers, but they’re just ways of project management and how best to work with each other and stakeholders. Each with their positives and negatives and I hope I have given enough information for you to think about what sort of structure you may prefer, or at least what to expect from an employer so you’re not in for a surprise after you land your first job!

Best of luck to us all aspiring devs!

Related posts:

The world had come to a standstill. And like everyone else trying to keep their sanity, I tried to keep mine by doing what I had always done — weightlifting. But that old repetitive action now felt…

Note that suspend function can only be called either from a coroutine or from another suspend function. Here GlobalScope implements CoroutineScope and launch is a coroutine builder which is an…