Project Management Central

Please login or join to subscribe to this thread

Topics: Agile
Agile outside of technology projects: Your Experiences
Network:91



I am wondering if the group has encountered Agile projects not related to software or IT. What area were they in and how did they work out? I have seen a few myself, usually related to new product launches.

Additionally, I am wondering if the group has encountered Agile being used in non-project work. Kanban seems well suited for this and I have seen it used for those purposes, I am wondering if others have seen it or other variations of Agile used in non-project work. (This part may be off topic for this forum)
It seems more companies are trying to adopt Agile. Are they doing it - Just for projects? Just for software projects? More general and day to day use outside of projects?

I should really create a poll question for this too...
Sort By:
Page: 1 2 next>
Network:89485



Joshua,

This subject was raised a lot and we are very interested in the feedback just ike you are but unfortnately, there wasn't much feedback probabably because Agile is still new to industries other than software.

Check this link:

https://www.projectmanagement.com/discussi...ology-projects-
...
1 reply by Joshua Render
Jun 11, 2018 10:56 AM
Joshua Render
...
Very good. I hope in the future to see more information on this and more companies try it.
Network:11441



Actually Joshua we have raised this topic a few times, and to be honest, there isn't much feedback. When you visit the various Agile websites, they always talk about how Agile, Scrum etc. can be used outside technology/software, and yet show very little and sometimes nothing in the way of examples or case studies.
...
1 reply by Joshua Render
Jun 09, 2018 11:18 PM
Joshua Render
...
Yeah it does seem when it is talked about it is talked about more in a hypothetical sense rather than "this is actually what happened"
Network:5417



I second Sante with that, but one of the very good uses of Agile could be in Management Process Projects
...
1 reply by Joshua Render
Jun 09, 2018 11:21 PM
Joshua Render
...
I could see some of the more general aspects of Agile being used in a lot of areas. Incremental releases may not always work, but a continuous flow. This would make me think of Kanban.
Network:816



Joshua -

Kanban originated in manufacturing contexts hence its broad applicability across industries. Agile as a set of principles, and some of the ceremonies which are commonly associated with it can certainly be applied, but specific practices might not fit a given non-technology context

Kiron
...
1 reply by Joshua Render
Jun 09, 2018 11:26 PM
Joshua Render
...
My first experience with kanban was in manufacturing. The Agile process has evolved a little to become something more separate and distinct, leading to it becoming a framework in its own right rather than a process of lean. Agile itself takes within it the lean mindset of working to continuously improve and try to eliminate waste - and that is probably I think its biggest value to non-project work.

So I guess maybe the question isn't can or where should Agile be used, but how do you think one could further develop Lean to be more useful outside of manufacturing?
Network:611



More and more literature is being developed and enhanced on this topic What I have seen in most applications is that Scrum is used with four significant adaptations.

First is primarily about mindset. For IT projects, the last responsible moment to make decisions of often quite late in the project. In product development, we must make more of our decisions earlier because the cost of change gets higher quickly.

Second, we need a different model for creating the product backlog. The work we do is not as closely connected to the features as it is in IT software development. Early in projects where we are in discovery mode, it often makes sense to create the backlog (primarily) based on important decisions to be made the the work to learn what is necessary to make the decisions. Later in the project, the epics may come from the traditional maturity steps in a product such as alpha, beta, and gamma prototypes. At this point the planning may resemble waterfall planning because there is a highly preferred sequence of events to follow. Here the scrum engine helps us more for its role in facilitating a high performing team a bit more than in its role in facilitating our ability to adapt.

Third, because there are so many more disciplines involved in creating a product, the development teams are usually too large for a single scrum team. To deal with this, the ideas from LeSS or Scrum at Scale are often needed.

Fourth, as the project progresses, the priorities for the work tend to come from internal process needs and dependencies more than from the customer/market. Hence, we need a more robust view of the Product Owner role to include system architecture, system engineering, and traditional Project Management mindsets in addition to feedback on the features that the customer most values.

Finally, the importance of minimum viable/valuable product takes on a different meaning in tangible product development. In IT projects it is possible to continuously improve the experience for the person who bought early and bought that minimum viable product. For tangible products, we don't have an upgrade path. I can't buy a bicycle that has the minimum requirements of two wheels and no gears and (easily or inexpensively) upgrade it to one with multiple gears in a couple months.

There are other societies more dedicated to product development that are creating robust practitioner communities for Agile practices.
...
1 reply by Joshua Render
Jun 09, 2018 11:36 PM
Joshua Render
...
I have become fascinated with the idea of using Agile in some form for more than software development. I think there are several possible benefits and the close integration with Lean is probably number 1 on the list.

So you have:
1. The integration of Lean and continuously looking to improve the process
2. The strong focus on the product/output of work being the core measure of success
3. The iterative component, working to get it right based on customer need
4. Embrace changes. Start from the beginning encouraging people to look for ways to change and work to adapt and be flexible
5. The servant-leadership philosophy
6. Allowing teams to have more control over how they do they work
7. As you mentioned the idea of the backlog

Of course, this list is from a more general perspective and how you would (if you even could) implement those in a given scenario would require more specifics on the scenario, and I think you provide a good view of some of the challenges one might face there.
Network:91



Jun 08, 2018 10:37 PM
Replying to Sante Vergini
...
Actually Joshua we have raised this topic a few times, and to be honest, there isn't much feedback. When you visit the various Agile websites, they always talk about how Agile, Scrum etc. can be used outside technology/software, and yet show very little and sometimes nothing in the way of examples or case studies.
Yeah it does seem when it is talked about it is talked about more in a hypothetical sense rather than "this is actually what happened"
Network:91



Jun 09, 2018 1:23 AM
Replying to Kevin Drake
...
I second Sante with that, but one of the very good uses of Agile could be in Management Process Projects
I could see some of the more general aspects of Agile being used in a lot of areas. Incremental releases may not always work, but a continuous flow. This would make me think of Kanban.
Network:91



Jun 09, 2018 9:02 AM
Replying to Kiron Bondale
...
Joshua -

Kanban originated in manufacturing contexts hence its broad applicability across industries. Agile as a set of principles, and some of the ceremonies which are commonly associated with it can certainly be applied, but specific practices might not fit a given non-technology context

Kiron
My first experience with kanban was in manufacturing. The Agile process has evolved a little to become something more separate and distinct, leading to it becoming a framework in its own right rather than a process of lean. Agile itself takes within it the lean mindset of working to continuously improve and try to eliminate waste - and that is probably I think its biggest value to non-project work.

So I guess maybe the question isn't can or where should Agile be used, but how do you think one could further develop Lean to be more useful outside of manufacturing?
...
1 reply by Kiron Bondale
Jun 11, 2018 5:20 PM
Kiron Bondale
...
Joshua -

Lean is evolving beyond manufacturing - if you think of the old 6 M's model which evolved into the 6 P's model to address services, or the heavy use of lean in healthcare, telcos and other human oriented services work there is definite growth.

However, just as with agile, adaptation is needed.

For example, when looking at a manufacturing process which is predominantly driven by machines, you can strive for a very high (80+%) process efficiency level. When we deal with a predominantly human driven process, it's almost impossible to get over 50% process efficiency just based on the unpredictability and variation of human beings.

Kiron
Network:91



Jun 09, 2018 11:05 AM
Replying to Brian Cohn
...
More and more literature is being developed and enhanced on this topic What I have seen in most applications is that Scrum is used with four significant adaptations.

First is primarily about mindset. For IT projects, the last responsible moment to make decisions of often quite late in the project. In product development, we must make more of our decisions earlier because the cost of change gets higher quickly.

Second, we need a different model for creating the product backlog. The work we do is not as closely connected to the features as it is in IT software development. Early in projects where we are in discovery mode, it often makes sense to create the backlog (primarily) based on important decisions to be made the the work to learn what is necessary to make the decisions. Later in the project, the epics may come from the traditional maturity steps in a product such as alpha, beta, and gamma prototypes. At this point the planning may resemble waterfall planning because there is a highly preferred sequence of events to follow. Here the scrum engine helps us more for its role in facilitating a high performing team a bit more than in its role in facilitating our ability to adapt.

Third, because there are so many more disciplines involved in creating a product, the development teams are usually too large for a single scrum team. To deal with this, the ideas from LeSS or Scrum at Scale are often needed.

Fourth, as the project progresses, the priorities for the work tend to come from internal process needs and dependencies more than from the customer/market. Hence, we need a more robust view of the Product Owner role to include system architecture, system engineering, and traditional Project Management mindsets in addition to feedback on the features that the customer most values.

Finally, the importance of minimum viable/valuable product takes on a different meaning in tangible product development. In IT projects it is possible to continuously improve the experience for the person who bought early and bought that minimum viable product. For tangible products, we don't have an upgrade path. I can't buy a bicycle that has the minimum requirements of two wheels and no gears and (easily or inexpensively) upgrade it to one with multiple gears in a couple months.

There are other societies more dedicated to product development that are creating robust practitioner communities for Agile practices.
I have become fascinated with the idea of using Agile in some form for more than software development. I think there are several possible benefits and the close integration with Lean is probably number 1 on the list.

So you have:
1. The integration of Lean and continuously looking to improve the process
2. The strong focus on the product/output of work being the core measure of success
3. The iterative component, working to get it right based on customer need
4. Embrace changes. Start from the beginning encouraging people to look for ways to change and work to adapt and be flexible
5. The servant-leadership philosophy
6. Allowing teams to have more control over how they do they work
7. As you mentioned the idea of the backlog

Of course, this list is from a more general perspective and how you would (if you even could) implement those in a given scenario would require more specifics on the scenario, and I think you provide a good view of some of the challenges one might face there.
Network:1576



Agile is not a method or process, Agile is not related to software or IT, Agile did not start with the Manifesto. Agile is a practice that was formally born in 1990 as an alternative to Lean. So, you can apply Agile in everything if and only if you make an impact analysis first and you understand your whole enteprise architecture. This activity is not new. Belongs to business analysis field from the very begining. Unfortunatelly because Agile becomes a buzzword then most of the people do not understand what Agile is. For example, your list in the answer to Brian Cohn has not sense (generally speaking) about Agile. Things like "embrace changes" are not understanding at all. But, go to the basement. Relating to original post perhaps this will help:
https://hbr.org/1986/01/the-new-new-product-development-game
https://hbr.org/2016/04/the-secret-history-of-agile-innovation
https://www.scruminc.com/wp-content/upload...-with-Agile.pdf
https://steveblank.com/2016/11/10/how-the-...vation-culture/
https://www.linkedin.com/pulse/when-agile-...e-title-publish
"Perfectly Positioned", http://www.pmnetwork-digital.com/pmnetwork/april_2016?pg=73#pg73
...
1 reply by Joshua Render
Jun 11, 2018 10:44 AM
Joshua Render
...
I realize Agile itself is not a method or a process and that it originated well before the manifesto. I don't generally regard the manifesto as important from an Agile creation perspective - but I like much of the definitions about what Agile (general usage) should be, so I stand by my list but recognize that it is not all-inclusive. The Agile manifesto also focused on software development and my question was focused on quite the opposite.

Agile was born precisely because complex waterfall projects spanned years and had to adhere to decisions made years before with no allowable room for change. Embrace change belongs in that list.
Page: 1 2 next>  

Please login or join to reply

Content ID:
ADVERTISEMENTS

"Technology is a gift of God. After the gift of life it is perhaps the greatest of God's gifts. It is the mother of civilizations, of arts and of sciences."

- Freeman Dyson

ADVERTISEMENT

Sponsors