Podcast #128: We chat with Kent C Dodds about why he loves React and discuss what life was like in the dark days before Git. Listen now.
2 Copy edited.
source | link

You are using a methodology on a product that is not compatible IMHO.

In the way most people define agile, all of the work is negotiable based on changing priorities, re-order-able, or replaceable.

In the way most people define waterfall is that the work is laid out in sequence ahead of time from a significant architecture effort at the beginning.

The tasktasks you list above seem very waterfall to me, they. They have to be in a certain order, and they are not negotiable.

I am not saying that you have to abide by anyone's view of any process, but at least for these tasks you seem to be in a non-agile project to me. Trying to bash that into an agile process is going to be a sloppy fit at best.  

If the rest of the project is well suited to agile I wouldn't worry too much about the initial setup being a bad fit, but the fact that you mention RTOS and devdevelopment boards make me suspect the whole thing would be better off in something more like waterfall (a long sequence of immovable dependencies).

You are using a methodology on a product that is not compatible IMHO.

In the way most people define agile, all of the work is negotiable based on changing priorities, re-order-able or replaceable.

In the way most people define waterfall is that the work is laid out in sequence ahead of time from a significant architecture effort at the beginning.

The task you list above seem very waterfall to me, they have to be in a certain order, and they are not negotiable.

I am not saying that you have to abide by anyone's view of any process, but at least for these tasks you seem to be in a non-agile project to me. Trying to bash that into an agile process is going to be a sloppy fit at best.  

If the rest of the project is well suited to agile I wouldn't worry too much about the initial setup being a bad fit, but the fact that you mention RTOS and dev boards make me suspect the whole thing would be better off in something more like waterfall (a long sequence of immovable dependencies).

You are using a methodology on a product that is not compatible IMHO.

In the way most people define agile, all of the work is negotiable based on changing priorities, re-order-able, or replaceable.

In the way most people define waterfall is that the work is laid out in sequence ahead of time from a significant architecture effort at the beginning.

The tasks you list above seem very waterfall to me. They have to be in a certain order, and they are not negotiable.

I am not saying that you have to abide by anyone's view of any process, but at least for these tasks you seem to be in a non-agile project to me. Trying to bash that into an agile process is going to be a sloppy fit at best.

If the rest of the project is well suited to agile I wouldn't worry too much about the initial setup being a bad fit, but the fact that you mention RTOS and development boards make me suspect the whole thing would be better off in something more like waterfall (a long sequence of immovable dependencies).

1
source | link

You are using a methodology on a product that is not compatible IMHO.

In the way most people define agile, all of the work is negotiable based on changing priorities, re-order-able or replaceable.

In the way most people define waterfall is that the work is laid out in sequence ahead of time from a significant architecture effort at the beginning.

The task you list above seem very waterfall to me, they have to be in a certain order, and they are not negotiable.

I am not saying that you have to abide by anyone's view of any process, but at least for these tasks you seem to be in a non-agile project to me. Trying to bash that into an agile process is going to be a sloppy fit at best.

If the rest of the project is well suited to agile I wouldn't worry too much about the initial setup being a bad fit, but the fact that you mention RTOS and dev boards make me suspect the whole thing would be better off in something more like waterfall (a long sequence of immovable dependencies).