PLM Agile Deployment - 101
Most companies developing apparel and consumer products understand the benefits of PLM. The cliché answer to what those benefits are includes shorter time to market, improved communication, and better product quality. Those are just a few of the benefits that motivate businesses to engage in the laborious task of deploying a PLM system.
Traditionally, software deployment mirrored a framework or methodology known as Waterfall, made popular for software development. This method consists of upfront and contiguous phases. Those phases start with Planning, Design/Configuration, Testing, & Training/Deployment.
Late in the 90’s, came about a consensus of a group of trusted software development experts who agreed that Waterfall process was flawed. The inherit problem with this approach, for both software development and software deployment is that changes to requirements are often discovered late in the process, resulting in cost overruns and project delays.
Today, much of the software development projects are managed using an Agile approach. Benefits include a shorter deployment timeline, a heightened level of project communication, and an ability to make design changes quickly. Agile Deployment has been designed based on the framework used for Scrum therefore making it a bi-product of Agile and Scrum.
Agile Deployment uses an iterative approach called a Sprint and can last be anywhere from 5 days but no more than 30 days. This allows for the roll-out of functionality earlier in the project thus delivering benefit to the business sooner. In Agile Deployment, usable functionality is configured, tested, and deployed. Due to the shorter cycles, required changes can be found early and usually planned into the following Sprint.
Teams are self-organizing and cross-functional. This is an essential part of the success of Scrum and Agile Deployment. The members decide what work they will do and how.
Learning the rules of Scrum and Agile Deployment dramatically increase productivity
So how does it all work? Prior to the kick-off of the software deployment project, the requirements are gathered and written as user stories (see e.g. below). Those requirements are grouped together by functionality found in the software that can be used on their own or offer some value to the business and prioritized based on process.
For example, by rolling out material libraries first, the team can spend time adding in their core library items early on. This also gives the business another opportunity to identify any needed changes.
At the start of the project the core team and the business agree on the first group of user stories or the “What” of the Sprint. In this four hour or less meeting, they review the stories and agree that they are complete and clearly understood by everyone.
Next the core team starts to develop the “How” the work will get done. What is essential is that someone on the team has deep knowledge of the system and experience configuring it. Together the team identifies how the work will get done and what “Done” really means.
Each day the core team discusses their progress at a daily Stand-Up Meeting. These meetings are time-boxed and should not last more than 10 – 15 minutes. During the meeting each member of the team is asked three questions: “What did you complete yesterday?”, “What are you working on today?”, and “Do you have any impediments?” This keeps the lines of communication open and issues visible.
Close to the end of the Sprint, the team meets with the business to review the work that has been performed. This step should last no more than two hours and is called a Sprint Review Meeting, is a demo of the functionality and an opportunity for feed-back from the business prior to the roll-out. If the software is working as needed and the business has signed off, the users are given training.
As the functionality is rolled out the users are should start to merge the new functionality into their development process. During this time the users are encouraged to give feedback to the core team on what is great and what is a challenge so that any needed further changes can be made.
Finally the Sprint Retrospective Meeting is where each member of the core team gets together and each member answers the questions: “What was successful in this Sprint?” and “What could be improved for the next Sprint?” This is the core of continuous improvement; it gives the team a chance to reflect on what worked and what didn’t.
Throughout each Sprint there are tools for managing the work. One such tool, called a Burn down chart, is created to track the progress of the Sprint to insure the team stays on track for delivery. Estimating User Stories and the creation and management of a Burn-down Chart should be left to an experienced Scrum professional.
If your business is new to Agile and Scrum, it is highly recommended that you bring in a Scrum Coach. He will support the team to develop the right habits and to understand how to work within the Framework developed for Agile Deployment.
If possible keep your team in one location, you want one that works well together and face to face contact really helps to make that work. If that is not possible all is not lost, distributed teams can work but investment in the right tools will be necessary.
There are many types of software that help with managing the back log of requirements but when getting started invest in a white board and packs of Post-it Notes.
If your business plans to use Agile Deployment for future software deployment projects, consider getting some of the core team members certified as Scrum Masters and Product Owners.
This method, like anything new, requires patients as the team transitions from Waterfall into Agile Deployment. It will be trial and error at first but as the team begins to catch on and the business starts to see benefit far earlier than with traditional methods, it will become easier and the team will find their style and pace. If a team member is struggling to fit in, find a new place for her. Keeping the synergy within the team is essential to its success.
Learning any new method can be challenging but, with the right group and the desire to master it, great things can happen. Releasing functionality early gets your business early ROI. Learning the rules of Scrum and Agile Deployment dramatically increase productivity. Self-organizing teams require less management overhead and support intrinsic motivation. Finally having a definition of done engineered into each delivery makes for high quality work and a happier user group.