Agile PLM Implementations - is there another way?

 

The businesses of the future are ready to change, to compete with the new and disruptive companies that are coming after their market share. 
There’s a consistent piece of feedback received over my blogging "career”, surrounding an organization’s failure to change culture - to empower people to change how they think and do.
The 4th Industrial Revolution (4IR) business has changed its culture 1st:
it's changed the way it's people think, through the blending of cross-functional teams, toward productivity and innovation (Offense thinking).
When it innovates and operates it's Customer-Centric. It captures data, analyses, learns and deploys this new intelligence to the benefit of the customer, supplier and operator experience. It moves fast, tries new ways, fails and learns quicker. 
In the 4IR, how can we possibly think about implementing arguably the most important enterprise applications (that directly affects product innovation): innovation platforms, Product Lifecycle Management and Smart Manufacturing Operations/Execution that contradicts the above?
How can we think about eating the elephant whole, rather than in fast, bite-size chunks? 
These applications are targeted at the heart of the 4IR business drivers: new and innovative products and services in order to deliver smarter, more personalized and better experiences. It drives focus, cost reductions and productivity through improved product development practices and operations. The enterprise looks to the product lifecycle and its Innovation Platform to promote and harness ecosystem wide collaboration, manage product data and multiple product design, manufacturing, maintenance and disposal functions.

Agility

PLM has to bring stability, speed, flexibility and faster reaction to the demands of the customer and marketplace! 

But delivering the PLM & Product Innovation Platform is a complex process that when extended across the enterprise can take considerable time, but remains fundamental to the 4IR culture in terms of its approach to installation along with design and build. 

The 6 Benefits Of An Agile Approach To PLM

Using Agile and the associated SCRUM and DevOps methodologies to implement PLM enables continuous improvement, care of the principle of Fail-Fast, Learn-Quicker. 

The benefits of agile PLM implementations include: 

1. Goal focused: starting by working with the customer to establish “user stories.” These stories are prioritized and lined up into “sprints.” After each sprint the customer received working features that can be used immediately.
2. Stakeholder engagement: Agile provides opportunities for stakeholder engagement before, during, and after each sprint. Delivering working software early and frequently increases stakeholders’ trust in the team’s ability to deliver high-quality working software and encourages them to be more deeply engaged in the project.
3. Quality of solution: Testing is integrated throughout the process and enables early and regular inspection of new features. A completed feature can be used immediately. If an issue is found, it’s resolved in the next sprint.
4. Predictable costs & schedule - the cost is predictable and limited to the amount of work that can be performed by the team in the fixed-schedule time box. Combined with the estimates provided to the client prior to each Sprint, the client can more readily understand the approximate cost of each feature, which improves decision making about the priority of features and the need for additional iterations.
5. Allows for change - allows for the introduction of previously unthought of requirements turn on a dime. Change is expected and accepted. Because features are completed within a sprint, the focus on subsequent sprints can be changed to include features that have become more important, or maybe were needed sooner than later.
6. People change: and one of the greatest benefits of Agile is the ability to make quick wins and show people that "out of little acorns, big trees can be grown". It allows people to change gradually, and to build momentum. 

I couldn't imagine implementing PLM in any other way!

The Key Elements Of An Agile Approach

At the front end, requirements are captured with what are called user stories. Each story is a statement of:

"As a ( the role) I want (something) so that it gives me (the benefit).” 

Each story provides enough information for the implementation team to scope the work and develop more in-depth requirements and tasks.

Once the user stories and tasks are delivered, sprint planning starts. The Sprints are short periods during which development work is undertaken, testing conducted and feedback from the customer/user gathered. 

For the sprint planning, a determination of what requirements need tackling, while balancing what can be delivered with usable functionality within weeks, rather than months. The customer can experience a steady and ongoing series of incremental updates rather than wait for months to see what’s going on.

With incremental updates, the customer can see new features after every sprint. In the traditional Waterfall approach, the customer typically may not see anything for months. When they do, some of the requirements may have changed. With Agile, the requirements are fresh and can be exercised by the customer after each sprint.

The daily SCRUM meetings during each sprint give everyone a chance to update the team on progress as each team member reports on what has been done in the last 24 hours, what they plan to complete that day and any issues they may have run into. 

The moderator of the meeting or SCRUM master is instrumental in this process. These meetings are intended to be about 15 minutes in length, and a good SCRUM master makes sure you stay on track and determines if follow-on drill downs need to be scheduled.

And So, Why Do Agile Projects Fail?
1. Weak Leadership
2. Weak Team
3. Stakeholder Communication
4. Requirements, Both Quality & Quantity
5. Running Proper Retrospectives
6. Doers Not Talkers Please
7. Project Metrics
8. Scope creep
9. Training
10. Experienced People

Nothing great comes easy! I've always found, just when you start to relax and let things take their course, everyone relaxes and things go wrong! The same can always be said for PLM implementations and in fact all projects.

Here's a few reasons I see why Agile can fail:

Be sure that the person you choose to be the ScrumMaster (or leader) is truly capable of leading, overseeing, and performing any follow-through that must be undertaken.

Make sure that your team is dependable, efficient and does what they say.

Poor communication between stakeholders is a common downfall of any project. Unfortunately, some stakeholders may not be very clear in what they expect from team members and this forming a solid communication plan is essential.

Agile and in fact all projects frequently fail due to lack of definition. To avoid having a project with incomplete requirements, or an abstract scope, take the time to carefully breakdown the project into the action items that must be undertaken for project success. This is where strong PLM and Product Innovation Platform project experience together with meticulous planning comes through.

Agile projects depend on retrospectives being performed so that you can discuss with team members what was learned, how the team is performing, and how your team can improve. If you are not holding proper retrospective meetings, your team may falter for it. Not only will it be more difficult to place where everyone is, but if a team member struggles while another can help them out, you are missing out on an important opportunity for collaborative project success. Make sure to hold retrospective meetings on a regular basis.

Team members and stakeholders cannot have "removed" ("it's different where I am") processes and they cannot hide their progress or lack of and they cannot depend on the organization to pick up the slack. If team members are not fully accountable for their actions, the project will fail.

Six Sigma and Lean have a definitive set of metrics for determining quality in your project. Because Agile does not have a cohesive set of metrics, it is absolutely necessary to ensure that you do use some form of measurement to ensure quality.

Oh yes, it hasn't gone away. Even on Agile, Sprints build-up additional dreams from the users and business and this build-up can quickly overwhelm the team. To avoid this, take the time to construct the scope statements before undertaking the project.

Many teams face difficulties because they are not aware of the organization of the Agile methodology. In order to avoid this, take time to learn and train all team members in Agile. You won’t regret the investment of your time and money into this process.

I know, I'm biased but putting in place experienced Software Solution Architects and Project Managers, together with a great ScrumMaster is so essential in the exciting world of the agile implementation of PLM & the PIP. Those skills sit on top of your mountain of work and can see the problems coming before anyone, because they've been there before!

Link: Agile PLM Implementations - is there another way? | LinkedIn