\nJune 18, 2018<\/p>\n\n\n\n
A common problem we face is how to organically fit processes that are not part of pure software development. Here, we tell you how Agile and UX design can work together<\/strong>.<\/em><\/p>\n\n\n\n Many of you already know what Agile is (or Scrum, its most popular \nimplementation), its main benefits for software projects, and its main \nvalues (the Agile manifesto<\/a> makes it pretty clear). But a common problem we usually face is how to organically fit processes into our daily routine that are not part of pure software development<\/strong>, such as UX\/UI processes.<\/p>\n\n\n\n Next, we are going to delve into some concepts<\/strong> that \nwill help us understand why it is not necessary to force this practice \nartificially within our Agile process, but on the contrary, it must fit naturally into it. How do you do it?<\/strong> Let\u2019s take a look at the following:<\/p>\n\n\n\n Generally, a Scrum team is made up of a relatively small group of \nprofessionals (between 5 and 9 people), which is multidisciplinary and \nwith the necessary skills to carry out a specific project.<\/p>\n\n\n\n That does not mean that everyone must be a Senior and therefore, be \ncapable of doing everything (from programming, to testing, or \nconfiguring the continuous integration server, among other activities). \nIn general, most professionals end up specializing and deepening their \nknowledge in some subject area (front end, back end, etc.).<\/p>\n\n\n\n However, if a software project needs a good user experience, usability, and design, we will most likely think of a UX designer<\/strong>,\n a person who, although not directly related to the development, has to \nclearly understand the objectives and vision of the project.<\/p>\n\n\n\n As a key player in the whole process, the UX designer must therefore take part in the Scrum ceremonies<\/strong> (Dailies, Plannings, Demos, Retros) like any other member of the team.<\/p>\n\n\n\n A designer will then perform UX tasks in the same way that a \ndeveloper does development and architecture tasks or how a tester does \nthe testing work. A good self-management of their different tasks and \ndependencies is necessary in order not to generate bottlenecks.<\/p>\n\n\n\n One thing to consider is whether the team configuration passes the bus factor<\/a>.\n It is a rather crude test but with a clear message: How many members of\n the team must get hit by a bus before the team stops working? The lower\n the number is, the worse, as it means that the team\u2019s know-how<\/em> is not well distributed and is concentrated in few people.<\/p>\n\n\n\n If a team member is missing for any reason, it can generate a problem in achieving the Sprint goals<\/strong>.\n Since we probably have few UX experts on the team \u2013depending on the \ntype of project\u2013 this could be a risk factor if we are not prepared.<\/p>\n\n\n\n How can we prevent this from happening? There are many ways to do it.<\/strong>\n One is to ask the designer to document the design standard so that it \ncan be consulted by another member of the team if necessary. In \naddition, the designer can carry out some tasks with another member who \nis interested in learning or who has a penchant for UX, ensuring that in\n the case the designer is not available, another person covers his or \nher work. The important thing is to prevent the development from being held back<\/strong>.<\/p>\n\n\n\n Implementing these actions creates a more natural integration of the designer with the rest of the team<\/strong> by making him or her part of tasks implemented by other members.<\/p>\n\n\n\n Most design and layout tasks are very likely to be carried out prior \nto the development, which is why it is natural that they are implemented\n in separated Sprints. Doing this may seem like we are going against one\n of the Scrum rules that refers to adding value in each Sprint and \nimplementing something potentially deployable at the end of it.<\/p>\n\n\n\n A wrong comparison is with testing tasks, which are ideally carried out during the same Sprint as the development.<\/p>\n\n\n\n If something is not tested,\n it will probably not meet the Definition of Done, which is why we \ncannot consider something finished if it must be tested in the next \nSprint. The difference here is that the design and layout tasks could be\n considered analogous to definition and analysis tasks, as they are part of the discovery process and specify how a functionality will interact<\/strong>.<\/p>\n\n\n\n It is not recommended to do the design and layout during the same Sprint<\/strong>\n as the development because they require customer feedback and can \ndrastically change the direction in which it goes. If we start the \ndevelopment at the same time as the UI design, we will probably have to \nundo a lot of work.<\/p>\n\n\n\n Agile is an adaptable work scheme with no prescribed rules that say \nhow things must be done, but a set of good practices as jurisprudence \ndoes exist.<\/p>\n\n\n\n In this scheme, we cannot underestimate the importance of UX and UI, as they are an essential part of software<\/strong>,\n and as such we must find the way to make them part of the development \nprocesses, just like testing or programming do, with all of these \nintegrated in the most natural and organic way possible.<\/p>\n","protected":false},"excerpt":{"rendered":" June 18, 2018 A common problem we face is how to organically fit processes that are not part of pure software development. Here, we tell you how Agile and UX design can work together. Many of you already know what Agile is (or Scrum, its most popular implementation), its main benefits for software projects, and… Read More »How to combine Agile and UX design (or any other practice for that matter)<\/span><\/a><\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"closed","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"neve_meta_sidebar":"","neve_meta_container":"","neve_meta_enable_content_width":"","neve_meta_content_width":70,"neve_meta_title_alignment":"","neve_meta_author_avatar":"","neve_post_elements_order":"","neve_meta_disable_header":"","neve_meta_disable_footer":"","neve_meta_disable_title":"","footnotes":""},"categories":[1],"tags":[9,10],"class_list":["post-739","post","type-post","status-publish","format-standard","hentry","category-uncategorized","tag-agile","tag-ux"],"_links":{"self":[{"href":"http:\/\/www.smart-bricks.net\/index.php\/wp-json\/wp\/v2\/posts\/739","targetHints":{"allow":["GET"]}}],"collection":[{"href":"http:\/\/www.smart-bricks.net\/index.php\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"http:\/\/www.smart-bricks.net\/index.php\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"http:\/\/www.smart-bricks.net\/index.php\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"http:\/\/www.smart-bricks.net\/index.php\/wp-json\/wp\/v2\/comments?post=739"}],"version-history":[{"count":1,"href":"http:\/\/www.smart-bricks.net\/index.php\/wp-json\/wp\/v2\/posts\/739\/revisions"}],"predecessor-version":[{"id":740,"href":"http:\/\/www.smart-bricks.net\/index.php\/wp-json\/wp\/v2\/posts\/739\/revisions\/740"}],"wp:attachment":[{"href":"http:\/\/www.smart-bricks.net\/index.php\/wp-json\/wp\/v2\/media?parent=739"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"http:\/\/www.smart-bricks.net\/index.php\/wp-json\/wp\/v2\/categories?post=739"},{"taxonomy":"post_tag","embeddable":true,"href":"http:\/\/www.smart-bricks.net\/index.php\/wp-json\/wp\/v2\/tags?post=739"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}1. They are part of the team<\/h2>\n\n\n\n
2. Bus factor<\/h2>\n\n\n\n
3. Design before development<\/h2>\n\n\n\n
To Sum Up<\/h3>\n\n\n\n