I work as a product designer in Sweden (2) Reflection of a designer in agile development
What is Agile Software Development?
Agile development, as the name suggests, is all about being able to move quickly and easily. As far as software development is concerned, agile requires the ability to deliver a usable product in the shortest possible time, and to update and iterate the product by repeating the same development process. Agile development is about "better", not "best".
In fact, for me, agile development is not a development method, but a mentality or a value. In fact, if you compare the process of agile development, it is not much different from traditional waterfall development: obtain requirements, design, develop, test, release, maintain/update. This is probably the process, but agile minimizes everything and allows the product to continue to evolve.
And why do you say that agile development is more like a value, mainly because the community of agile development also attaches great importance to this value. After all, the process can be easily replicated, but the "why you do it" is the most important factor that affects product development.
For example, if a company claims to use agile development but values process and tools over individuals and interactions, the company may not be really doing agile development, but a faster, componentized Waterfall development.
What does an agile team look like?
The minimum team composition can be like this: Product owner, Scrum Master, development team (including designers and engineers, which varies by project). The role of Scrum Master can be a complete person, and sometimes it can be part-time by other people. For example, in my current team, team members take turns to be Scrum Masters.
However, due to the efficiency and flexibility that agile development values, the team composition does not have to be a very fixed team. Take H&M as an example. Although we have a team, there are many functions that require the support of other experts. These experts do not need to be permanently in the team, but they must be able to flexibly support various projects according to the needs of the project, so as to ensure the smooth operation of the project. run.
In addition, cross-team and cross-departmental communication is also a very important part of agile development. Spotify's team composition is a well-known example. Each of their projects is composed of various Squads (squads). The members of the squads may come from different departments and have different supervisors, but what is interesting is that they also have an organization called Guild (association), which allows users to have common interests and ideas. A free group of people who exchange techniques or ideas with each other, facilitating the exchange of knowledge.
How can companies of different sizes apply agile development?
Looking back at my work experience, about half of the companies are emphasizing that they are agile, and the other half are adopting agile. Agile development can be said to be a software development method that has been regarded as the standard since the explosion of Internet products in 1990.
However, is it really so divine? !
To be honest, when I talk about agile development with colleagues or friends in my spare time, I feel that most companies make agile run into small waterfalls. The main reason is as I said earlier, the value emphasized by agile development is not easy to be reflected, and most companies will think that as long as the team runs Sprint, has Daily scrum meeting, and has Retro meeting, it is agile development. , but this is falling into the "focus on process and tools" archetype.
How small startups can run agile
From my past experience, unless there are members in the company who are very familiar with agile development, and the founders or senior managers start to promote it, the whole organization is very agile in terms of "cultural", otherwise it is actually quite difficult, but small. The advantage for a company is the low cost of trying out new development methods, and the fact that trying multiple parties is an important step in building a culture before they have their own processes in place.
The small organizations I have worked with have relatively few “established rules”, so it is easy to flexibly decide the development method based on the project content. Although there may not be professional agile coaches and Scrum Masters in the organization and team, it is easier to establish culture and values. The main reason is that the interaction of small organizations is easier and more dynamic, and it is very suitable for agile development.
But a very important thing for small organizations is the attitude of the founder/senior executive. If the role recognizes the value of agile and reduces the degree of his own interference in product development, or positions himself to develop with team members, with equal weight to each other's opinions role, then it will be easier to promote agile development.
How big companies run agile
Physically I find it more difficult to promote agile development in large companies than in small companies. The main reason is that communication is time-consuming and labor-intensive due to the large number of people, the high cost of failure to enter the market, and the fact that each product is involved in the whole body, it is bound to follow the plan, and it is difficult to respond to changes.
But the advantage of large companies is that once they decide to promote agile development, they can have ample resources to assist in the difficulties that may be encountered in the development process, or to provide education and training, agile coaching, and so on. For example, H&M is a company that I think has abundant resources, but it is still not enough in the process of introducing agile, and it has evolved into a hybrid development method.
For example, because of the size of the organization, we put a lot of emphasis on documents, mainly because they allow members across departments and time and space to have the same understanding of the same project. In terms of flexibility, to be honest, it is not very flexible. The main thing is to complete the planned things. Although we find that "user needs and assumptions are not the same", which is a very critical twist, we only This topic will be put into the backlog instead of adjusting the defined scope at the moment, and since the schedule is usually planned together with the entire company or other key departments, this newly added backlog will be escalated further and further, resulting in a lot of future. "Debt" to be repaid.
Therefore, I believe that the size of the organization should not be used to determine what kind of development process is appropriate, but should consider the nature of the product itself and the company's culture.
Challenges and Reflections for Designers
Any role is very important in agile development, and from my point of view, I think to be a designer in an agile development organization, in addition to having a certain degree of design ability, definition or Reframe (re-architecture) The ability to question is also very strong.
How to say it, because the requirements we receive will not be like the traditional development mode, there are very detailed Product specification product specifications. The demand received is usually a sentence. When we get such a sentence, we must have the ability to define "what does this sentence mean?", "what is the related user experience behind it?"
Designers are at the forefront of the entire development process. Often we need to define the User Story together with the PO, such as interviewing users, interviewing stakeholders, confirming product indicators, defining design scope, setting research methods, etc. These are all things that designers need to pay attention to in agile development.
For example, as a designer in a technology company with a PM, I may receive a request for "developing a shopping cart" and include all the functions required in the shopping cart and the corresponding API or technical requirements, such as It's "removed item", "changed quantity", "out of stock", etc. In a complete product specification, the definition of various states will even be provided, and the designer will design the defined behavior and state.
In an agile development environment, as a designer, what you will get is the phrase "development shopping cart", and the rest is up to you and your team to explore and define together!
This is actually quite challenging for designers, because at this point you need to focus not only on user experience or visual effects, but how the product brings value, confirm the operation process and various states with engineers, and It is necessary to be able to segment and arrange agency projects so that products can enter the market in the form of Minimum Viable Product (MVP). And how to define this MVP is a big challenge. I will write an article later on how to plan your MVP.
What I've learned in agile teams is not to wait for any "orders", even to ask questions, to discover possible risks or things that haven't been considered, and to be the one who starts the discussion, when the designer becomes the starter project people, we can ensure that the user experience is never sacrificed.
Epilogue
Personally, I don't think agile is a development method that is applicable to all enterprises, and it can't be discussed in terms of enterprise size alone. As I mentioned above, agile focuses on mentality, so I think organizations should first understand what their internal culture is like, how people usually deal with problems, how to communicate, and evaluate the relationship between the product and the market before coming Decide what development environment this product should use.
As an extreme example, if the majority of employees prefer and rely on complete specifications, then the waterfall development approach of a big PM is not bad and can be very efficient. And if most of your employees are very creative and development is really fast, then agile might be better for you. And if the market is very competitive and dominated by consumer products, agile is suitable; but if the product itself is low-substitute, and the cycle is long, then whether or not to use agile is not so important.
Designers should cultivate their ability to adapt to different development environments. After all, we need to be able to play the role of maintaining user experience. Whether in a waterfall with clear specifications or agile development full of unknowns, designers must be effective definition and solve the problem.
Thanks for reading this far! If you like my article, please help me clap 👏 and share 📣! If you have any cooperation invitations or simply want to exchange ideas about going abroad to design, you are also welcome to find me on my LinkedIn, Facebook or IG. Stella Hsiao | LinkedIn / @imsyc | Instagram / Stella Hsiao | FaceBook
Like my work? Don't forget to support and clap, let me know that you are with me on the road of creation. Keep this enthusiasm together!