New Products whit Agile and Infrastructure Request

Sometimes there are aspects of setting up servers that take a lot of time, but it should be possible to at least have something within a Sprint. This is not a criticism of the infrastructure team. There are many good reasons why they may have given that answer.

Is it not an option for the Scrum Team to have responsibility for setting up and maintaining the server? Perhaps some of the Development Team members will have infrastructure expertise.

Perhaps at the end of the first Sprint, it is not necessary that everything is very efficient and highly performant with the server (improvements can come later, when there is evidence for making them); and most likely there are some features of the server can wait until later (or will never be needed).

For example, it may not be necessary for the server to meet certain security standards until the product stores customer data.

Taking care of those particular infrastructure tasks, may only be something the team addresses when it needs to. Doing it up front could be wasteful, particularly if it gets in the way of being able to inspect a working product.

Do you create a story for that, or you don't start the sprint until you had all you need to work?

Perhaps it ought to be stipulated in the Definition of Done, given that deployment in a production environment is necessary for an increment to be released.

In Scrum, no-one can force a team to do any work for which they cannot meet the Definition of Done, and a team would take care not to do so.

My advice is to clearly articulate the deficit for release (i.e. everything needed for “Done” which cannot yet be satisfied) and communicate this to stakeholders.

If the team do decide to start work without being able to achieve the “Done” standard, then full transparency must be provided over undone work, and also the fact that Scrum is not yet being implemented due to organizational dependencies and impediments.

a potentially releasable Increment of "Done" (...)  the new Increment must be "Done," which means it must be in useable condition and meet the Scrum Team’s definition of "Done". (...) regardless of whether the Product Owner decides to release it.

Software sitting on a temporary server made from an old PC (or current developer's PC) still could do the needed work. If you installed the Increment on it, it would be inspectable, usable, and it was released. Just because this server is only accessible from LAN (for the stakeholders to be able to try it out) does not really mean that it was not released. This is the PO who decides who to release to, and if release at all.

Hello,

Thanks for all the feedbacks :)

Answering some of the questions that you guys mentioned:

@Simon Mayer:Is it not an option for the Scrum Team to have responsibility for setting up and maintaining the server? Perhaps some of the Development Team members will have infrastructure expertise.

In that case I work in a big tradicional company and we have two big IT segments, that is Software projects and Infrastructure. In that case the Scrum Team is from the Project segment, and the company "says" that this segment does not need the infrastructure skills because we already got the infrastructure segment, so we need to make a request to then.

@Simon Mayer: For example, it may not be necessary for the server to meet certain security standards until the product stores customer data.

In that case, the company "Force" usto get all the best infrastructure requirements as we start the project,so we need to the server to  to meet certain security and performance standards even if the product is not in use for the customer yet. 

@Ian Mitchell: Perhaps it ought to be stipulated in the Definition of Done, given that deployment in a production environment is necessary for an increment to be released.

@Ian Mitchell: If the team do decide to start work without being able to achieve the “Done” standard, then full transparency must be provided over undone work, and also the fact that Scrum is not yet being implemented due to organizational dependencies and impediments.

I agree with you, and we tried this to put that in the DoD, but the team have a 3 weeks sprint, and the infraestructure request take 3 months to be Done, so we won't be able to deliver the feature in production at the end of the sprint.

I think the case here is just be transparent and say that the team can't deliver any feature for the Client in production before the infrastructure is ready, and manage the Client expectations about de R.O.I. $$.

@Filip Lukaszewski: Software sitting on a temporary server made from an old PC (or current developer's PC) still could do the needed work. If you installed the Increment on it, it would be inspectable, usable, and it was released. Just because this server is only accessible from LAN (for the stakeholders to be able to try it out) does not really mean that it was not released. This is the PO who decides who to release to, and if release at all.

In that case even a old PC(that here is a free space from our virtualized infrastructure) nedd to be requested and is have again de 3 months SLA. The other think here is that the PO(and the team) knows that the team can finish the development of the feature and the PO is "pushed" by the Client to release something that's brings $$$ value(for the Client $$$ value is the feature runing in production) for the release.

Thanks for all the contribution :)

The Scrum Guide stipulates several times that the team should deliver a "potentially releasable Increment of "Done" product at the end of each Sprint."

In my opinion, the organizational constraint around environment preparation may preclude the actual deployment of said product, but it may still be an option to have the team create the deliverables that will wait until the infrastructure to actually deploy exists.   This of course invites a ton of other issues, such as Lean waste around creating excess inventory and waiting, and whether the team is adhering to a proper DoD.

Bottom line, does it make sense to have the team create work product that needs to wait before delivering to the customer?

Helloy Timothy,

Thanks for the comments. Here are my Answers.

In my opinion, the organizational constraint around environment preparation may preclude the actual deployment of said product, but it may still be an option to have the team create the deliverables that will wait until the infrastructure to actually deploy exists.   This of course invites a ton of other issues, such as Lean waste around creating excess inventory and waiting, and whether the team is adhering to a proper DoD.

I Agree, one of the things that I'm trying in the company is change their mind about this kind of situation. Because I think is a waste of time start a project that we don't have the "ways" or resources to start the development.

Bottom line, does it make sense to have the team create work product that needs to wait before delivering to the customer?

When we have a team with more than one project(that is a lot of teams here here) we can work in another product while we "wait" the resources for the new one, but i was in a different team these days that was assemble just for to this new product, and the team is in "idle".

And it's worth pointing out that I work in a big company and the still are doing the Waterfall Agile, that we only deliver some value at the end of a project (1 or 2 years later), so for the company is "OK" to start development and not deliver in anything of value.So my real challenge here is showing to the "board" and the business area that this is not agile.

In that case even a old PC(that here is a free space from our virtualized infrastructure) nedd to be requested and is have again de 3 months SLA.

Well, if you are going to have interesting conversation with the "board" you might as well want to tell them that the setup you described is... risky. A startup would have a prototype done in 2 weeks, and you wait 3 months for a very basic test environment...

As a SM, I would investigate other options, like speaking with the infrastructure team if they could create a fast-track path for NON-PROD testing environments, or maybe find a discovery / technology incubator team inside your organisation so they could help in a less official way...

Hello @Filip.

As a SM, I would investigate other options, like speaking with the infrastructure team if they could create a fast-track path for NON-PROD testing environments, or maybe find a discovery / technology incubator team inside your organisation so they could help in a less official way...

As is said before, for the business area they see $value only when the features is in production, so even the team deploy the feature in a testing environment for example, the business don't se value because they can't release this feature to the final Client/User from a server that is not NOM-PROD.

I think today the problem here is more political than technical. And i will just figure out how to solve this If I start to change they mindset for a "Agile" approach.

Thanks for the Help :)