nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Agile practices in teams and companies outside IT and software industries

Dzmitry Hryb [Deviniti]

Hi everyone!

I'm doing some research for a piece of content that we're creating at Deviniti, and I have a question to the Atlassian Community

Have you ever come across adopting some kind of Agile project management practices in teams and companies outside the IT and software industry? In which cases is it a good or a bad move?

Feel free to share your opinions, personal experience, or cases that you know about - we'll feature the most interesting ones citing those who brought them as well.

A discussion on the topic is highly appreciated as well!

Comments

Damien_gvt3ng

I personally use Agile practices for everything these days, there have been many great stories about Agile being used for renovation projects, in the classroom and in many other industries. That said it isn't always the answer, waterfall done well is often better than Agile done badly so it's all down to having the right people, the right buy-in and the right mindset.

Dzmitry Hryb [Deviniti]

Hi @Damien ! If you have some links to such stories as you've mentioned, I'd love to learn them

Bryan McMillan_4pe0cs

Hello, I am with Cprime and have helped companies that do other things in addition to software development implement Agile. Specifically Scrum. I helped them to implement this for HR, Facilities, Support Teams, Hardware (yes, Agile for Hardware), Security both physical and software, and more. Most of these companies already had Jira Software so that helped as they already had a good tool. And many of these already wanted to implement Agile. Normally, I helped them choose a 2 week cadence and that seemed to work well. A few of these I can honestly say we had to tweak after they got started adapting as needed to better fit their paradigm. Agile is a good Framework to apply in many areas outside of software. However, I totally agree with Damien in that any of the lifecycle models done badly is not a good thing, not even Agile.

Regards,

Bryan

Dzmitry Hryb [Deviniti]

Hi @Bryan McMillan

Thanks for sharing! A 2-week sprint is kind of a standard, I suppose - it works pretty well for our non-technical teams, either. We only had to make one sprint double-length so far during the Jira Day Remote weeks And we found it easier to adjust the process with 1-week iterations when we were just starting with the shift.

Are there any industry/team specifics regarding certain cases that you mentioned?

Bryan McMillan_4pe0cs

Hello @Dzmitry Hryb [Deviniti] ,

Yes, indeed there is. My first and foremost suggestion is to keep-it-simple. Second, adapt a meaningful workflow for each IssueType used that not only meets the needs for the specific team(s) but also addresses reporting to each persona above the team to make sure the statuses are meaningful to consumers of reporting from Jira to make sure that all completely understand and are on the same page. Third, only collect meaningful/useful/value-add data on Jira Issues. If you don't need the data for reporting, for regulation/compliance, for searching/filtering and such then avoid collecting it in Jira. Each industry, business unit, department, and team each have a variety of needs and requirements. So, you'll need to listen to each need and do what you can to meld all if it into those needs the company needs as a whole. Chances are excellent that not every requirement will get satisfied. Lastly, even within any specific industry there exists a wide degree of variance as no two entities are identical.

I sure hope this helps,

Bryan

pargab sala

I earlier used it in 'Resource Management' of the project for EPC firm (Hydro-mechanical Dam Project).

The best way to know your supply is to develop a resource management plan within the constructs of agile project methodology. This means having a normalized and manageable set of roles, a functioning and well-maintained skills database and alignment and mapping to resource management processes.

Tips for strategic agile capacity management with focus factor:

Always keep your capacity estimate and your task list estimate on the same terms (FTE, hours etc).
Compare your priority list commitment hours with that of your capacity and make sure that they match.
Although juggling multiple projects is quite common, refraining from such a situation helps keep the schedules moving and the forecasts accurate.
While estimate task duration, try limiting to only required hours as the focus factor generally takes care of the buffering hours.

Resource capacity planning for agile teams relies on accurate demand forecasting. This process can be tied to the PMO with scientific resource management. Resource management tools let you map current as well as pipeline projects and their hourly requirements such that, much before the time you are aware of the requirements that are coming your team’s way.