Having been on a number of development teams for more than 30 years, I have seen that we use different words for the same things back then. The goal is to get faster in development, make fewer mistakes, and be more relevant to the customer, but in practice we struggle just as much now as back then.
In the latest development team project, a main component within one of our products is a computer board. Now that there is a computer inside our device we need to program the thing. To make the computer work we had a small team of coders/programmers. Coders seem to have their own language talking about different functions, calls, gets, puts, and more. But there is also a language of the process to coding. Since that time I have come to loath the term AGILE.
Here is what I understand the term agile is supposed to mean — As a new developer comes up with an idea for an app, she develops something that she thinks captures her idea and that might work for her and others. The starting block of agile is to first develop a minimal viable product. Meaning, I would like to show you something that has the functions and flow and a little of the look of what I am trying to develop but I also know that it is not anywhere near being finished. She then shows it to 10 friends to figure out if they like it or not and what needs to change to make it better. She then takes the comments that have been captured, sometimes in user stories, and creates version 0.2. She shows that to the original 10 and then another 10. Again capturing information on making the app better. Each time developing and capturing, developing and capturing. The idea is that over time she has created the ideal app with the least amount of time between iterations. In theory this is supposed to speed the overall development process and deliver a more relevant product.
Now back to the development team. With agile development there are a lot of tools to help keep track of projects, tasks, sub-tasks, bugs, issues, user stories, and more. So our team uses some of the best of those tools. But we don’t really use the agile concept because we are not agile thinkers. Just because you have the tools of agile development doesn’t mean you ARE agile developers. In other words, just because you have a hammer doesn’t make you Frank Lloyd Wright.
Our team will agonize over every detail, which is good, but delays the implementation and the ability to come up with that minimal viable product to show someone. So much so that it never really gets out there to test. The team is not thinking agile just documenting like they do. Arguments ensue when the developers want to know what customers want and when the feedback is given, it is either mistrusted, “you didn’t ask the right people”, or has forgotten that the customer feedback on a feature was obtained months ago but now it is buried under a pile of other data and the developer asks for it again. (Forgot to put that in the agile development tools did we?)
One solution is with the original Customer Requirement Document. This is THE THING that is supposed to start everything off. The CRD describes the product or service, who would use it, how the customer would use it, how much should the parts or service cost, how much are we going to charge, what are the initial specifications, and more. In the old days this was the product plan but much more detailed and would take months to craft so that it could be put before the management team or board. Today we want to get to market faster so we streamline the process by creating the CRD. When the idea has merit we then go through a checkpoint. Some refer to this as stage gate or phase gate. Unless the idea can get through the gate, the internal approval process, it can’t go further. But as the development process continues, changes made, improvements, feature de-scoping, customer groups evolve, we rarely go back to the original CRD that started us on the journey. So instead of leaving this document to posterity, update the document and do some comments on the document. Whether you use Google Docs or Word or whatever, the features are there to track changes, collect comments, and more. When you find out that the cost is much higher than you anticipated, put that in the document and identify the potential impacts or alternatives. After a first round of testing we want it to be more accurate but it will cost more and the team needs to decide whether to open the accuracy spec and keep the cost or bite the bullet for more costs. When each of these issues come up, and lots of issues come up, add that vital information and the decision regarding that decision with the original document not buried in a sea of ones and zeros.
As a friend of mine said the other night “I am not afraid of change, I welcome change that will help me, don’t tell me that I will love it, show me how the change will actually help me.” So far changing to agile development hasn’t helped how we think or how we develop. But we use that WORD all the time. I would also embrace the change if it actually helped us because, at present there is a constraint on the mental activity that limits its constructive use.
There are so many great things happening in the world of product development with the widespread use of 3D printing and quick prototyping of circuit boards that it is a shame that the programming part, that also has some wonderful development tools, the part that is supposed to help us be faster to market, can’t quite seem to get there. So don’t use the word agile around me unless you really mean it.
Originally published in Medium - July 5, 2018