Development Flow is an Important Aspect of Agile Development
Many startups and companies are using Agile Development to deliver their products as targeted as soon as possible. This plays a huge role in productivity and the working environment that makes people feel excited about the great success they want to achieve. And many people think that achieving the target, showing to the world that you and your team can be trusted to handle your newborn company and has an amazing future. This is NOT a wrong thing, the spirit of entrepreneurship is an amazing thing in the past decade that shapes the world of the internet and how we use it every day.
While having a focus on delivering the products, some organizations, whether a small team or big company tends to forget their internal issue, especially sustainability. Meanwhile, sustainable development has always been in the agile principles. And “The best architectures, requirements, and designs emerge from self-organizing teams”. You MUST remember that your products really indirectly reflect the communication within your organization. No matter how proud you are, the users are the judges and users tend to understand the problems.
Some people may think that the existence of Development Flow is creating many layers to make agile development slower and creating a bottleneck. No, instead we need Development Flow so we can find, understand, and fix the problems. This may seem unrealistic to read but, Teams are responsible and don’t do “whatever they want” because trust is a key in Agile Development. That’s why educating your team is such an important step in the first, same important as the evaluation step or 1on1 meeting. So, Never too focus on Delivering your product and forgetting this principle “At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.”.
Based on a study, “developers seem to perceive the complexity of Scrum projects as higher than that of the traditional project”. In my opinion, there are several factors related to this problem. This may not true to all, but the ambiguity documents developers received or made is the main source of the problem. Whether Product Requirements Documents, Tech Requirements Documents, or Even Documentation. In other words, Agile doesn’t mean you don’t document things, but it is mandatory to have enough document so you don’t do any unproductive activity in the middle of the project timeline.
There is also a dilemma in the way of thinking to “Responding to change over following a plan” in the Agile Manifesto. In the short way of thinking, this may seem developers have to accept whenever and no matter what. NO! Never put one point over another. If we see the 12 principles based on the Agile Manifesto, those exist to balance each other to deliver the common goal of the Agile Manifesto without creating chaos.
Agile Manifesto: https://agilemanifesto.org/
the 12 Principles: https://agilemanifesto.org/principles.html
The important thing in Agile is never creating any dictatorship activity in your Development Flow because the collaboration is the key in Agile. Controlling things in your team they won’t have a positive impact on sustainability, especially Social Sustainability. It is also important to note that there is no fixed Development Flow that can be implemented generally. But, it doesn’t mean that you don’t need described Development Flow and let everything goes as it flows.
The Development Flow is shaped within your organization itself, it reflects your communication. Meaning your Development Flow is always improving as you do the “At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.” principle. As important as other documents, you need to state the Development Flow on a document. Why? like code documentation that you use to describe things on your code, this is a document that helps your team to be updated with the flow of your own company.
More importantly, with Development Flow on the document, it makes your teams think that they are not following the old tradition of how the company works. Because they understand better how to do things, and helps to improve your Development Flow. Meaning your employees themselves are the users of your Development Flow of your Agile, which can be evaluated, improved, and adapted that may impact the performance of your team to deliver a great product. That’s why it is important to have a mindset that always questions “what’s wrong with the team, do we miss something on the Development Flow?”, especially when you face a delivered yet failing product and/or out of the concept tech.
This is a way of the Mongolian Army did during Empire expansion. Even tho they have strong experience, strategy, and military knowledge. They took any foreign knowledge that can be used to make the greater army, instead of following the tradition. And it can be proved how Chinggis Khan innovated upon and evolved, rather than invented, traditional nomadic tactics.
Below is one example of Development Flow I’ve made that focuses on Research, the mindset of “ideas come from anyone”, organized multi-layered testing and review, and user-driven decision. Please be aware, No Development Flow that can be implemented to any team generally. Once again, Development Flow is shaped within your organization, and it reflects your communication. So, figure it out and takes anything that can help your team to be improved.
My favorite on this Development Flow Example is Research steps. Before you actually start working on the product or tech issue itself, you must understand whether the current tech is good enough to handle the requirements. Whenever you need more advanced tech, find the options available, create something that accountable for helping you pick up the best option after comparing those. You have to really study and understand it, the research won’t be research if you just can install/create and use without making a real situation scenario and good data conclusion. And never take a conclusion from the internet or other teams as your research result, because every product has its own unique problem and scenario. Do your own, And don’t under and overestimate the tech requirements, pick as good as its need. This Research step is good using Kanban instead of sprint that has limited time and makes things seem unproductive in the sprint.
The way of thinking that the idea doesn’t always come from the Product Team is also good, considering the collaboration team is such an important thing. The idea can be from anyone, from your engineers or even your users. Because the tech idea or user feedback can be a product itself. So, please stops creating an activity that a team or someone is superior above others. It won’t be a collaboration, because you don’t open to listening to anyone from outside your own made circle. This is where you actually need the Empathy Driven Development, to see the real point of your product, what good things that can be delivered.
It is also important to understand the balance between working on tech issues or tech debt and working on delivering new features. The product team needs to understand the current problem from tech and stays humble for letting the Engineering Team finish the problem they face. And Engineering Team needs to aware that it is your responsibility to deliver a good understanding of the importance to tackle the tech problem first before working on the feature. Because it is not the Product Team problem when something goes wrong with your service. Stay having good communication can help to create a good collaboration to deliver a better product.
Back to “Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.” principle. If we think on only to this point, we won’t stop having a dilemma about progress vs changing requirements. And it is not allowed to change something on running sprint. So, it is better to have changing requirements as a new task and see the prioritize. Never push changing requirements as the highest priority that may disturb the sustainable development and consistency of delivering pace. Also, changing requirements is only about “…customer’s competitive advantage”. So, it is weird to have changing requirements in the middle of development especially when the product is not yet delivered, it is surely not based on OUR users’ feedback. It is only our perception that this is better than the old one. So, make sure to not create this kind of condition, because it causes a negative impact on social sustainability.
More into the tech side, there’s a good joke that represents the actual condition inside the team, that engineers don’t really understand what they do. I took the point and see that actually they don’t really understand the others’ code on review. No matter how good you ready the code, you won’t easily understand what actually it does until you did something with it. I am always having a thinking that I won’t give approval on a PR that I don’t understand, and this is not a blocker. So, that’s why it is essential to have a descriptive PR and test scenario that really does things. This kind of activity between your peers which is called “internal bug bounty” is good to have on the staging environment, especially if you have a peer that really loves to break things up. This way of thinking and breaks things on staging is important so they really give you a vision outside your mind and helps you to improve your code before the actual delivery on the production environment.
Many essential things can be found and covered, you can find many good things that can be implemented on many sources of study and research. And Never ever underestimate any source even unrelated things on the cover. Say a History or even Sci-fi source, read and take what can be implemented. They who have a spirit to read not an exact thing, but instead use their head to think something that can be related to their problem is amazing. Because everyone has their own different way of doing things, but we have ONE common goal, be better at something. “while there is value in the items on the right, we value the items on the left more.”
references:
[HOW SUSTAINABLE ARE AGILE METHODOLOGIES? ACCEPTANCE FACTORS AND DEVELOPER PERCEPTIONS IN SCRUM PROJECTS] https://pdfs.semanticscholar.org/43ea/0bd76bf0f90953b3370e30a1838846fea193.pdf
[Social Sustainability Aspects of Agile Project Management]
http://www.diva-portal.org/smash/get/diva2:1070296/FULLTEXT01.pdf
[Sustainability and Agile]
https://www.agilealliance.org/sustainability-and-agile/
[Empathy Driven Development]
https://www.empathy-driven-development.com/
