Do your progress meetings hinder progress?
Have you been asked to report your progress in percent complete, while what you really want to say is “Leave me alone, I’ll be ready for startup” There is an axiom in software development that says: 80% of the code takes 20% of the time and 20% of the code takes 80% of the time. Part of the reason is that the bulk of coding is things that are clear and you know how to do, so you speed through it. But the parts that you don’t know how to do take much longer to figure out. So, how do you really know where you are when you get finished with the parts that you know how to do?
There is a better way. How do you think Google or Apple keeps track of the massive programming efforts that they undertake? They sure as heck don’t sit everybody down in a big room and ask for progress updates. And they don’t go off programming for months without talking to their customers.
They use agile software development techniques and the technique that is specific to this problem is SCRUM. Remember the goal of agile development is the rapid development of usable code, and in process automation, this is the rapid development of control code that you can simulate.
The term SCRUM comes from Rugby where a tight group is working to advance the ball by passing it back and forth. In this software development technique, work is divided into sprints. These can be variable duration to achieve specific tasks, or a fixed duration. An example would be a one week sprint, where the work is broken down into the amount of work that can get done in a week.
The participants of the SCRUM are the people writing the code and the people who are going to use it, customers or customer reps. No managers are required! The meeting starts with a demonstration of what was accomplished last week. The customers provide feedback on what was shown and information on what may have changed in the past week. Then a quick discussion on the work planned for the next sprint and any impediments to getting it done.
Periodically, monthly in our example, an expanded SCRUM is held. In this meeting you recap all the work from last month in all of the SCRUMs and plan the next four weeks in broad strokes. All stakeholders are present and if necessary a review of cost and schedule is done. This meeting is a chance to step back and look at the project and progress overall.
SCRUM has many advantages over traditional progress meetings, but the key is that it plays to a programmer’s strengths. A series of short deadlines keeps developers focused and the rapid development of working code is very satisfying. The repeated interaction between the developer and the customer prevents small misunderstandings from leading to significant rework. And, you get a lot better feedback from an operator if they can see a working simulation rather than a spreadsheet or a stack of PowerPoint slides. Less time has to be spent documenting a detailed plan and more can be spent where it counts, doing the real work.
This post was written by Faron Cedotal and Scott Hayes. Faron is a senior control system specialist and Scott is a principal engineer at MAVERICK Technologies, a leading automation solutions provider offering industrial automation, strategic manufacturing, and enterprise integration services for the process industries. MAVERICK delivers expertise and consulting in a wide variety of areas including industrial automation controls, distributed control systems, manufacturing execution systems, operational strategy, business process optimization and more. MAVERICK Technologies is a CFE Media content partner.
MAVERICK Technologies is a CSIA member as of 3/20/2015