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.
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.
4 comments:
Interesting thoughts. I started a company to work on agile and scrum myself.
Would have been interesting to talk to you about your experiences at DCamp.
So how does it work at Yahoo? Do you do the design in a previous sprint compared to the development?
Hi Siddhi,
During the development process there are dependencies on design - both from the feature and UI perspective. If these are not ready before the development the project gets stalled. Thus you have to foresee these dependencies and keep the design cycle ahead.
Unfortunately I could not attend the DCamp. I was out of town. But I heard it went very well.
I actually enjoyed reading through this posting.Many thanks.
Hi there, awesome site. I thought the topics you posted on were very interesting. I tried to add your RSS to my feed reader and it a few. take a look at it, hopefully I can add you and follow.
Scrum Process
Post a Comment