18
Really good question. Really hard to answer. Here is my two cents contribution.
Agile showed up as a response to the practices of the late nineties for building software, practices that assumed you could define everything upfront in such detail and plan them out such that it was then just a matter of following that plan to reach a successful outcome. But ...
14
TL;DR
Trying to "future proof" your data is done by making your tools, processes, and data structures flexible, not by fixing them for eternity. You do this by embracing test-first database design, ensuring your data is normalized and extensible, and that your tools and processes support change. You do not accomplish this by treating your data or ...
14
I'd like to be "fully" agile and having design being part of the sprint [...]
I think there is a misunderstanding here, which is that in Agile there isn't any "upfront anything" and that the current iteration is the only place that things must happen. If this misunderstanding exists, people try to plan and do work only for the current ...
10
The agile approach does not necessarily imply shortsightedness.
Depending on the problem domain, you may have a very complete understanding (in your example, the industry exists for quite some time, has best practices, etc.) or a very limited understanding (such as a novel idea for a social network).
Very complete understanding
It would be foolish to throw ...
9
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 ...
8
How should a PM reconcile the wish to deliver something quickly, which may require extensive rework to add functionality in the future, versus doing extensive design up front then being able to develop all of the functionality quickly thereafter, with minimal rework?
This is the question at the heart of agile.
You could rephrase the question as:
Is the ...
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
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
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
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 ...
6
You already understand that UX/BA activities should be done before the Sprint starts, as developers need stories for planning. Your real question is how do you justify this approach from Scrum perspective (it's always the question with Scrum).
I can see couple of ways of justifying it:
UX/BA tasks are part of the sprint. But their job isn't to deliver a ...
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 ...
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 ...
4
In Scrum, you have a Definition of Done. Equally important is your Definition of Ready — that is, what work is ready for sprint planning.
Now, since a level of “Done” may be applied to each station in a workflow, it is reasonable to surmise that this includes the transitioning of work into the Sprint Backlog itself. In other words, before work can be ...
4
I see two possible solutions:
Consider the UX/UI designer as part of the SCRUM team. Whatever he/she does is a story, like all other stories. Now you have reduced the problem to the usual challenge of breaking down a task spanning more than one sprint, or more than one required participants, into pieces small enough not to have those issues. He will be ...
3
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 ...
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
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 ...
Only top voted, non community-wiki answers of a minimum length are eligible