8
In our company we also face similar problem and I would agree to the post above that kanban is a good choice. Kanban board provides all the necesarry visibility and clarity for team, also we do stan up meetings for quick overview. During planning phase we take parts - if the planning is for first project, we invite only the members that are related. In such ...
8
Is it my job as solution architect to learn all these laws and see how they apply to the software we are going to make or should this be a task for somebody else?
If you don't want to learn the laws, you are basically asking to receive complete requirements with everything perfectly laid out for you, so that in turn, you can then lay out a technical ...
7
Your question is titled about integrating into a Scrum team, but it sounds like you are not organised like a typical Scrum team would be
Typically, your UX designers would be team members, they develop software, the same as your programmers.
You should not create user stories for UX tasks. User stories should meet INVEST criteria. UX tasks would likely ...
7
Even if you - as solution architect - get a list of "we need x, y z" and you describe how this should be implemented, you still need to be aware of the laws related to security, privacy, scalability and more.
E.g.: if the law says you need to use a Secure Connection, then your "solution how to communicate" needs to deal with SSL and/or ...
6
I think this is totally possible as you need to agree on one and the most important rule. When you plan sprint backlog, you close it and there is no place for new "unexpected" work items. Because you will be forced to deliver value on each of the ongoing projects, in any other case you will fail not one project but all together. Also, it is important that ...
6
TL;DR
In your rather long question, this mixture of issues stood out as the gist of what you're really asking about:
Sometimes a design will be approved the first time, but other times it'll take 5 iterations. The only thought I had was to maybe re-score every time I have to do an iteration & bump it to the top of my sprint since that's still ...
6
Soliciting requirements is a iterative process, starting at an abstract level and diving down as you iterate. It is a data pull from the stakeholders; so it is about asking a ton of questions, several different ways, and becoming more tactical as you go along. Since it is a data pull, the techniques are not rocket science. It involves surveys, interviews, ...
6
This is not the purview of the Product Owner (PO).
The PO should not care how the product is built - that concern lies with the Development Team. The PO should only care about what is built in what order.
In my experience, purely development tasks such as these should be created by the Dev Team, not the PO.
If something can be stated in a way that ...
6
There are two sides to this - laws and regulations. I would not necessarily expect someone on a project team, regardless of their role, to be an expert in either law or regulatory requirements. I would, however, expect an organization to have access to experts in these fields, either as employees or some kind of contractor or consultant relationship. I would ...
5
My advice:
Set aside time for your team to learn some basic UX/usability, whether it's looking over blogs or videos together or actual training. Even if you get a dedicated person later, helping your team become more T-shaped will pay dividends.
Work together to create a proxy for a UX designer, i.e. a visual style guide that can be followed by almost ...
5
It's the product owners duty to define acceptance criteria. This can include usability features.
For example: As a color blind user, I want to use this feature without any impediments
It's the engineers duty to figure out how to do that.
For example: Subtask: As a user, I want my color blindness settings from the main application to take effect when ...
5
Despite the fact that I agree with David that design by committee is sarcasm [and a real phenomenon, I agree with Michael Hogan too :-)], question is about examples (not about "design by committee" term).
So, take a look at this article.
There is a list of projects designed by committee in the "Case Studies" part:
Design by Committee: The U.N. ...
5
Do your projects sequentially, one at a time. Period.
And how do you prevent the fact that other projects/clients won't be waiting for a month...
Think this one through: say you have three projects to do, and each one will take four weeks (with the entire team working on it). Further assume you wouldn't lose any time switching between them.
If you do ...
5
I hope theres not too much redundancy to other answers, but I wanted to go in to some details about tools you might use in agile team with several projects.
What we do (about 6 developers, on 2 bigger and upto 4 smaller projects at the same time) is as well combining tools from different technologies.
We write specifications based on user stories, which we ...
4
At the initial scoping phase of the project you need to understand what the client wants and what users want. Your project management skills will be tested in trying to balance both sets of requirements and deliver a product both are happy with.
To understand your client's requirements use the techniques that other answers have proposed including what you'...
4
I'm not sure we've answered the OP's question:
How do you prevent a situation where you have to produce work-product work first and get client feedback before getting on the right track to meet their needs?
If I understand the problem correctly, the OP is working with the client to develop the initial requirements for the project (pre-initiation). The ...
3
Design-by-committee is a real phenomenon, especially in government projects where a committee of elected representatives establish and control budget decisions. University of Southern California course SAE 550, "Systems Architecting and the Political Process", is a survey of engineering efforts that have been heavily influenced by design-by-committee.
The ...
3
Looks like your Scrum team does not have a Product Owner nor a Scrum Master
However, if you do, get your Product Owner to prioritize the stories and get your Scrum Master to receive and manage all requests for your time. Your team (and you) should focus on one highest priority story (as decided by your Product Owner) at a time and take it to 'done' status. ...
3
Business analysts and Designers in a Scrum team
Business analysts help provide detailed requirements to the dev team. So, in a Scrum team a business analyst can be a part of the Product Owner (PO) team and assist the PO. They can also step in place of the PO, when the PO is unavailable.
However, designers actually do the work of creating a shippable ...
3
Every employee of any organisation has a responsibility to comply with laws and regulations. For example the General Data Protection Regulation applies to all employees of an organisation. I suggest your team as a whole needs to take ownership of the regulatory compliance matters and as a solution architect you ought to play a key role in that, but what's ...
2
The best place to fulfill this requirement would be your teams Definition of Done. A process policy used to ensure quality.
Speak with you team about how to best test usabilility in the sprint cycle. I'm sure they will have lots of interesting ideas and a Definition of Done policy is best owned by the team. Some suggestions might be;
Pair devs with UX
...
2
The short answer for me is to always have user stories. I come at this with a software dev background, many Product Managers don't have a background in development and cannot think in units of dev work. However, they can work with us on defining who are the end users, and what will they be doing with the end product. Once we can come up with a list of likely ...
2
Would not delve in graphic design issues, since my aesthetic feeling may not be shared by others. As for eliciting customer's requirements, there are a few considerations:
How do you structure and dimension your product space?
a) Structure: what attributes of the product do you consider overarching and largely constraining your design? For instance, for ...
2
This actually is a very good question. I've found that visual representations of system processes can really help people who don't write code understand system designs. Yet, I've also found people are hesitant to maintain and reuse such documentation. Here I present an incomplete list of reasons why reuse and sharing my be true in the hopes that someone on ...
2
I am trying to find an example of the failure of design by committee...
Design by committee is not actually a serious method. It is sarcasm. Typically, that phrase is used to describe a design process that is extremely inefficient and is leading to feature-bloat. It is inefficient because it takes longer than necessary to make decisions. It leads to feature-...
2
This question is a perfect example describing one of the root problem and why many companies liking & switching to Agile Development.
If you are familiar with some agile development concepts you will understand my response as is. If not try to read about scrum, product backlog, definition of done, user stories, retrospective, sprint review etc..
I ...
2
The old saying "a picture is worth more than thousand words" is also true when it comes to software specifications.
You can write multiple pages of text to describe your user interface and its functionality. The result is that the reader takes an hour to read it and still has just a vague and abstract idea in their head about how the end result will look ...
2
To be blunt about the answer, it sounds like the designer has a lot of crutches. If you want them to step own design (I'll assume you do or you wouldn't have hired a designer), you need to take those away. Now, before I get into the ones I see in your description, I should add that if you take them all away at once, you may just overwhelm them - you have to ...
2
This is a question for which I have always been looking for an answer. With my experience with this, is how I am managing:
These kind of technical tasks are considered 'acceptance criteria'. Or you can have a story based on your infra-requirement, like:
"As a (role), I need the system to respond well when there is load of 10K concurrent requests"
OR
You ...
1
Sounds like your organisation uses Jira tickets as their central source of information, (i.e your SM looks at Jira tickets), so the Jira tickets should contain short comments on how the implementation decisions have changed, and why.
Put a link in the ticket that points to the appropriate design directory. This way the ticket always references the most ...
Only top voted, non community-wiki answers of a minimum length are eligible
