Skip to main content

Due to the Russian invasion of Ukraine, we have paused all purchases and training in and from Russia.

Infrastructure as CODE Scrum teams

Last post 08:33 pm August 17, 2018 by Timothy Baffa
10 replies
12:42 pm August 15, 2018

SO, I started a new contract and in 3 days I see opportunities to fix the orgs Agile framework. 

I was under the impression the teams were norming phase agile application teams. They said they have been doing Agile 4 years. Come to find out they are really engineering teams who scrum but don’t really know why other than the CTO said to do it.

There is no real dev code just task level infrastructure PBI’s which I find seem to work better in a Kanban method. They do everything an application team would do sprints, points, all the ceremonies etc. but struggle with it.  They have PO’s but they don’t really write the stories the engineering teams do.

They have output but it’s not seen by the consumers or user audience.

What I already see are huge gaps in understanding Agile fundamentals.

Just curious if any members work with infrastructure as code teams and how you feel about them. Harder, easier, same? I find them to be my most challenging teams to work with. I have had success but not without it being painful at times.


07:17 am August 16, 2018

They have output but it’s not seen by the consumers or user audience.

Who benefits from their work? Maybe they've been looking at the wrong audience? Hopefully, there is a reason for the work their doing, somebody must benefit from it. Those are the audience you should be looking at.

They have PO’s but they don’t really write the stories the engineering teams do.

Bear in mind that User Stories are not a required part of Scrum. Are they not writing Stories or are they not writing PBIs at all. If it's the latter, what do the POs do and who is writing those PBIs?

Come to find out they are really engineering teams who scrum but don’t really know why other than the CTO said to do it.

Maybe you could come together and compare their current way of working with their old way of working? It's possible there have already been some improvements the team is unaware of because they didn't pay attention to them. If not, this might be an opportunity to introduce them anew to Scrum - with everything, including the values and try a reboot?


08:11 am August 16, 2018

There is no real dev code just task level infrastructure PBI’s which I find seem to work better in a Kanban method

Scrum is based on sprints and therefore the ability to frame meaningful Sprint Goals. The sweet-spot for doing so is the complex product space where these goals allow significant unknowns to be challenged and addressed.

In my experience, infrastructure teams generally tend to work in a “merely” complicated space rather than a truly complex one. There is usually value in optimizing their flow of work and hence transparency via a Kanban may prove useful. Meaningful Sprint Goals, however, typically end up being more the exception than the rule.

My recommendation would be to view an infrastructure problem through that lens, i.e. is the domain a truly complex one with significant unknowns, and for which Scrum may be usefully leveraged.


09:04 am August 16, 2018

Although for the infrastructure team, Kanban is usually chosen.

But from another point of view, Scrum has a better rhythm than Kanban.

Scrum can also be a good option if the team is more concerned with working cadence, even if it is for infrastructure tasks.

Put all the work to be done into the Product Backlog. The Product Owner then arranges the priorities of Items.

In the sprint planning, the team estimates the work can accomplish in the Sprint.

In the Sprint Review, the Development Team does not necessarily need to have actual outputs of the software to demo.

Even without the actual outputs of the software, there may be stakeholders.

At least the Product Owner can review the outcome of the Sprint's work.

 


09:43 am August 16, 2018

Yes Kanban would be the best method. As, there is not standard defined timebox. The work Item will tracked against it status completion.
It will be the status of those work items which are tracked and monitored etc.

Best is you look at how they work currently and look at what could be done better.


12:51 am August 17, 2018

I appreciate every ones response I was not really asking a question. 

 

IAN you literally never make any sense I don't think you have ran a Agile team in your life. Go read another book.


01:42 am August 17, 2018

Hi Mad,

Reading your post I think I recognize a question, but I am very carefull now :). Past two years I have been PO of an infrastructure team (providing secure and compliant cloud services to devops teams in our organisation). 

Key concept for infrastructure products (cloud or not) is self-service. To get infrastructure out of manual provisioning processes for application teams and enable these teams to focus on app development. Infra as a code comes hand in hand with cloud in my opinion. Now there is much to say about how to organize this in more complex organisations and how u want this ideally.

But main difference is; skills. Infrastructure gurus are no developer gurus usually. And in devops wow, automation ci/cd and cloud, ideal infra and dev skills are growing towards each other. 

If an infra team.works demand ticket based and has no opportunity or support to change its WoW. Well I guess you have your answer about whether scrum is the best solution for wow.

If you want the full story, contact me on LinkedIn for example ;)

Regards,

Marco

 

 


03:11 am August 17, 2018

I worked as an agile consultant in some high-tech or financial companies. 

The MIS department includes the development teams and the infrastructure teams.

Most companies are less willing to use two different Agile Framework.

However, while all are Scrum teams, the practices used by the development teams and the infrastructure teams are different. This will not violate the Scrum Guide theory. User story, story point, are not required by Scrum.

For example, each product backlog for a development team is a user story, but each product backlog in the infrastructure team is a single work item.

What about the Refinement meeting? The refinement meeting is not a must as long as the team members can clearly know what to do is enough.

For the adjustment of the agile framework, we must decide whether to adopt a revolution or a way of evolution.

If the team has been agile for four years, it is not necessary to make drastic changes immediately. Perhaps a different way, by their flow and practice to start. Adjust some inappropriate practices first.

For example, many teams think Scrum must be able to display output at Sprint Review meetings before it can be released. Any time as long as the work is completed can please the product owner to see, as long as the product owner feel appropriate, the product can be released. This concept is important for the infrastructure teams. 

Sprint Review is one of the events set by Scrum.
The infrastructure teams can discuss at this meeting to see how much has been done during this period, or let the Product Owner know what the next Sprint should be able to accomplish.

 


03:31 am August 17, 2018

Dear Mad,

Ian is a respected expert on Scrum. Whoever has been in this forum for long knows his ability to cut through ambiguous questions and ask the right questions. While others typically confuse between theory and practice, he approaches practical issues with solid principles rooted in theory.

Your comment is in bad taste. Sorry to say this - You seem to be one of those 'practically speaking' personas who do not internalize agile / scrum beyond the terminology lipstick. Moreover, your open comment without any respect tells a lot about how you would handle your teams. Good luck for MAD teams


11:04 am August 17, 2018

I do fine thanks.


08:33 pm August 17, 2018

Perhaps Dan (Mewesy?), you would do better elsewhere?   Just a thought.

And please don't bring up how mean everyone is to you on this forum, or how forum admins begged you to stay.   Don't believe it, and don't care.   Half the time, your comments and observations are relative and/or interesting.   The rest of your comments are acerbic. non-relevant, self-boastful, and insulting.


By posting on our forums you are agreeing to our Terms of Use.

Please note that the first and last name from your Scrum.org member profile will be displayed next to any topic or comment you post on the forums. For privacy concerns, we cannot allow you to post email addresses. All user-submitted content on our Forums may be subject to deletion if it is found to be in violation of our Terms of Use. Scrum.org does not endorse user-submitted content or the content of links to any third-party websites.

Terms of Use

Scrum.org may, at its discretion, remove any post that it deems unsuitable for these forums. Unsuitable post content includes, but is not limited to, Scrum.org Professional-level assessment questions and answers, profanity, insults, racism or sexually explicit content. Using our forum as a platform for the marketing and solicitation of products or services is also prohibited. Forum members who post content deemed unsuitable by Scrum.org may have their access revoked at any time, without warning. Scrum.org may, but is not obliged to, monitor submissions.