Dave-Perkon-headshot-online
Dave-Perkon-headshot-online
Dave-Perkon-headshot-online
Dave-Perkon-headshot-online
Dave-Perkon-headshot-online

Agile project management control design methods

Jan. 25, 2016
Agile software project management methods work for design projects as well but be sure to not turn it into a micromanage to-do list.
About the author
Dave Perkon is technical editor for Control Design. He has engineered and managed automation projects for Fortune500 companies in the medical, automotive, semiconductor, defense and solar industries.

Much has been written about project management. You have probably been to a seminar or week-long project management class and now have a certificate to officially break down a project, line up the work and knock down the tasks in a sequential fashion. This waterfall project management method works well, but the fine details, dates, resources and hours may be a bit constricting when changes occur.

With waterfall project management, when change occurs, especially later in a project when the requirements have been cast in stone, it can be costly. Another method, agile project management, embraces changes by simply updating a product backlog and planning it into the next sprint. It also provides a good framework that may help to promote creativity and responsibilities of all team members involved.

Agile project management started in the software development world but works well in the machine build and control system design and integration world also. The focus of agile is a framework for breaking down work, passing it out to the team and keeping the team communicating. The end result is a close-knit team delivering small pieces of the project constantly.

Also read: Multidiscipline teams transcend platforms and solve problems 

Agile breaks down the work to create many deliverable pieces to show the customer progress, not just one final, completed machine. Instead of the project management providing rigid processes and procedures, agile empowers the team members using daily communication. Agile also promotes collaboration with the customer and responds to change instead of negotiating or just following a plan.

Although there are many principles, roadmaps, roles and artifacts to agile project management, some of the key concepts are the framework, product backlog, planning events, the sprint and daily scrums. The project owner, development team and scrum master all play important roles in agile. The project owner defines what to build; the development team decides how to build it and by who; and the scrum master keeps everyone working together and removes roadblocks to completing the work.

The project owner defines the vision or elevator speech of the project, creates a road map of the major milestones of the schedule and creates the product/project backlog—a list of goals, stories and tasks for the project. The backlog includes features, functions and requirements. It also includes changes, enhancements and fixes; and it can also be used to prioritize tasks and risks.

This backlog also has large top-level goal stories that may be broken down to smaller pieces as part of planning events. For example, the control schematic may be broken down into smaller pieces, such as power distribution drawings, safety circuit diagrams, network architecture, I/O list and panel layouts. Similarly, machines may be broken down into stations or assemblies and programs into features and functions.

Sprint planning is a big part of the agile project management framework and involves the project owner and team reviewing the product backlog, creating a sprint goal and a related sprint backlog of tasks to complete in the next week to month. These goals are deliverables to keep the project moving and can be something used to keep the customer seeing progress on the project. Many pieces of the project are completed during each sprint with the result being a potential customer deliverable.

For example a “confirm part handling” sprint’s goal is to confirm the robot material-handling concept will work and could include preliminary program sequence outline, selection of robot and vision system, preliminary prototype end effector design, manufacture of a part-handling method and building of a test fixture. The sprint deliverable is a test platform to confirm the robotic part-handling accuracy and repeatability testing that could be part of another, separate sprint.

With the product backlog and sprint goals defined, the team, during sprint planning, decides how the work will be completed—it’s self-managed and can make its own decisions. This includes organizing the work into manageable pieces of two to eight hours each, agreeing on who is responsible with the responsible person committing to getting the work done. This is a common point of failure of agile.

The failure is that the project owner or manager will define the what and how and then demand the work is done by the date he decides. Agile should promote an openness and focus where everything is visible to the team and each member can focus on the tasks within the sprint without others constantly pushing a different agenda. Many project managers are happy to micromanage, turning a well-planned sprint into a to-do list with due dates. It’s better to let the team own the decisions and commitments.

To keep the sprint moving to completion—a term the agile community likes to call “velocity”—it is important to have a daily scrum. It is probably the most important part of agile project management. The daily scrum is a 15-minute standup meeting for the sprint team used to synchronize the tasks and activities and review the plan for the next 24 hours. Pick a time and place to have the daily scrum and stick to it to keep it simple.

During the daily scrum, each team member explains what they have completed since the last meeting, what they will complete before the next meeting and what roadblocks are in the way of completing their tasks. The bottom line is every day the team should be able show how it plans to work together as a self-organizing team to meet the sprint goal and produce project deliverables. Break it down, line it up and knock it down.

About the Author

Dave Perkon | Technical Editor

Dave Perkon is contributing editor for Control Design. He has engineered and managed automation projects for Fortune 500 companies in the medical, automotive, semiconductor, defense and solar industries.