post: improving agile

posts/hoxonstudios/02.improving-agile.md

@@ -0,0 +1,74 @@
+---
+title: Improving the way we implement agile
+published: false
+description: The fun of building cool stuff in the software industry seems to be fading
+tags: 'agile, programming, projectmanagement'
+cover_image: ./assets/improving-agile-cover.png
+---
+
+Along the way, developers gave too much power to the people surrounding their work. This could be due to our nature but the truth is that we lost absolute control of the software we build.
+
+I want to briefly revise the most common roles in Agile projects to see if there is room for improvement.
+
+## Business People
+
+In the last projects I worked on, I found a common pattern when it comes to Business Analysts and business people in general. Instead of focusing on what customers need, they focus on how it should be built. They treat developers as people that cannot design good software by themselves. Saying that this is a HUGE mistake is not enough to describe the harm that this is doing to the industry.
+
+In this kind of projects, developers lose any interest in the work they are doing very soon. Engineers are people that are prepared to design and craft innovative things, not to burn a bunch of tasks one after the other.
+
+## User Stories
+
+In their original form, User Stories were meant to be placeholders to start a discussion. Currently, in lot of projects, they had become very detailed requirements coming from the business experts and architects. Not to mention the bureaucracy required to change even the smallest detail.
+
+In my book, well defined user stories should be very small descriptions of the user’s needs:
+
+> As a user,
+> I want to be able to track the arrival date of each shipment,
+> so we can be prepared to receive it in our facility
+
+The above level of detail is ideal to create a User Story and start the discovery phase with the development team.
+
+I have seen user stories with so much detail that they even described how the fields of a form must be validated and what data types should they have. That kind of things cannot be accepted. I have no problem with having BAs involved in the discovery phase with the Dev Team, but they cannot decide this kind of things alone. As an example, I have seen developers that decided to avoid thinking about form validations.
+
+    If the validation is not in the acceptance criteria, it should be because they don’t need it. 😮
+
+## UX/UI Designers
+
+The same thing happens with the UX and visual designers. Most of the time, I see user stories that are received by the development team with all the UI work already defined and validated by the customer.
+
+In my opinion UX/UI designers should always be part of the development team. Their work should not end up in a requirement, it would be better if they take part in the discussion about how to implement the functionality. This way, developers can spot things that could lead to an over-complication of the solution earlier in the process. Is easy to present very complicated things to the customer without discussing it with the people that are going to bring it down to reality.
+
+Due to this kind of mistakes, projects end up way more complicated and hard to maintain than they should be. And it makes sense, because BAs and designers don’t know the true cost behind the things they want to implement. You could say that this can be communicated in Story Points, but how do you measure the impact in the maintainability of the system? You can’t.
+
+## Quality Analysts
+
+Nowadays QAs seems to be mechanical testing machines. They look at the acceptance criteria of a user story, they translate it to a bunch of test cases and then they proceed to run them. Having actual people only doing that kind of work makes no sense when it can be easily automated.
+
+It will be great if instead they start looking at the business goal. After the Dev Team finished the previous user story that doesn’t have any acceptance criteria at all, the QA could do the following testing:
+
+    - The user is able to set the ETA of the shipment
+    - Is easy for the user to understand how to do it
+    - Existing shipment arrivals are handled properly
+    - UI is aligned with the actual branding of the company
+    - The form field only accepts dates
+    …
+
+The question is, do we need an AC placed in each User Story to validate this kind of things? Shouldn’t we trust the expertise of our QA to decide which tests are needed for each user story? If we don’t, we will have the same problem as before, QAs will only test the things that are present in the acceptance criteria.
+
+The majority of the Product Owners and Managers doing agile, doesn’t believe in the feedback loop, which makes working this way even harder. They push developers to meet deadlines and have the features ready from the get go. You will see developers screaming when they see a user story without a very detailed AC. They don’t want to be blamed for not having the new functionality completed in the first try.
+
+Another question, does the QA need to know how the Dev Team implemented this story from a user’s perspective? Or it will be better if they only look at the business requirement and they try to figure out how to exercise it? If looking at the user manual and navigating through the application is not enough, it could be a good indicator that the UX or user manuals can be improved. Some will say that in some projects, quality analysts don’t have the required business knowledge to do this kind of things. Well, if that’s the case, you found one more problem to solve.
+
+## Architects
+
+In some medium or big projects, Architects have the task of defining how the requirements coming from the business must be implemented.
+
+This practice creates a huge disconnection between the developers and the business. This often leads to a huge communication problem, because engineers start asking for confirmation for the most insignificant things you can imagine. Also, some of the solutions proposed by the architects are nearly impossible to implement. Guess why… You are right, because they won’t be the ones implementing them.
+
+From my point of view, Architects should be there, just to validate the solutions proposed by the Dev Teams and to help them find the best path in the discovery process.
+
+## Final Thoughts
+
+I don’t know if these things will change in the near future, but I encourage developers to take back the ownership of their work and start building products instead of just completing tasks.
+
+Let’s get the fun back 😄