Welcome Nimesh Soni to AgileBD

15 views
Skip to first unread message

S. M. Sohan

unread,
Jul 29, 2011, 1:26:53 PM7/29/11
to agi...@googlegroups.com
Hello Agilists:
Nimesh Soni, the author of Agile Release Planning, is now in AgileBD. Please feel free to ask a lot of questions regarding release planning and beyond :)

Thank you for your time.
--
Sohan
http://smsohan.com
skype:smsohan | gtalk:sohan39 | cell: 403-714-2673

nhm tanveer hossain khan

unread,
Jul 29, 2011, 2:59:25 PM7/29/11
to agi...@googlegroups.com
Thanks Nimesh Soni for joining us :)

Just wondering, How would you manage a product which has continuous and frequent updates ?
Let me explain my context -

We just had our first customer on one of our SaaS platforms. We have been continuously assisting our customer to make our system more consistent and stable. It looks like lotta things got into different shape than we have thought before we let our first customer taste it.
So now this product is getting more patches and fixes for core module and also for client related modules.
Just wondering how would you suggest in such case to be more responsive to client through agile way ?

Right now we are outta process. just observing a simple way around. all client or our discovered issues are kept on issue tracker and everyday our product owner used to prioritize them and tag them with today's date. ie. target-30th-july so everyday morning we conduct a meeting with our product owner to see what we have difference in thought about the tagged issues.
So we fix up as much issues as we could and deploy them on server.
At the end of the day we used to send out a daily status where we explain which tasks we have taken in charge and which we couldn't finish up.
This process is working for us quite well since we have domain expert constraint.

Now my question, What else would you suggest ? (I know many of us would say, since it has been working why would you ask for other options?, perhaps to see the difference and making it more productive)

Best wishes and thanks again for joining us :D

--
You received this message because you are subscribed to the Google Groups "Agile Bangladesh" group.
To post to this group, send email to agi...@googlegroups.com.
To unsubscribe from this group, send email to agilebd+u...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/agilebd?hl=en.



--
Best Wishes,

nhm tanveer hossain khan (hasan)
blog - hasan.we4tech.com
cell - +8801713090511
facebook - www.facebook.com/we4tech
linkedin - www.linkedin.com/in/we4tech

"work for fun"

Nimesh Soni

unread,
Jul 29, 2011, 11:57:06 PM7/29/11
to Agile Bangladesh
Thanks for the warm welcome.

I see a big problem with the approach you are using for now. It may be
working for now, but with this approach you will always be in reactive
mode. You are reacting to all the bugs that are found and fixing them
based on some priorities. However, bugs are Technical Debt, and you
are not gaining any customer confidence with fixing them either. Our
goal should be to prevent the bugs from occuring in the first place.

The other problem is that you put the system in production/into market
withouth having proper customer inputs. Along with your reactive mode,
you also need to get proactive. Continue using your current approach,
however, along with that, start thinking strategic and be proactive.
Form a panel of customers, call it your 'Product Owner'. Ask the
panel, what they would like to see in the future release and work
towards including those features in the next increment of the product.
I would say define your release to be 90-day. You can have three 3-
week sprints where you complete the development, and use the last 3-
week sprint to complete activities related to releasing the product to
market as well as planning for the next release. With this release
cycle, you could be putting product with improvements and new features
into the hands of your customers every 3 months. They would love to
see the features they sought for, and would be very willing
participant in your release planning.

Hope this helps.


Nimesh Soni
skype: nimesh0308 | twitter: @beyondCSM
Author: "Agile Release Planning" Book: http://amzn.com/B004TGTHNM


On Jul 29, 2:59 pm, nhm tanveer hossain khan <hasan8...@gmail.com>
wrote:

Nimesh Soni

unread,
Jul 30, 2011, 12:01:19 AM7/30/11
to Agile Bangladesh
Thanks Sohan for the warm welcome. I appreciate it.

Nimesh Soni
skype: nimesh0308 | twitter: @beyondCSM
Author: "Agile Release Planning" Book: http://amzn.com/B004TGTHNM


On Jul 29, 1:26 pm, "S. M. Sohan" <soha...@gmail.com> wrote:
> Hello Agilists:
> Nimesh Soni, the author of Agile Release Planning, is now in AgileBD. Please
> feel free to ask a lot of questions regarding release planning and beyond :)
>
> Thank you for your time.
> --
> Sohanhttp://smsohan.com

Tim Abbott

unread,
Jul 30, 2011, 2:49:20 AM7/30/11
to agi...@googlegroups.com
Nimesh,

In all honesty, I think where we are is in late Alpha stage with a paying customer.  What Hasan described is very correct and what we are doing is working through one scenario to properly define the proper product features.  Actually, I think what we want is 2 more clients (paying or not) in order to really properly define the real use cases for the product because we were guessing regarding the feature set.  We are building the product for the GCC market and specifically Saudi Arabia at the moment and there isn't enough data to understand all of the possible use cases so we guessed on many features and most were correct.  However, one of the most important features wasn't given the depth that this client needed and so with more clients, we can dig deeper.  This is the main reason we are going through this process because this is the state of the product and I would certainly never call this a stable final release.  While the codebase is stable, this client is helping us to understand one segment of the market and we are targeting 2-3 different types of clients to make sure we understand what is the most important and how we can finalize the product development taking the various customer needs into consideration.

The product doesn't even have a public facing website for this reason.  

I hope this is clear.  

--

Best Regards,

Tim Abbott | EVP Digital Strategy
Tasawr Interactive 

Phone: 966 1 206 6597 | xtn 219
P.O. Box 295672 - Riyadh 11351 - Kingdom of Saudi Arabia

"consistently excellent"

LEGAL CONFIDENTIAL: The information in this e-mail and in any attachment may contain information which is legally privileged. It is intended only for the attention and use of the named recipient. If you are not the intended recipient, you are not authorized to retain, disclose, copy or distribute the message and/or any of its attachments. If you received this e-mail in error, please notify me and delete this message. Thank-you.

Mithun Sarker

unread,
Jul 31, 2011, 12:15:49 AM7/31/11
to agi...@googlegroups.com
Hello!

I hope I will talk on right track as your expectation. :)

This is a very challenging topic as I see, because it happens a lot I guess specially where the product design is not yes finalized. It starts from the requirement engineering to release planning with sufficient quality for product stability.
What I can assume that the product design team needs to be more realistic first of all about the product and how, where, who , when and why a product module is  going to be used. A lot of communication is a very cruel thing when you work with such a product which is absolutely global. Some times, for localization support you can start building several different projects with some common service to keep things cleaner and avoiding localization specific failure or violation in service. But this definitely depends on the size of the project, complexity of business and usability AND requirement complexity/correctness.

On the other point of view of Mr. Nimesh, I would definitely go with him. Because that's what a QA team are suppose to do, but can't expect it from only test team. Preventing is obviously the  best option. What I am understanding, may be i could get wrong, you are building the project thru a bug/addoc requirement driven  development, which will ultimately have issues in the long run. Depending upon the scale of project you can face the problem where domain expertise becomes a liability of a single   or couple of person and therefore product changes are hard to adopt. I think a continuous update of use case and dependency matrix should help you to remain more stable on future.

For managing the frequent changes, I m not counting bug/error as change,  I think a approach of Mr. Nimish's sounds little familiar to me that you should build up a PBL list with these change request, Compile them technically   as a chunk or module wise and QA must ensure the desired impact of changes to keep the integrity of changes and make sure no change is going to break any other business made previously or recorded as a future concern in current scope of development.
Then you can estimate and run a sprint with changes fix a deadline with clients for sort UAT on the changes, and the merge with production branch.If u make a 3 weeks sprint u can let the clients know about the changes u made in 1.5 week as sneak peek. But daily communication and ad-hoc adopting may involve some over head in the process. :)

I would appreciate if Mr. Abbott  and Mr. Nimesh would also suggest or discuss for unexplored challenge on my idea. :)


--
..:.:: M Sarker
..:.:: Senior Quality Assurance Engineer.
..:.:: SoftwarePeople.

:.:.:: Phone: +8801819201288
.::.:: E-mail: bd.ms...@gmail.com
.:.:.: MSN: bd.mS...@live.com
....:: Gtalk: bd.mS...@gmail.com
:::.:: Skype: bd.mSarker

Tim Abbott

unread,
Jul 31, 2011, 1:34:00 AM7/31/11
to agi...@googlegroups.com
Mithun,

Want a job :)?  Just kidding, but you bring up some great points, however, I'm not sure this is necessarily QA's task.  I'll give you guys a little perspective about working in Saudi.  Let's just say the mindset of the decision makers here for the most part isn't very agile.  However, that being said, the largest player in the travel market in the Middle East offered to buy us because they loved our solution so much.  The country representative of Worldspan GDS offered to partner with us and they have offices throughout Africa and the Middle East.  The national commission for Tourism (yes there is tourism in Saudi some how) is interested in partnering with us and the funny part is, while the solution is travel related, we don't consider it a travel related solution.  However, I'll get back on topic now.

Mithun brings up some excellent points but I'm not sure they speak to what we are doing but some of them are challenges we are having so I'll cover those challenges:

1.  We are gathering real world requirements now.  I would say 80% of our features make sense and from a feature perspective are done fairly well, but I'm not sure how robust they are from a technical perspective.  However, there aren't many systems to compare it to.  From a functionality perspective, I would compare it to a much more robust airbnb.com (we started before them but could never pull the trigger to release) but with a nice templating engine like wordpress or similar and with support for car rentals and sales, short term accommodations (hotels, motels, hostels, etc), and real estate.  We have what I would call and inventory management system that's easy to get up and running in 10 minutes or less.  This site is built using our templating engine:

www.shary.com.sa (a large car rental company)

Right now, you can't really book any car (bingo) even though if they used that feature you could and these guys are very large.  The problem is, our features are even more advanced than we thought.  What people are extremely interested is:

a.  building a website (because even the large players like these guys don't have functional ones)
b.  showing their inventory
c.  having someone email them when they are interested in inventory

That's pretty much it.  What we built was a lot more than that which includes online reservation, slick inventory management, fleet management (for cars), deal management, employee access management, branch management, and a host of other things.  i'm not quick to dismiss those other things, but we need other people on the system to see how they will use the features.  Features look really cool on paper, and ours do but if the customer isn't using them then they have the potential to GET IN THE WAY.  

2.  Quite honestly, I'm not sure we can got with Nimesh's view even though he knows more than us.  The product isn't ready yet in my opinion.  I would say we are probably 3-6 months away from getting to that point.  To be honest I'm not as concerned with Release Management as Hasan is but that's because I am much more familiar with it, since I've been involved in so many releases in some form or other in shrink wrapped software and other environments.  What I am concerned with is testing, operations, customer support, and change management.  These I am less familiar with and because making mistakes by introducing change to people's already working systems might not be welcomed, especially in this market.  Also, I'm not sure that we have learned the right mix of customer empathy to feel their immense pain when they have problems.

3.  I am sure that we will have globalization challenges with localization as the primary initial focus, however, that is so far away, I don't even want to think about it.  It's in the back of our minds but if we can survive here, I'm almost certain, the others will be much easier (we hope).  


--

Best Regards,

Tim Abbott | EVP Digital Strategy
Tasawr Interactive 

Phone: 966 1 206 6597 | xtn 219
P.O. Box 295672 - Riyadh 11351 - Kingdom of Saudi Arabia

"consistently excellent"

LEGAL CONFIDENTIAL: The information in this e-mail and in any attachment may contain information which is legally privileged. It is intended only for the attention and use of the named recipient. If you are not the intended recipient, you are not authorized to retain, disclose, copy or distribute the message and/or any of its attachments. If you received this e-mail in error, please notify me and delete this message. Thank-you.

Nimesh Soni

unread,
Jul 31, 2011, 4:58:02 AM7/31/11
to Agile Bangladesh
Thanks Tim. That provides me a good background into the scene!

I suggest that you work towards getting more customer representation
to drive the priorities and MMFs (minimum marketable features). Though
you are in Alpha stage, your ultimate goal is to get it to production
and deliver a product that your potential customers would want to buy.
Having proper representation of your customer base is key to getting
to that ultimate stage.

And, I would say even in Alpha stage Agile Release planning can help.
You still need to define your release and work towards those features
and functionalities. You will be releasing it to a few alpha-test
customers, that's all.

Hope this helps.
Thanks.

Nimesh Soni
skype: nimesh0308 | twitter: @beyondCSM
"Agile Release Planning" Book: http://amzn.com/B004TGTHNM

Nimesh Soni

unread,
Jul 31, 2011, 5:07:43 AM7/31/11
to Agile Bangladesh
Thanks Mithun. You brin gup some very good points. I suggest 90-day
release cylce for a reason. Within this period, you can have three 3-
week sprints where you can work on the development activites (that
include Testing as well!) and one 3-week sprint would be used as
stabilization and release sprint.

Product backlog should feed MMFs (minimum marketable features) into
this release cylce. And, what are these MMFs? They are 'packages' of
functionality that we want to release, and definition of them should
come from Prodcut Design.

This (Product Design) in turn is not an IT exercise. It should be
driven by your customer base, and IT is just an enabler. IT is coming
up with the technology solution.

To summarize,
Product Design -> Release cycle -> Product Increment

As you release the product increment, you will get feedback from
customers that will feed into Product Design. You see the iterative
nature of the process!

Hope this helps.
Thanks.

Nimesh Soni
skype: nimesh0308 | twitter: @beyondCSM
"Agile Release Planning" Book: http://amzn.com/B004TGTHNM


> .::.:: E-mail: bd.msar...@gmail.com
> .:.:.: MSN: bd.mSar...@live.com
> ....:: Gtalk: bd.mSar...@gmail.com
> :::.:: Skype: bd.mSarker
Reply all
Reply to author
Forward
0 new messages