Infrastructure as CODE Scrum teams
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.
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?
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.
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.
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.
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.
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 ;)
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.
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
I do fine thanks.
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.