Scrum, KANBAN, XP, Lean, Agile -how to drive the development

kine

Just want to open discussion about possible methodologies to drive the development in context of Microsoft Dynamics NAV VAR partners.

When I went through these different names, in most cases they were described or implemented on small teams, without specialists, focused on one project. As a employee of VAR partner, I am working each time on multiple projects (3-8), doing support between (which is hard to plan). The overhead of this is big.

How you are solving this problem? Do you use some Agile Methodology, or you have your own? Is it mix of these, or something totally different?

I am thinking about KANBAN system, which could help to lower the WIP, stream the task flow (is easy to implement, you do not need some specific software etc.), mixed with something from Scrum.

Some references for quick start:
http://en.wikipedia.org/wiki/Software_d ... ethodology
http://en.wikipedia.org/wiki/Agile_software_development
http://en.wikipedia.org/wiki/Kanban
http://en.wikipedia.org/wiki/Scrum_%28development%29
http://en.wikipedia.org/wiki/Lean_software_development

Any discussion about problems and possible solutions is welcome.

Main problems I see today:
1) Too big WIP
2) Too much switches between different tasks
3) Not clear priorities of tasks (everything is HOT)
4) Mixing implementations with support (same people are implementing and doing support)

David_Singleton

Development in a Navision implementation is like Sex in a marriage.

Its 10% of a good one and 90% of a bad one.

There are so many more things that are far more important, yet over and over companies seem too focused on making development more efficient. The issue isn't how to make development more efficient, the issue is how to build successful Navision implementations with less development.

People with your level of expertise should not be allowed anywhere near development tools, you are too valuable for that. You should be at the customer site with the consultant designing specs and telling the consultant "No they don't need that code, instead train the users how to do XYZ" if you did that, then you would have far less programming needed, and thus the projects would be easier.

kine

Yes, David, but still we are developing our addons, supporting customers etc. and our people must do that somehow. "Organized chaos" is not good... :-) We are not big company, but we have enough work to be over-helmed by it, and to keep implementations good you need time and "quiet" for work. It is hard to work when each 15 minutes someone interrupts you with some request, when the priorities are changing during a day, if you work on something and than you are "moved" to something other, because somebody just remember, that they need this and this today etc.

I want to discuss the technics others are using to organize their day. It is not just about development, it is about communication, time planning, rules etc. And all this is creating the environment for making the implementation and support good.

David_Singleton

kine wrote:

Yes, David, but still we are developing our addons, supporting customers etc. and our people must do that somehow. "Organized chaos" is not good... :-) We are not big company, but we have enough work to be over-helmed by it, and to keep implementations good you need time and "quiet" for work. It is hard to work when each 15 minutes someone interrupts you with some request, when the priorities are changing during a day, if you work on something and than you are "moved" to something other, because somebody just remember, that they need this and this today etc.

I want to discuss the technics others are using to organize their day. It is not just about development, it is about communication, time planning, rules etc. And all this is creating the environment for making the implementation and support good.

OK, I maybe misunderstood then.


I think the issue is one of scalability. Once you are large enough, the best is to have dedicated support group for all urgent requests. This can start with one person that just takes priority tasks. Leaving the rest of the team to work on managed tasks. I generally find that a person can prioritize a bunch of burning issues, or they can manage normal development tasks. The difficulty comes when managing fires and normal work together. If possible then putting a junior in with the fire fighter is a great way to train them, provided management realize that the junior is there to learn, not to help put out the fires.

In terms of technology, I really don't think it matters. I myself use Excel, I have tried all sorts of project management tools, online and off line etc, but in the end Excel works.

David_Singleton

Oh and also Verticals, Add-Ons, Customizations and Fire Fighting should all be separated. If your company is not big enough then you don;t want to be developing add-ons or Verticals till you can dedicate people to these. In the end each group should support the one above them.

kine

If there is separated support and implementation, how to manage the communication between them - I mean how to transfer the know-how from the implementation to the support team and back. If they will not communicate, the support will not know about the new functionality and the implementation will not have the valuable feedback from customers using the product for longer time.

And yes, I am talking about VAR with 10-20 people in implementation+support (developers + consultants + [analysts]) - excluding sales, backoffice and other areas of company. Smaller team will manage itself easily, bigger team could be splitted into smaller without problems.

For me splitting the support and implementation could be possible, only if you have enough consultants for each area, to be able to separate them.

If you have 1-2 consultant for some area, you cannot dedicate them only for support and this is beginning of the pain...

David_Singleton

I don't see why a team developing and Add-On need to communicate with the people putting out fires. Of course there will be specific cases where an issue with an add-on needs to be resolved, but why does a developer developing custom code for an implementation need to be communicating with the team developing a new add-on?

As I said, I don;t think any company should develop any add-ons till they have sufficient business that they can have a dedicated development and analysis team dedicated to the add-ons.

In terms of Verticals, this needs to be completely detached from normal business. If you have a true vertical solution, then you should have a dedicated team doing these implementations, and/or training and supporting other Navision Partners that implement the vertical.

David_Singleton

kine wrote:

If there is separated support and implementation, how to manage the communication between them - I mean how to transfer the know-how from the implementation to the support team and back

During the Post Implementation review, a customer moves from Implementation phase to support phase, at this time the knowledge transfer happens.

kine

David Singleton wrote:

As I said, I don;t think any company should develop any add-ons till they have sufficient business that they can have a dedicated development and analysis team dedicated to the add-ons.

In terms of Verticals, this needs to be completely detached from normal business. If you have a true vertical solution, then you should have a dedicated team doing these implementations, and/or training and supporting other Navision Partners that implement the vertical.

Developing addons is the way how to minimize the customizations for each customer. This is how to do good implementation with low amount of added code, even when you are small company. In this case you really customize only the specific requests of the customer. If you are solving something 3rd time for different customer, it is feature which could be added into addon, and the implementation for each customer is than cheaper, because they could get what they need right in the box, for lower price. It is why the addons are interesting even for small companies. And do not forget, that when you create addon, you do not need to buy objects into license for the customer, from which the customer pay maintenance fee - in some object-complex solutions, where the logic is not complex, but data structures, forms and reports are heavily used, the cost of objects could be bigger, than when you develop it as addon and register it in Microsoft. I am not talking about addons in form as ISV is developing them - which are resold by ISVs. I am talking about creating the company portfolio of addons (vertical and horizontal packages) from which you can create the target system as from building blocks. This is the way how to save cost and make customer happier.

kine

I just want to stress that this topic is not just about development, but about the whole implementation part (implementation and support team).

David_Singleton

kine wrote:

I just want to stress that this topic is not just about development, but about the whole implementation part (implementation and support team).

OK, that's quite different then. I was referring to your opening comment:

kine wrote:

Just want to open discussion about possible methodologies to drive the development in context of Microsoft Dynamics NAV VAR partners.

kine

Yes, development, from consultant to developer and back... whole chain, may be wrong word, but I do not know better to describe it in one...

David_Singleton

kine wrote:

Yes, development, from consultant to developer and back... whole chain, may be wrong word, but I do not know better to describe it in one...

Personally I still like the original one developed for Navision, by Sales Works (well they were not called Sales Works then but...)

anyway that process was pretty good for medium to large Navision implementations, but there was a break even point. My experience was that it added about $60,000 to the project before you started, so you have to see room to save that $60k before it made sense use it.

Take a read of this book:

The Mythical Man Month

http://www.amazon.co.uk/Mythical-Month-Essays-Software-Engineering/dp/0201835959/ref=sr_1_1?ie=UTF8&s=books&qid=1267034158&sr=8-1 (PS they deliver to Czech that's how I go my copy)

Its the best book I ever read on the topic.

matttrax

David Singleton wrote:

Take a read of this book:

The Mythical Man Month

Great book. A little dated, but all of the concepts still apply.

David_Singleton

matttrax wrote:

David Singleton wrote:

Take a read of this book:

The Mythical Man Month

Great book. A little dated, but all of the concepts still apply.

Yeah, imagine how peeved I was when I realized it was written before I ever started in Navision. I wish I had read it back then.

kine

After reading the wiki article about the book, yes, it is true. And the different methodologies are about these things from different angles. They are solving the communications, planning, estimations, team organisation etc.

And this is what I want to discuss, how it works in your companies, which problems you have etc.

I know that this could be somehow problematic to talk about, because not everytime it is possible to talk about the internal things, methodologies, problems etc. on this forum.