I’m going to against popular opinion in this topic and state that our standups (and the afternoon catchups) have actually had tremendous value to our project. We’re a disparate team of 11 people across Cape Town and Centurion and, due to the high velocity and pressure of the project, we don’t have time to do long planning sessions, retros and grooming of requirements. Especially now that everyone is working remotely, where previously the large majority of the team were centralised to an office in Cape Town.
So we effectively have a mini sprint-planning each morning and a little retro in the afternoons. During those sessions, there are always issues the developers face that come to light, that I can course correct before they spend 2 weeks in building a feature incorrectly. That way we’re also constantly refining the requirements, twice a day, and it ensures that everyone on the team knows what’s going on. Seeing as I need to build in a contingency plan for when developers are on leave or resign, I can’t afford having a single person being a champion of any specific feature, business domain or process.
Couldn’t agree with you more. However, this is the process and structure and as much as I try to reshape or reform it for the purpose of productivity it is what it is.
Now this is probably why I’m in this situation of being micro-managed and the purpose for them to see progress on a daily nature is due to my week consisting of 60% of meetings. I’m sorry, I refuse to do work in meetings, other than for what the meetings nature is, as I find it rude. Besides that I can’t do focus work when I have people droning on and on in my ears, not to mention having to pay attention to the discussions.
And now I am attending yet another meeting. This one, however, I am part of because I insisted. I have been pushing for QA to be part of feature design meetings, both technical and conceptual for years now. Finally they are letting me in. I enjoy it though.
I am doing a thing called “static analysis” of a new feature. You basically take apart the business requirement documentation and voice your opinion of the workability of features during design meetings as the software test analyst. This way you can prevent bugs and conceptual discrepancies from even getting into the software before it is written.
I am getting very frustrated in my current position as I am effectively just a UI designer who gets requirements and told to design. I am the Senior UX Designer and don’t even drive the weekly UX meeting agenda. Usability patterns and such get brushed over as it doesn’t fit with what the boss wants.
Sorry, just getting tired and frustrated of not having input taken into consideration. You hire a professional to tell you what to do, not to tell them what to do. Innit?
Anyway, this topic has gone on long enough and slightly gone off track, don’chya’think?
The business analysts come to the table with the business requirements for a feature. The lead devs comes to the table to tell them how it can be done. I come to the table, having read all the requirements with my comments on what will be problematic. The CIO comes to the table to ask questions of everyone. We leave with the basics of the FRD (functional requirements document) which the devs use to create the software and I use to test the software against.
We sure could use a poper UX designer. Our current one can draw pretty pictures but cannot do the actual front end work for it. Our devs have to do both back end and front end for projects.
My apologies, I understand what design meetings are for, simply meant it sarcastically as we should be doing them but I don’t get the affordability of doing so. When I raise the issue people tend to frown upon the thought of, “urgh… more meetings”
I have an understanding of a few languages though don’t actually code myself. I know HTML/CSS and other frameworks so that I can translate and understand what the devs are talking about when required, front and back end. I’m more involved in the empathetic, psychological and cognitive aspects of design and love qualititive research.
That is such a pity. From what I read and have seen of your work in images here, you have a LOT of very good concepts to bring to the table. I guess I have been spoiled that the “bosses” in our design meetings have been a lot more co-operative than authoritative.
The thing is our current structure and process is driven by functionality, the stories get specced by PM/PO/BA and get spoken about feasibility from a dev perspective. Only then does it generally come to design, which is just ass way of going about it. Which also put us (well, me) on the back foot as design is happening alongside development or often stuff ends up on a QA environment before the design is even finished. I’m then left to answer for certain things or solution problems while in refinement/planning.
Agreed, that is just stupid. Design should happen from the start. You cannot build a car without knowing how the car interacts with the driver, both visually and manually.
Came across this in my Twitter feed and decided to explore it, rather interesting article speaking into what we’ve been talking about herein. Also some good reference material, a good call to point for me is NNgroup
Not going to link all the references within the article, explore if you like
