What's up next?

Hello Readers:
Wish you all are doing great as the Spring already started :-)
Recently my grad courses are keeping me busy with assignments and projects as the term comes close to an end. So, I haven't had much time to spend on blogging other than posting the Ruby on Rails link blog called www.DrinkRails.com. However, for my readers, I thought I would post the recent presentation that I put for the Agile course here:

But I am looking forward to start a new project with Wairever (www.Wairever.com), a Calgary based health care IT solution vendor. I hope that will fuel me with a lot of new concepts and as always, I will try to keep my learning posted here at my blog. Stay tuned! BTW, if you are Ruby on Rails developer or wanna be so, please let me know your feedback about the DrinkRails.com link blog.

"Promises are meant to be broken" and my 2010 promises

"One must have a good memory to be able to keep the promises that one makes"

--Friedrich Nietzsche

"Promises are like the full moon, if they are not kept at once they diminish day by day"

--German Proverb

“Better a broken promise than none at all.”

--Mark Twain

Its always good to refer to previous experiences when you do a research. This doesn't only make you fair but also eliminates the reinventing the wheel problem! Well, this is what I learned from my graduate studies :-)

So, what is this about promises today? Well, you know its the time of the year when you have vacations and enjoy with family and friends... and start thinking about the next year. Make some rough plans probably for the upcoming year. Here is what I am promising-

1. By January 1, find two potential MS research topics and draw an outline of each!
2. By January 1, reduce 1kg weight!

What's next? Well, I have a vision of the future but trying to be agile here. Not doing lot of useless upfront thinking and leaving it up to the retrospect session on January 1 :-) I believe agile works and so if I can follow the spirits, I should be able to reach my vision on time.

My readers can wait till Jan 1 to get the retrospect report! I will be blatant and truthful (and this is a promise!).

Lean Thinking: You will probably like to learn the essence of agile

Image taken from: http://www.leansoftwareinstitute.com/images/img_bigpicture.jpg

If you read the Poppendieck's book called, "Lean Software Development : An Agile Toolkit", you probably liked it because it managed to get the essence out of agile practices. So, what are these core principles? Well, most of you already know the phrase, "Inspect and Adapt". Now, you also know a bunch of specifications that facilitate this, for an instance, Scrum, XP etc.

Reading the book, I had a realization that, its good to talk using concrete facts as much as possible. So, doing a value stream mapping practice is worth than spending hours in discussing the process optimization. The same holds true with the Profit and Loss statement when figuring out which option to take - quality compromise, deadline shifting or feature squeezing. Being able to answer why questions, at least 5 in a succession, is something very critical - then you know the hidden junk thats causing the bad smell. I highly recommend reading this book, especially to people who are doing agile for a year or so and thinking about getting better at it.

I also had the opportunity to attend a speech by the authors on this Monday. The speech was a great one. But for my readers, I will write about an example from the speech.

Once Mary and Tom visited a company that creates hardware and software tools for real time video conferencing. They met the Boss there and asked what they were doing. The answer was, "We are working to improve the system so that our customers get better video conferencing solution for their businesses." They went to a section where people were working on hardware and asked one what he was doing. The person replied, "I am creating a component for the system, so that our customers can do better video conferencing". Then they went to a software developer and asked what she was doing. She replied, "I am working to improve a part of the software so that our customers can do better video conferencing".... (I am sure Mary used better words than mine and it was really interesting to hear the story in her voice :-))

So, the fact that she wanted to capture using this example is, although each individual is involved in a specific task, they envision the bigger picture from the customers' standpoint. This is really important. Because as soon as you start seeing the views from the customers' perspective, you will produce less bugs. In the book they mentioned, most software bugs are not results of coding/design errors, rather they arise from the difference in views among customers and developers.

Overall, it was a pleasure to read the book, although this blog post may not reflect all of my respect and take home from the book :-(

Communicating tools for working on remote projects

Ever since I started working in the software industry, as a freelancer or representing a company, I found the most challenging part of a remote software development project is "Communication". In agile setup, collaboration plays a leading role to be effective and efficient.

By communication, I mean the following:-

1. Getting the spec as intended by the client.
2. Asking specific questions on time.
3. Status update about progress, blocks and forthcoming events.
4. Getting feedback as intended by the client.
5. Making specific suggestions with rationale to the client.

I am listing a few tools that I used and recommend others to use.

1. A note pad: I write down small bullet points as soon as I find a question/suggestion/idea.
2. Voice chat/telephone call: It should be #1 preference. Its real time and most speedy after face-to-face. I use Skype for my voice calls and sometimes my phone as well.
3. IM: I use GoogleTalk most of the time if it works with client. Otherwise, I just use the one that my client uses most frequently.
4. Collaboration tool: I use ScrumPad.com. Post my messages, people get email notification and can directly reply on that notification. This way the collaboration is all captured in ScrumPad and we can also keep using Email.
5. A wire framing/drawing tool: Sometimes a small sketch/piece of drawing may greatly ease the communication hurdle. I use MS Visio at times. However, I also use scanned copies of hand drawings and annotations. It works. However, I am looking for a good web based wire framing tool and I believe it will off-load a lot of decision confusions.
6. Desktop sharing tool: Screen capture and desktop sharing also works for me. I use LogMeIn and Xing. These tools offer first class feedback capturing capability from remote clients.

I also try to follow some general rules:

1. Always have a prioritized list of points that I want to discuss.
2. Be on time.
3. Never stay disconnected for more than 3 business days.

I am sure out-sourcing will keep growing in the coming days, not only for its low cost but also for the fact that they are getting smarter and equally competent as people who charge many folds compared to them. I also anticipate a lot of out-sourcing job will go to individuals or 2/3 person groups, may be not from fortune 500 companies, but there are still other unfortunate millions of companies who will need such small teams. If you plan to work remotely, I am sure you will need some of the above tools, and if you are already in the business and think you have other good tools, please share with me.

The CGI story on agile scaling success on a large project

This intro is from the presenters:-

PAS was a joint venture development initiative by 4 major oil and gas
companies and CGI. Devon, Encana, Husky and Talisman joined with CGI to
develop a new Production and Revenue Application. Each company put 3 senior
business resources on the project. The development component of the PAS
initiative cost $35M over 5 years with up to 90 people on the team. This
presentation is on how we used Agile to achieve this mammoth undertaking.

The product is currently running in production at 5 major oil and gas
companies with great reviews. It is also in production for several mid and
smaller sized companies. CGI is currently marketing the product.

This was my first ever meet with the Calgary agile methods user group, CAMUG and it was a great experience. Off late, I have been looking for my graduate research topic on agile methods, especially around scaling agile beyond a single team and this was just a perfect session for me.

I noted down a few of their discussed topics that I would like to share with my readers:

1. The project continued in dev mode for 5 years, a $35M project.
   
2. It started with only 3 members and extended to a team of 90 following Scrum+XP.
   
3. The project had 5 sponsoring companies or clients.
4. They had 6 teams working in the same sprint cycles.
5. In each team, there were significant members from the business working full time with the team onsite and in the same open-space arrangement.
6. They had some 3000+ unit tests and also 300+ acceptance test.
7. They automated all repetitive tests.
8. The had external experts visiting them from time to time. Eric Evans once visited them and helped them getting better grasp on Domain Driven Design.
9. There had been a $800K and one month deviation from the projected cost and timeline.

They also discussed some issues related to working in a multi-team, multi-client project. I remember the following ones:-

1. They had to balance between features/bug fixes.
2. The deployment was taken care of by the respective sponsors, not the teams.
3. They had issues with sprint backlog management.

They highlighted some aspects with great emphasis:-

1. Open communication is the key to success.
2. Onsite and full time real user availability is very important for such a big project.
3. Automated tests, partial pair programming and continuous integration is a big plus.
4. Staying co-located was really helpful.

What about scaling beyond?

1. I asked them, if they felt it would still be a similar success if there had been 12 teams or even more with 200 people or so. They said, it would be challenging. But in response, they also said, following waterfall would make life much harder with such a big team, if at all it could be a success at the first place! Yes, I also believe this.
2. One of the audiences asked if they outsourced a part of the project and the response was 'No'. CGI has a big team in India with a very high CMM ranking, but the project manager and asst. project manager said, it would be much difficult for differing time zones. Also, it would be difficult to transfer the knowledge as well as replicate the value of onsite client presence. The development manager also added that, the cultural difference between an agile and CMM setup would also been an issue if they had to go for the off-shore team.

The session was much more eventful than what I could compile. So, if you are anywhere near Calgary and interested about meeting agile practitioners from the industry, lets meet at the next meet! 

 

 

Rambling stories from my days @ Code71 : Startup days

Sighs!

Back then, on Friday, May 26, 2006, I was a final year undergrad student at CSE, BUET. I was looking for a part-time software dev job opportunity and found a little one page advert for a student job at asha-technologies (lately renamed as Code71). Visited their website and thought it might be worth giving a try!

As usual, I was interviewed over phone and enjoyed a long 2 hour interview on premise. I found it really inspiring and gained more interest towards the job after this session. I started waiting for a response… but was pretty certain about a positive one!

Good things happen in quick successions in our lives. Agree?

I agree. Because I just started a soul-journey with my soul-mate, Shahana, on the March of 2006. Then got the job offer on the 26th of May! Couldn’t be happier. A job for me during that time was just beyond its compensation, it was an inspiration, opportunity to see the real world and being part of something bigger than myself.

Photo taken at Chhera dip (The Torn Island), St. Martins, Bangladesh. The last photograph taken with my first digital camera bought from my first month’s Salary!

I started my job on the 1st of June, 2006 at Asha-technologies. Asha-tech was still to find an office and Omar asked to meet him at his home office! That’s how it all started. We met a few times a week at Omar’s home until we moved to our office at the green building of green square at green road, Dhaka on the first of July.

Asha-tech signed up a client before it was even formed! So, once we moved into the office, we were building our first asha-tech product, an online loan financing gateway. We were enthusiastic about agile scrum/xp practices from the first day at office. The result was found in just less than 3 months. We rolled out our first release of the product. It was really a happy start. A fantastic start for a start-up. The client started generating revenue in less than 3 months of project inception!

The office setup was a small but adequate enough for our team. We installed long backup UPS (2 hours * 5 computers), A/C, IPS and dedicated internet connection with Wi-Fi. The work environment was full of fun. We were going for an outing to a team event every month and even more often going to delicious buffet places. We played table football and bowling… every time had a record breaking score and a new winner. We went swimming and believe me, Omar is as good a swimmer as he is a master in software technology. He would go to swimming with a flipper and flip like professional swimmers. He can even swim without using his hands/legs at all, lying side-on and in all such actions… I learned swimming keeping heads down and the easy way of breathing from him! Thanks!

Technologically we were maturing as well. Started using XPlanner for managing our project, attended daily standup meetings and started doing TDD. I won’t claim we got everything right at the first try… but, we were trying consistently, improving bit by bit… to this day.

For the most part, I was enjoying my job and became used to the pressure of a job + undergraduate studies. I said, good things happen in close succession. Another proof here! My first term final result with this job was a 4.0/4.0. I never scored 4.0 in a term before this nor had a 20+ hour/week job alongside my studies.

I strongly believe, my job taught me the attitude towards work, “plan, act and retrospect”. After over three years, I would suggest any new entrant in the software industry to start a career with passion. Its fun with passion. Its a win everyday with passion.

Lesson#2: Pace Your Sprint Rightly

In my previous post, I said about being incremental. Here come the next thing, being “ITERATIVE”. A prefer the term Sprint than Iteration.

So, once you decided to take small increments, make sure you reach the targets sprinting.

I suggest you prepare for sprinting with the right techniques and tools. A few recommendations-

1. Never miss a daily standup meeting. Spend only 2 minutes (or less) per person answering the three questions – what did you do yesterday, what’s on the plate for today and what is blocking the race?
2. Install visual clues for bringing the under the hood stuffs to daylight. Remember, being able to address the loopholes is the key. The solution usually follows automatically.

The key concept to internalize is, sprinting is a balance race. You need a good start and keep the momentum to reach the touch line on time. Its a small race and if you fall back, the touch line may seem too far to celebrate.

At Code71, ScrumPad, is helping us in sprinting. Our sprints are two week sprints in most projects. We found the team communication holds a key in meeting the deadline. Since, within a sprint, someone of the team may need an unplanned vacation or an issue may arise out of the blue, the team needs to step up and put extra efforts. Again, visual clues help the team in keeping everybody posted timely.

If a team finds it difficult to meet the deadline and find the sprint length to be too small, then what? Should they linger the sprint length? NO. The solution is to even shorten the length. To make sure, the team can plan for short spans with better accuracy. Lingering the sprint length addresses the wrong disease and hence may not solve the problem.

Lesson#1: Going Incremental is Natural!

As Scrum and Agile processes tell you, do it in small sprints, 2 weeks preferably, and go incremental. Take a small piece at a time and sprint.

I took this image from internet and credits to this site.

It’s easy to work out the Natural way than to defy it! If you are iterative and incremental, you are reaching towards the right hand side of the image! And to make the evolution faster, I suggest you try out Scrumming with ScrumPad. If you value “teaming” and “delivering” in sprints, ScrumPad will give you the oxygen to breathe while you sprint!

I suggest you follow a routine to iterate. At Code71, we follow the below-

Day 1: Plan for the next 9 days. Breakdown work items into smaller tasks, estimate at hours for each of the tasks and assign each task to an individual.

Day 8: Release in test server (shadow version of the real production environment) and collect customer feedback.

Day 9: Work on customer feedback and go live in production server. Always tag the version that is put in the production following the standard -

R<ProductReleaseVersion>.S<SprintNumber>.B<BuildNumber>.P<PatchNumber>

This gives us the rollback point when there is any issue in the latest production deploy. Of course, we make sure we do not need to touch on the tags too often!

How are you sprinting? Let me know if you have a suggestion.

Its easier to get lost! Would you?

I was talking to a friend of mine, who started a IT start up and working full time with a few others to foster the business. He was telling me-

“We have 13 projects running at this moment. We are working our heart out. But, we are not finding any time to do Test Driven Development, Continuous Integration and all the good things…”

Well, I understand how it feels! As the title says, “Its easier to get lost!”

 

Do you fancy getting stuck at this maze?

For startups, it is difficult to control the pulse. Because, you want to reach your billion dollar spot as early as possible, this week, or even earlier, today or even just in a few hours! And, as days go by, you start to feel the need for some process, to safeguard your efforts and quality, to hit the deadlines, to get in the rhythm of a sustainable pace.

But it may be really difficult to catch the ball at the first jump. We, at Code71, believe we need to be visibly competent and confident about the quality of our work. And worked hard to get the gears together in motion. Now it is cliques great. We have got the people motivated to follow the best practices, the tools to “do more with less” and the process to ensure a “sustainable pace”. I advise, you do at least the following to learn to escape the maze from tomorrow-

• DIE for planning. Plan for short spans. We plan for two week sprints.
• While planning, estimate honestly. Estimate all the hours necessary for following best practices. (producing automated test scripts may take 40% longer time, but bear with it)
• Plan on your inputs. You cannot push your inputs. So, you may need to squeeze the output to match against your capacity.
• DIE to meet the deadline according to the plan.

This is the mindset. You need to start believing to sustain. You need to plan honestly and never miss a deadline. After reaching the deadline, you retrospect. Find the loopholes and start filling those one by one. If you don’t see a loophole, find a ladder to reach higher. But do not place a ladder on a land mine!

Its not difficult if you have the preparation. To prepare, at a minimum do the following-

• Have a Continuous Integration (CI) server up and running 24x7 or DIE. (We use CruiseControl, its free and great)
• Make your CI server to send build, test and coverage report for you. Keep an eye on the coverage report and DIE to remain well above the the 80% line.
• Keep track of your activities for retrospect. We use ScrumPad. It helps you to iterate, collaborate and deliver.

The keyword is “sustainable pace”. I found Scrum to address this sustainable pace really smartly. If you haven’t tried yet and looking for the loopholes to fill or the ladder to climb up, I suggest you learn about agile and Scrum, find an expert and give it a try. It’s worth than you might have expected.

If you know a better way to keep delivering better, I will appreciate for sharing your idea to me.

Pair Programming: How am I feeling?

For an explanation of Pair Programming, please visit this wiki entry.

Good

I am pair programming on the ScrumPad project now and the feeling in general is good. I have this perception is the work quality is better than doing alone. Also, the amount of time wasted to find small issues are now much reduced. Overall, its good.

Productivity Increased

I definitely found the productivity boosted by a factor of 1.5 at least. May be this is specific to my case, as I am working on a mid scale refactoring task. We worked on two user stories so far and completed the stories in 1.5 times faster compared to the individual estimates. We are doing estimation on a regular basis and the variance between estimation and actual hours are less than 5% as we see in the last 17 sprints in this project.

Disclaimer

I am yet new to this practice and not in a position to draw a conclusion yet. However, I believe our open space set-up and strong team culture helped us a lot to start this pair programming.

Are you pairing? Please, share your feelings and suggestions.

Design/Code Review: Now, It's time to realize!

Are you doing code reviews?

Thank God, you are.

Not?

Well, you are not alone. You know, most of your bugs could be killed by reviews. Most of your technical debts could be paid by reviews. Your team could collectively learn more by reviews...

Now, It's time to realize!

Start now! It's simple. I have found the following approach to be useful-

1. Pair up with one developer. Make it explicit to the team. So, you know who reviews your code.
2. Mix up a junior team member with a senior one, if possible.
3. Have a fixed time, at least 30 minutes for each two weeks to do a team design/code review.
4. Do it in small increments. We did the following-

• Sprint#1: Review variable/method/class/file/folder names only.
• Sprint#2: #1 + Review if/else blocks, loops.
• Sprint#3: #2 + Review class responsibilities.
• Sprint#4: #3 + Review test codes only.

The result is really worth

This first level feedback will help you to eliminate a lot of bugs, help in knowledge transfer and collective learning. Roughly, It takes only 10-15 minutes to review a code written in 3 days. I suggest, keep it simple.

One interesting thing is, many times I have found the developer him/herself actually found bugs/mistakes in the code before the reviewer at the time or reviewing.

A reviewer's eye will save lot of your time and money.

Update: Be constructive in your feedback! Example:-

Worst: This code is a piece of ...

Worse: This code is bad

Bad: This code is not good

Good: A better way is..

Better: We can also do it this way...

Best ?

Part 1: How am I IMPACTing following Scrum?

In a previous post in this blog, I introduced the nice little acronym IMPACT for agile. To recap, here is what IMPACT stands for -

"Iterative and Incremental development of a software by means of Merciless refactoring, Peer reviews, Automated acceptance testing, Continuous integration and of course, Test driven development"

To give you a little background around my story, let me tell you about a project that I am working since June 2006. The project is a micro-finance loan application automation server for the US financial industry. It acts as a mediator between a loan seeking customer and one of over 50 lenders in an attempt to get a loan for the customer. So, the server adds value by taking a single application to 50 odd lenders from a single submission unless no lender is left untried or some lender says 'yes' to it. This is done in real time, the processing time in average is less than 3 minutes.

Now that you have the background, let me introduce the the challenges associated with this project. The bullet points are-

• Since this involves real dollars, there is nearly no margin for an error.
• It processes more than a thousand loan applications per hour, so a high availability is a must.
• This is done following agile Scrum and each two week one/two new lending partners need to be integrated.
• The lending partners change their integration API from time to time and we need to accommodate the changes ASAP.

To address these challenges this is how we are responding-

Iterative and Incremental development (IID)

We are following Scrum and using ScrumPad to manage the IID. Basically, our clients/product owners put new requirements in terms of user stories in the product backlog at ScrumPad. So, with the prioritized product backlog we, the team, pick items to a sprint's backlog. Then as usual, we break it down to tasks and do everything that it takes to meet the deadline of two weeks. Within a sprint the following are the milestones-

Day 1	Day 2	Day 3	Day 4	Day 5	Day 6	Day 7	Day 8	Day 9	Day 10
Sprint Planning	Dev & Test	Dev & Test	Dev & Test	Dev & Test	Dev & Test	Dev & Test	Dev & Test	Test Release	Production Release

• 8th day - Sprint works are completed.
• 9th day - Test delivery at a near production environment and feedback gathering from product owner.
• 10th day - Incorporate feedbacks and release in production.

Note that, we generally produce a number of test releases within the first 8 days. That gives us an earlier chance to gather client feedbacks.

The beauty if this approach is, with this model in place we can release as early as in 8 working days, if not earlier. So, this helps us meeting the last two challenges as mentioned above.

Merciless refactoring

Developing incrementally offers much challenge in attaining the longevity of the product. Because, naturally as new features come in, we need to make room for that in the existing implementation.To ensure the quality and life of the product, we do merciless refactoring as we go. We have over 90% unit test coverage, which helps us in doing this continuous refactoring. So, the idea is-

• Writing unit test and acceptance test.
• Refactoring our code/design and validating against automated tests.

Peer reviews

This is probably the most important practice that I recommend. Because, as we had new members in the team, we found that the quality was somewhat degrading. Once, we started peer reviews, it was very helpful to the new comers as well as the veterans to keep the code quality up to the mark. We review the following things-

• Naming of variables, methods, classes, files, namespaces etc.
• Use of private methods for increased readability.
• Hard coded string literals or constants.
• Long/nested loops and long running if-else blocks.
• Code commenting.
• Quality of coding.

I would suggest you to try Microsoft's Stylecop, it will give you a great head start to ensure the first level code quality by enforcing the common rules. This practice is allowing us to continue the good quality over time.

I have always been shy of reading extra large text in the web. So, I thought I could better post this in two parts! I assure, next post will contain more images than texts, So, you better stay tuned for the next one...

Iterative and Incremental implementation of Code Reviews

Extreme Programming (XP) advocates for a pair-programming, taking the code review to its extreme. I have also found that pair programming generates a lot of speed and also helps producing better quality product in the first time. But, at the same time it's difficult to impress the management or prove return on investment associated with pair programming to the business people. So, what is the best possible solution? I believe, we can implement frequent peer code reviews to mimic the pair programming to some extent and get the benefit out of it.

In our team, we started implementing code reviews as we now recognize that there is no way to live without it. As usual, our approach is an iterative and incremental approach. So, we are taking small steps and eventually embracing the best practices in the team. I would like to share our plan here in this blog. The review process goes on the following work flow-

"When I am done with my work on task, I commit the code with the reviewer's name on the svn comment. CCNet automatically builds and sends a mail to the reviewer. The reviewer gets the review email through a filter and reviews the code and sends his feedback to me via IM/email."

Sprint #1: Review all the names or classes, files, methods, variables and so on. So, the reviewer emphasizes on the names and provides feedback on the following things-

1. Is the naming standard correctly followed?

2. Is this a meaningful identifier?

3. Does the name conform to the conventions used elsewhere in the code?

Sprint#2: Review the use of private methods and code structure. The to-do list is -

1. Would it make more sense to put some code into the private method for readability and/or reusability?

2. Is there any hard-coded constant directly used without referring to a const/readonly data type?

3. For all the methods, is it possible to reduce the dependency by using a simple parameter instead of a whole object?

4. Learn from sprint#1 and use the common learning.

Sprint#3: Review the use of loops, if-else blocks. At this iteration, the to-do is-

1. Is it possible to eliminate a loop?

2. Is it possible to avoid the nested loops?

3. Is there a large if-else-if-else block? Why is it required? Is this large conditional block a possible candidate for future change?

4. Learn from sprint#2 and use the common learning.

Well, this is pretty much it. The idea is, we feel its not practical to go with an overnight policy for implementing peer code reviews. But, its very much possible that we do it in small increments and at each sprint's retrospective we bring this point. So, we are all informed that we need to do reviews, which, eventually should sustain as a best practice!

If you think you have some ideas regarding this, please share it with me/my readers.

INVEST - Characteristics of Effective User Stories

In Agile Software Development, for example SCRUM and XP, User Story is a tool to capture the requirements from the clients. The term User Story takes a very free form. Sometimes, we feel that there needs to be a boundary so that a user story is an effective one and not misused. I have a feeling that INVEST defines the border line on this regard.

The INVEST principle is a very good guideline for defining user stories in an agile environment. According to the principle, a user story should have the following characteristics-

Independent, Negotiable, Valuable, Estimable, Small, Testable

For an elaborate description on each of the terms please take a look at the link http://agilesoftwaredevelopment.com/blog/vaibhav/good-user-story-invest

What does a Scrum Master really do?

Hmm! I am now a CSM (Certified Scrum Master) after two days of training with CST Pette Deemer.

You want to congratulate me! Lets congratulate me first-
You: Congratulations! It's really a great news! How does it feel to be a CSM?
Me: Greaaaaaaaat! You know, its so cool that my profile gets a CSM on it!
You: Oh Sohan! I am so sure that you will contribute more at the company?
Me: Yeah, I surely will. I just need a product owner and a team with me to contribute!

(Now that I am so good with the certificate let me be your teacher on 'Scrum Master'ing)

Well, I have been following SCRUM for almost two years in my team and we had a lot of questions in our minds regarding the process. Some of the questions are answered and some are not. But to be very positive, the outcome of the training is good. It clears the philosophy behind SCRUM and also creates a clear vision on why one should follow SCRUM. I will be going on a question answer mode that closely resembles my learning at the training.

Q: Is scrum master a part of the daily scrum meeting?
A: Yes, he is involved, but stays outside the team's SCRUM cycle and takes note whenever someone points out to anything that is a hurdle before the team in meeting sprint commitment.

Q: So, is Scrum Master is a lead role?
A: No. Its rather a helper role to the team.

Q: Is it possible that Scrum Master is not co-located with the team?
A: Generally its bad. It seems unlikely that she can remove blocks from heaven (the distant is always a heaven!).

Q: What are the core responsibilities of the Scrum Master?
A:
Help team to follow SCRUM.
Do anything to remove blocks reported by the team.
Do nothing to create any block for the team.
Update the Burn Down charts, the 'Not Started, Started, Completed' board and other progress indicator 'things'.
Facilitate the team in meetings - avoid unnecessary time loss meetings, manage meeting place and things like laptop, projector, mic and sound systems... all that it takes for the team to have a potentially meaningful and quick meeting.

Q: Is Scrum Master part of the team?
A: Well, it depends. If the team is small and doesn't need/cannot afford a full time scrum master, someone from the team may take on this responsibility. But, a dedicated one is most likely to be effective.

Q: What should be the bullet points of the Scrum Master's characteristics?
A: Helping, self-motivated and feels comfortable to help people on any sort of problem.

Q: Enough is Enough. What else do you know about Scrum Master?
A: Hmm... Scrum Master is not executed if the team does not meet their commitment (unless its because of the fact that the Scrum Master wasn't able to remove blocks). Scrum Master always guards the team from product owner's pressure and change requests in the middle of sprints.

I could have a longer list of Q & A that I have actually learned at the training. But I am not going to do that partly because, I have only a few readers (namely I, me, myself and Sohan) in my blog and partly because I do not see comments on my posts too often.

So, if you have read this and really think you want to know more, energize me with your comments and questions :-). I will be really glad to share my learnings with you.

Prerequisites for IID

Up to now, I have figured out that teams trying to behave agile sometimes fall into the cave of pretending to be agile (e.g. stand up meetings and less than just enough planning and short iterations so on!). Often, when this pretending takes places for days, it creates a illusion on the minds of the people that they might be doing the "right thing". And all on a sudden, someone discovers things are breaking and there is no way out of this disaster!

So, I suggest for teams who are trying to get agile to meet the following prerequisites first-

1. Team members must have a certain level of all-round skills.

So, when we do not preserve seats for requirements gathering, planning and designing and still want a good architected software, we need to make sure we are not asking beyond the capacity of one team member. From my experiences I have found that, even a very good communicating team with enough of discussions and reviews cannot control the quality and integrity of the product when some of the fellows don't meet the all-round skill requirements.

So, an agile team is expected to meet all-round individual skills like
a. Database design concept.
b. Object Oriented design concept (must know about design patterns (e.g. from GoF) and design principles)
c. Standard Coding expertise.
d. Testing sense and writing effective test codes.
e. Understanding the business domain clearly and concisely.
f. Quickly respond to change requests and define effective way to meet system owner's demands.

2. An "agile" skilled team must practice the following

a. Effective Design and design reviews.
b. Good coding at the very first time (if possible).
c. Must write test/guard codes for automated testing.
d. Continuous and periodically re-factorization of the code base and architecture.
d. Some sort of mentoring to make sure things are in rhythm.

3. An "agile" skilled team must use appropriate tools for the "best practices"

a. Use smart collaboration tool to make sure all the stakeholders are on the same ground.
b. Use effective test suits.
c. Version management system.
d. Automated build system and continuous integrations.
e. Project management and time tracking software.

I will try to get more subjective on each of the items mentioned above in my upcoming posts.

Two Aspects of Agile Software Development Process

I have been in practice with the famous agile software development process called "Scrum" for more than a year. I have had the opportunity to see a SCRUM team developing from scratch in a completely start-up environment.

I will point to the two aspects as,
1. Management aspects.
2. Technical aspects.

1. Management aspects
I encapsulate the things like working on a story by story basis, standing up for daily status update meeting, producing deliveries in short iterations and without much of prior planning into this group. I believe this aspect heavily depends on the way the second aspect is handled.

2. Technical aspects
Technical aspects encapsulate the practice of Test Driven Development, continuous and periodic Refactoring and other hard core technical things like this. Despite the truth that, this aspect is not the much anticipated by the client, being "Agile" there is no alternative to achieve what is anticipated, "Business value", without this.

Developing Software falls into the category of craftsmanship. So, its hard to define the line and expect the players to stop on a referee's whistle. With agility, developers are free to add their creative inputs to the software design and code base. So, without attention to the technical aspects may lead to a process of "Iterative Incrementation Destruction" instead of "Iterative Incremental Develeopment".

In subsequent posts I will try to come up with actual examples in favor of first making the "techi" things right.

Visit www.scrumalliance.org for Scrum related knowledge.