Gaurav asks in this comment why we chose Crystal Clear.
The reason is simple. We wanted a process that would actually improve the work we did. There are a lot of companies that claim to be CMM-Level 5 and what not, but in actual reality they don't really follow the process. It's only when the audit comes around that everyone pretends to be following the process. We didn't want this to happen.
Most processes are high discipline. They are great in theory - if you followed everything perfectly, then you would get results. But not many people actually follow the process, because it is so much of a pain to do that. So either the process lies around unused or you have a "process department" to force everyone to use the process, neither of which is the right solution.
Crystal Clear is designed to be followed. It just has the three rules (or properties) I mentioned in the previous post. If you take two teams, one following a high discipline process and one following Crystal Clear, then chances are the one following the high discipline process will have better results. However, take a team which is supposed to be following a high discipline process, but is actually not following it and compare with a team following Crystal Clear, then the advantage goes to Crystal Clear.
So, the question was would we prefer to have a great process that no one follows, or a simple process that everyone would like to follow? For us, the answer was a no-brainer, and we went with the latter.
Another factor was that many high discipline process do not scale down easily to small teams. Crystal Clear follows the opposite path, it is optimised for small teams and scales up for higher team sizes.
Finally, the third property of crystal clear (reflective improvement) ensures that any changes to the process are introduced from within the team. Teams introduce additional processes according to the challenges that they face. All process changes are therefore bottom-up rather than top-down.
I'll talk more about this when discussing reflective improvement.
This post is a part of the selected archive.
Flickr Badge
Friday, May 27, 2005
Out of town
I'll be out of town for the next two weeks, so I won't be blogging till I get back.
I'll continue posts on Crystal Clear when I get back.
I'll continue posts on Crystal Clear when I get back.
Tuesday, May 24, 2005
Crystal Clear - Frequent Delivery
Crystal Clear is a lightweight agile process primarily intended for small teams (< 10 people) and projects which are not life critical - you wouldn't use this to control a nuclear reactor or to send a man to the moon. Unlike most other rules heavy processes, there are only three "rules" in Crystal:
Frequent Delivery
Crystal Clear is based on the premise that the ultimate success of any software is to have a satisfied customer. This may be what is written in the specification but more often than not, it is different from the specification. When the customer embarks on a project, they themselves are not exactly clear as to what is possible by the software. As the software is developed, they get a clearer picture of the software and usually have some changes to how the software operates.
Traditional (non-agile) processes place a great deal of emphasis on having a detailed specification which is agreed upon at the beginning and signed off by both parties. When the software is finally delivered, the customer often finds that the software doesn't do what they had in mind, while the developers point to the spec and show how everything that was agreed upon has been implemented. Making changes at this point could cause massive redesigns, but at the same time the customer is not happy with the product. Neither side is willing to move, with the result that the software is ultimately a failure.
Crystal Clear emphasises frequent delivery instead. Deliver working software to the customer every few weeks. This has two major advantages. One, the customer has some working software with periodic updates. This keeps up the customer's confidence high that progress is happening. It also gives the customer visibility into the project and enables them to keep track of the progress. Secondly, it gives them the opportunity to use the software and come back with feedback. This feedback is easier to incorporate because the software is still in development.
Another advantage of frequent delivery is that it also gives confidence to the developers that the project is moving forward. It builds morale when you see new features in the hands of the customer every few weeks. There is nothing as draining to developer morale as long projects with no end in sight.
Delivery cycles in Crystal Clear are around 3 weeks to a couple of months in duration. During a delivery cycle, you pick the features, implement, integrate and test them and then pass it on to the customer. The actual duration of the delivery cycle depends upon the project. The delivery cycle should give enough time to implement, integrate and test a few features. Apart from that, shorter delivery cycles mean quicker feedback from the customer.
Thats it for frequent delivery. I'll cover osmotic communication and reflective improvement next.
This post is a part of the selected archive.
- Frequent Delivery
- Osmotic Communication
- Reflective Improvement
Frequent Delivery
Crystal Clear is based on the premise that the ultimate success of any software is to have a satisfied customer. This may be what is written in the specification but more often than not, it is different from the specification. When the customer embarks on a project, they themselves are not exactly clear as to what is possible by the software. As the software is developed, they get a clearer picture of the software and usually have some changes to how the software operates.
Traditional (non-agile) processes place a great deal of emphasis on having a detailed specification which is agreed upon at the beginning and signed off by both parties. When the software is finally delivered, the customer often finds that the software doesn't do what they had in mind, while the developers point to the spec and show how everything that was agreed upon has been implemented. Making changes at this point could cause massive redesigns, but at the same time the customer is not happy with the product. Neither side is willing to move, with the result that the software is ultimately a failure.
Crystal Clear emphasises frequent delivery instead. Deliver working software to the customer every few weeks. This has two major advantages. One, the customer has some working software with periodic updates. This keeps up the customer's confidence high that progress is happening. It also gives the customer visibility into the project and enables them to keep track of the progress. Secondly, it gives them the opportunity to use the software and come back with feedback. This feedback is easier to incorporate because the software is still in development.
Another advantage of frequent delivery is that it also gives confidence to the developers that the project is moving forward. It builds morale when you see new features in the hands of the customer every few weeks. There is nothing as draining to developer morale as long projects with no end in sight.
Delivery cycles in Crystal Clear are around 3 weeks to a couple of months in duration. During a delivery cycle, you pick the features, implement, integrate and test them and then pass it on to the customer. The actual duration of the delivery cycle depends upon the project. The delivery cycle should give enough time to implement, integrate and test a few features. Apart from that, shorter delivery cycles mean quicker feedback from the customer.
Thats it for frequent delivery. I'll cover osmotic communication and reflective improvement next.
This post is a part of the selected archive.
Monday, May 23, 2005
del.icio.us: bookmark this
I just saw this post on the del.icio.us blog on how you can add a Bookmark This link for each post. I've added it to my blog here. Now, if you want to bookmark a particular post, you can just click on the Bookmark This link and add it to your del.icio.us list. Pretty cool! I use del.icio.us to keep track of my bookmarks and it would be awesome if other sites also had something like this.
Saturday, May 21, 2005
Processes in a small company
Remember Agile India 2005? One of the reasons I had attended it was because my company was interested in introducing some processes. Gaurav's post woke me up and reminded me to write about my experiences with them.
The final outcome was that my team (7 people) adopted the Crystal Clear process. This is a relatively less known process compared to Waterfall, Spiral or XP. I'll be writing more on Crystal Clear, and why we chose it in the next few days. In the meantime, check out the Crystal Clear website.
The final outcome was that my team (7 people) adopted the Crystal Clear process. This is a relatively less known process compared to Waterfall, Spiral or XP. I'll be writing more on Crystal Clear, and why we chose it in the next few days. In the meantime, check out the Crystal Clear website.
Conversational Blogging
Dina has a good blog post titled Conversational Blogging. In it she says "I find I am so let down when I read a post without comments".
There has been a lot of discussion about what make a blog. Is it the personal voice, or is it that readers can add comments? Or is it about linking to other posts?
The first thing to realise is that it doesn't really matter whether your blog is really a blog or not. The only thing that really matters is that you have some interesent in posting and your readers have some interest in reading it. Whether you call it a blog or a frequently updated website is really irrelevant.
That said, how do I identify a site as a blog rather than a website? For me, I agree with this post by Amit that the main thing is the distinctive voice of the writer. But all this is just to name the page as a blog or website, which like I stated above is really quite irrelevant. If the page is compelling, it doesn't really matter whether you call it a blog or not.
Now, coming back to the comments part. Some blogs don't really need comments. This is especially true of link blogs which just provide links or reproduce other posts with maybe a small commentary. However, blogs with essay type posts greatly benefit from having comments open.
Very often I've encountered posts that I would like to have commented on but the comments are off and I can't really get down to crafting out an email. What's more, I can't see what everyone else thinks about it either. The result is that there is no real conversation. The flip side is comment spam/trolls. Its irritating for sure. Blogger doesn't have any good method of preventing comment spam, but if you're hosting your own blog there are some solutions to it.
So comments are definately needed if you are into the whole "blogging is conversation" idea. If you are not into it, then you can get by without comments. I definately think that the power of blogging is the conversations that it generates, and therefore have my comments on, but if you don't believe so then thats fine too.
Here is a small example to show what I mean. Read Amit's original post, and then read this cross-posted version with comments enabled (read the comments too). Which one is more enriching? My vote goes for the version with comments.
There has been a lot of discussion about what make a blog. Is it the personal voice, or is it that readers can add comments? Or is it about linking to other posts?
The first thing to realise is that it doesn't really matter whether your blog is really a blog or not. The only thing that really matters is that you have some interesent in posting and your readers have some interest in reading it. Whether you call it a blog or a frequently updated website is really irrelevant.
That said, how do I identify a site as a blog rather than a website? For me, I agree with this post by Amit that the main thing is the distinctive voice of the writer. But all this is just to name the page as a blog or website, which like I stated above is really quite irrelevant. If the page is compelling, it doesn't really matter whether you call it a blog or not.
Now, coming back to the comments part. Some blogs don't really need comments. This is especially true of link blogs which just provide links or reproduce other posts with maybe a small commentary. However, blogs with essay type posts greatly benefit from having comments open.
Very often I've encountered posts that I would like to have commented on but the comments are off and I can't really get down to crafting out an email. What's more, I can't see what everyone else thinks about it either. The result is that there is no real conversation. The flip side is comment spam/trolls. Its irritating for sure. Blogger doesn't have any good method of preventing comment spam, but if you're hosting your own blog there are some solutions to it.
So comments are definately needed if you are into the whole "blogging is conversation" idea. If you are not into it, then you can get by without comments. I definately think that the power of blogging is the conversations that it generates, and therefore have my comments on, but if you don't believe so then thats fine too.
Here is a small example to show what I mean. Read Amit's original post, and then read this cross-posted version with comments enabled (read the comments too). Which one is more enriching? My vote goes for the version with comments.
Monday, May 16, 2005
Future of corporate blogging?
eWeek has this cartoon on corporate blogging. While its meant to be a bit funny, I can see the day when something like this actually happens.
Friday, May 13, 2005
Tuesday, May 10, 2005
Friday, May 06, 2005
Fixed vs Liquid reopened
Matt Linderman at Signal vs Noise reopens the fixed vs liquid debate. Check out the comments too.
The main reason for most websites not adopting liquid layout is line length readability. I changed my site layout a few months ago from fixed (which was the blogger default) to liquid.
At 800x600 and 1024x768 it gives about 10-15 words per line, which is about optimum for reading. Higher resolutions can cause the main text width to get too big to be easily readable. This can be solved by using the CSS max-width property, but I've not implemented it yet.
Another advantage is in accesibility. When the user changes the font size, the layout remains consistent without text overflowing from one column into another.
Another reason, which is specific to my site layout is that it gives more space for the photo thumbnails at the top of the page. At 1024x768 it spaces out the thumbnails nicely with a pleasing margin at the sides. In the previous design, they were restricted to about 760 pixels of width leading to some amount of cramping. The flip side is that they now take two rows at 800x600.
Fixed width designs can be good in situations where there are a lot of fixed width elements in the design (images etc). They are also good when designers need control of the design to maintain some identity. The main problem with liquid designs, the line length readability issue can be solved with the max-width property.
Otherwise I feel more people should give liquid layouts a try. If it doesn't work, it can always be thrown away, but the sad part is that most people don't even try it, prefering instead to copy a fixed width design from somewhere because everyone else is doing it.
The main reason for most websites not adopting liquid layout is line length readability. I changed my site layout a few months ago from fixed (which was the blogger default) to liquid.
At 800x600 and 1024x768 it gives about 10-15 words per line, which is about optimum for reading. Higher resolutions can cause the main text width to get too big to be easily readable. This can be solved by using the CSS max-width property, but I've not implemented it yet.
Another advantage is in accesibility. When the user changes the font size, the layout remains consistent without text overflowing from one column into another.
Another reason, which is specific to my site layout is that it gives more space for the photo thumbnails at the top of the page. At 1024x768 it spaces out the thumbnails nicely with a pleasing margin at the sides. In the previous design, they were restricted to about 760 pixels of width leading to some amount of cramping. The flip side is that they now take two rows at 800x600.
Fixed width designs can be good in situations where there are a lot of fixed width elements in the design (images etc). They are also good when designers need control of the design to maintain some identity. The main problem with liquid designs, the line length readability issue can be solved with the max-width property.
Otherwise I feel more people should give liquid layouts a try. If it doesn't work, it can always be thrown away, but the sad part is that most people don't even try it, prefering instead to copy a fixed width design from somewhere because everyone else is doing it.
Subscribe to:
Posts (Atom)