Learn Software Development » Design

How to incorporate UI design as part of Scrum work, collaboration between Product Owner and UI Designer

ashish — Tue, 18 Oct 2011 19:16:37 +0000

If you want to ensure that your product / software application is successful, there are a number of things you need to care of. If you look at the success of many of Apple’s products such as the iPod, the iPad, iTunes, and the iPhone, it is about ensuring that your workflow appeals to customers, that they find using it so easy that they are even willing to pay a premium for such products. What this brings out is the importance of ensuring that you have workflows that appeal to customers, and this means that you need to get your UI designer into the product development process. However, it is not easy to integrate the working of processes with the working style of UI designers. In my experience, getting them to work with the kind of deadlines and schedules that you can impose on engineers and QE can be a difficult task, and this process can interfere with their creative juices.
So, what happens in the case of Scrum ? Well, for Scrum work, we typically say that features should be worked upon when you get close to the Sprint, since that is when the prioritization of features for a Sprint actually happens. However, when the sprint starts, the team starts working on the tasks, which means that the UI for those tasks should be ready. Which automatically means that the UI for tasks should start before the Sprint planning activities (seems a bit strange that some activities for tasks should occur before the Sprint in which the task should be worked on, but there is no other way to get the UI in place).
For this to happen, it is also necessary that there is a parallel planning process underway, whereby the Product Owner has a list of prioritized tasks (already there as part of the Product Backlog); with the difference being that the tasks for the next Sprint should be confirmed during the previous Sprint. In addition, there should be a schedule in place which tracks the work being done by the UI designer, and this planning needs to happen with the Product Backlog, so that it should never happen that the UI designer is getting too many tasks. If this happens, then the UI will not be ready when the team is starting work on the tasks in the Sprint.
So, in the Sprint before a particular Sprint, the Product Owner, one or 2 assigned team members, and the UI designer should be working on a list of tasks for which the UI is required at the start of the subsequent Sprint, and should aim to get a high level workflow document and a UI wireframe in place. Once the actual Sprint starts, the Scrum team will start working with the UI designer to get the final UI based on the User Stories outlined by the Product Owner.

Problem in Scrum: Looking at technical debt, which will cause more problems as you move ahead ..

ashish — Tue, 04 Oct 2011 14:24:11 +0000

What is technical debt ? Well, I will not try and give a definition for technical debt. Instead, consider that you have 2 approaches to build some great new features. You can do something in a quick way without trying to build a great design, or you can build it the proper way through the required design. Now, if you need to get features done quickly, then trying to build in the proper design and architecture can stretch the possibility of getting the features done in time for the need (say, if the team is under pressure due to market requirements, or due to external stakeholder pressure). In such cases, it is a business need to build the feature done quickly enough, but one of the problems of taking such an approach is that you need to build a structure in order to build more and more features, and as you neglect the design work, building features becomes even more difficult. To put it in another way, in order to save some time in the beginning, you spend more time later. This is what is called technical debt.
In the case of the Scrum process, what I have seen in practice in many teams is the concept that because of the pressures, because of the way that the team seems to work from a Sprint to Sprint, the tendency to think about architectural change can slip by. The whole team is driven through a process whereby the Product Owner defines a set of features, prioritizes them, these are broken down into discrete tasks and estimated and then implemented by the team. There can be a lot of pressure to ensure that the teams are delivering a set of features on a regular basis; further, people are occupied on ensuring that all the features are delivered on time. It can get pretty difficult to insist that architectural tasks are delivered, since there can be a lot of resistance to putting these tasks into the Product Backlog. It would typically need somebody of the stature of an engineering manager to have those discussions with the Product Owner, to explain the need to put in the engineering time for putting in design for building for more features. It can be difficult at times, and in our case, it took us a few months and one round of feature failure to explain the engineering design process in detail to the Product Owner, and now we are in such a condition that the Product Owner totally understands when we push for some architecture work. However, it can take time for the Product Owner to be comfortable with these details.

Problem in Scrum: Inability to prioritize the architectural and design tasks – Part 2

ashish — Mon, 03 Oct 2011 14:21:32 +0000

In the previous post (Not putting design priority), I had talked about how a Scrum team can face challenges in terms of prioritizing the architecture and design tasks. In this post, I will continue my previous discussions and talk about how teams do actually place a lot of emphasis on the design part, and how this has to be driven by somebody.
I was recently talking to an engineering manager who was part of a team that was working on a product (or rather, the people in the Scrum team reported into the engineering manager). When I asked the same question, about how the team managed to ensure that they did not get into a situation where the design work was not planned for, the engineering manager was quite emphatic on this subject, that the team ensured that all the required architecture and design work was planned and the team ensured that in discussions with the Product Owner, these were incorporated into the Product Backlog and actually implemented as part of ongoing Sprints.
Sometimes, such an approach can be problematic. Part of the philosophy about Agile that I have heard often enough is the need to avoid doing unnecessary work. Sometimes, it does happen that the architecture work that is planned for the cycle is actually an overkill, and when the work is done, you realize later that the feature for which this architecture was planned and executed was not required. This can be painful, and when such a scenario occurs, there can be disagreements with the Product Owner. We had a case once before where we were supposed to be building a great new feature that dealt with the interaction between the client server application and an internet based client chat and forum system. This system was not in place earlier, and hence the entire application layer that dealt with integration of the API’s of the web application was integrated, so that in later cycles, the user interface would be built and tested. However, in a change of plan (caused due to new features integrated by an opponent), we dropped the internet based system integration and built in a new feature that was a core feature.
As a result, all the architecture work that we built in had to be dropped, and all the time that was spent in this work was also wasted. Also, there was no certainty that the work that was done would be used sometime in the future, since the feature may or may not be needed in the future. On the other hand, if we needed to put in the feature, it was necessary to make the architecture change in earlier Sprints, so that the software had the base built for the user interface feature. This was a ‘necessary evil’, and in the end, if the feature was needed to be done, the necessary architecture was required to be in place in advance. For most features that are big and require such architecture work, such planning is required.

Problem in Scrum: Inability to prioritize the architectural and design tasks – Part 1

ashish — Fri, 30 Sep 2011 19:18:34 +0000

Over a period of time, some of the discussions that I have had with fellow managers, and more specifically with managers who play the role of Scrum Masters come to a conclusion revealing a weakness in Scrum implementation. Projects where there is initial time spent on planning the architecture and design for the end project tend to have a good design that is scalable, where the individual components (and the flow between them) and the overall design has been well thought out. Sometimes, the amount of time spent in design and architecture seems like an overkill, but in most cases, the amount of time spent is the amount of time required for such activities.
However, one of the biggest problems that has been seen in the implementations of Scrum that I have observed relates to the planning for design tasks. In a typical waterfall methodology, the schedule is split into properly defined and demarcated times for the implementation of all the design work, and the product seems all the better for that. However, when you get into the game of having a Sprint where all the User Stories for that Sprint should be implemented by the end of the Sprint, where the Product Manager defines all the User Stories (and is lead to believe that the Product Owner controls a large chunk of what the engineering team is actually doing). As a result, when you have design tasks that could take multiple Sprints to complete, many times the engineering team cribs about the limited amount of time that they get for doing such a task and believe that the design work is not really complete and can cause problems as the project schedule moves ahead.
Consider the case where the User Stories are defined and added to the Product Backlog. Ideally, these should include the tasks related to design and architecture so that they can be properly prioritized and planned for completion in the required Sprint cycles. But, when the overall requirements are not constant, or are broken down into small parts, it does get more difficult to come up with a proper and structured design document which covers the need. In addition, for many teams, it can be hard to convince the Product Owner about the need to do large architectural tasks, especially when they do not relate to features, or may be needed for features that may or may not be required.
Overcoming such challenges requires a lot of planning, and some work outside the regular Sprint planning cycle, but teams need to do this in order to ensure that they have a good design.

Scrum – Having to make crucial product decisions, and yet not aware of the overall design of the product

ashish — Wed, 27 Apr 2011 18:48:11 +0000

This is a Scrum story that does not have any easy solutions, and yet we faced these many times. It could be because our working of the Scrum process was imperfect, or could be because of the way that the relationships between the Scrum team and the Product Owner were setup. So, if any of you readers have any comment on what we could do to improve things, do let us know.
The story is around designing a complex product in Scrum. The product has various modules, various dialogs, several workflows, some of them inter-dependent, and others that feed into each other. For such a product, the design complexity in terms of architecture was fairly complicated, and we needed to get a good architect in place to work through the various components. As a result, it was necessary that a certain logic in terms of which component got created at what stage was required, and in a conventional workflow, we would have insisted on getting this design workflow as part of the items that needed to be done.
In the Scrum based system, we had to depend on User Stories written by the Product Owner, and as a result, it was a challenge to get the Product Owner to understand the User Story in the form of a design relationship, as well as the sequence in which these design stories were made and the necessity of getting them. Our Product Owner was a very confident person, and it was difficult sometimes to get the Product Owner to understand that an entire Sprint was to be spent in design steps, and there would not be something that would be delivered in the form of User facing features at the end of the Sprint.
Sometimes the discussion would get very difficult indeed, and it was beyond the power of the Scrum team to convince the Scrum team, and we would need to get more stakeholders involved; but the sponsor of the project was fine since he felt that having such a Product Owner would be like a check on the engineering team, and ensure that only those elements of design was done which were necessary. This was however pretty frustrating for the Scrum team.