Sprinting: the Scrum experience

Scrum is an Agile PD process, which is seemingly becoming very popular in the industry. So I thought of writing about it a bit. I was fortunate to work on two projects – one was using scrum the other was not. So I could see the difference between the two. Let me share some of my experiences with you.

The worst problem with scrum is - you land up working hard all through the product lifecycle :(

Implementational approach
My feeling has been that Scrum has a very ‘implementational’ character. Implementational? A very focused approach to ‘implementation’ than design, exploration or research. It’s very effective if you know what you are implementing. Thus this basic implementation approach most of the times conflicts with design. Which by character is more exploratory and research oriented. Design due to its subjective character involves a lot of analysis and discussions (with shareholders, PMs etc).

Design: subjective (& dynamic in internet business)
Another issue with design is that it has dependences on business; any changes in business and strategy could substantially influence the approach to design and design solution. Thus it becomes critical how and when you use Scrum for design. Suddenly a competitor comes in the market and you have to rethink strategies and design; thus in internet business the situation is very dynamic. You should always be ready to change you approach to your environment.

It would be recommended that design comes into scrum with a little ‘home work’. The earlier phases of research and exploration should be kept out of scrum. Build up a little understanding of the project and then start sprinting. Otherwise the problem would be that by end of the sprints you might not have a substantial ‘deliverable’. Though you might have done a lot to understand the project you may not necessarily have some thing concrete to share with you non designer teammates. If you are the only designer then you can understand you might understand your situation would be tough. Some people call this ‘Sprint 0’. I would say this is important.

Involvement and sharing
One of the best part of scrum. It keeps you ‘involved’. You know various components of the system – from data; to backend engineering to front end etc. Also it gives the designer an opportunity to educate and make the engineers aware about design issues. When people know what you do - they tend to respect you. Sometimes you will land up at a situation where you feel a certain engineering weakness/error/problem could be countered through ‘design’. Thus it keeps you involved.

Pressure to be ahead of you engineering and time estimation
Using scrum you’ll be constantly finding a sense of urgency to be ahead of your development teams. You don’t want to be blamed for slowing down the project. Thus you have to be at least a sprint ahead of the developers.

Another common problem is that you will never be very sure of the time for your tasks. Design often is dynamic and keeps changing through the course of the lifecycle no matter how hard you try. Even there is a restriction (by Scrum) on PMs interfering with their basic task; still you will encounter changes or suggestions that may have a significant impact on your work or time.

The best idea would be to keep your task broad and a bit generic with more time allotted. This will also give you some buffer time to explore and to some extent nullify the estimation issues.

What worked for me was for a 3 week sprint was that I used to keep one day off. This used to give me some time to explore or even reflect on my designs (which is very helpful if you are most of the time in the implementation mode.)

If you follow the ‘spirit’ of scrum I’m sure you will like it. Especially if you are the curious kinds who want to know all about the product you are working on.

Trust & Design – its all about trust

Design is subjective by character. Design shapes up the way you build it. Every stage & every element that needs to be designed have multiple solutions. Every solution has its own pros and cons. And what you choose defines the next set of options you will get in the next stage. Not only do you have to think of elements alone but also how they interact with the rest of the elements. Thus design is subjective – it all depends on the design decision that we take along the process.

Subjectivity & multiple solutions: call for conflict
This subjectivity and multiple solutions create conflict in design. If you are a designer and work with Product Managers you would have faced these kinds of debates. There would be occasions when you would land up in a situation where the design choices are even. Both have their own qualities. What do you do? Use reasoning of course. And to add to the complexity in designer’s life – every one can think about design. It’s something that every one encounters and thus they have ideas or opinions about it. Design is primarily thought driven than skill driven; and thus every one can think. The only differentiator for designer is the ‘awareness’ and his ability analyze more parameters than the untrained designers.

Trust
Thus a designer’s job isn’t only to provide design solutions; there is a lot that goes ‘behind the scene’. As a designer the first thing you want to do is build ‘respect’ and ‘trust’. Very often you would land us in these 50-50 choices; and here how much you team trust you makes a huge difference. Not every small decision can be tested with user thus you need to be responsible and careful with your design decisions. One error and you’ll lose you ‘veto’ power.

Moving to new team? You are back to zero
This could be one of the reasons why some designers don’t want to shift teams. Every time you move to another team you are back to ‘zero’. You again have to build your respect and trust. As design is subjective unlike mathematics or engineering so it becomes really difficult to prove your solutions.

I guess ‘design’ is all about ‘trust’ – trust in you decisions and trust in you by your team.