Agile Design and Tracking, Part 1

Timothy Trimble
May 14 · 4 min read

Introduction

I’ve been around for a while. In the dark ages, I taught myself how to write video games. It was not pretty, but I got it done, and I learned a lot. Then I leaped games to business applications. Being the studious and observational home-grown developer that I was, I quickly learned the GIGO principle — Garbage In = Garbage Out. If you want good software to be delivered, you have to put good design and quality into it. Just as a reliable house has to be designed and built, a reliable application requires quality design and effort. In these series of articles, I will attempt to discuss why and how the use of quality Design and effort Tracking is necessary for successful Agile based projects.

Waterfall

Many years ago, I wrote an article about the application of best practices for the Software Development Life Cycle (SDLC). At that time, the trend in software development was the use of the “Waterfall” method — Analyze, Design, Document, Develop, and then Implement. When followed correctly, it can result in successfully implemented systems and happy clients. However, the reason for my writing the article was due to my frustration with many organizations ignoring critical processes in the SDLC and ending up with unhappy clients, delayed delivery, and cost overruns. Throughout the years, this article has been the most popular download from my website, and I credit the inclusion of this discussion to the success of my FileMaker Pro Design & Scripting for Dummies book.

Agile

Today, there are very few organizations relying on the Waterfall method, and instead, they aim for following Agile, SCRUM, and Continuous Deployment. Instead of designing the entire system up front, a core set of functionality is implemented, and then additional features, fixes, and improvements are provided on a regularly timed cycle (2–6 weeks, or continuously deployed as each piece is completed. The goal of these newer methodologies is to provide systems that meet the continually changing needs of the business. While this is very beneficial to today’s businesses and consumers, it also promotes a “need it now” mentality.

Need It Now! Mentality

As a world-wide, internet fed society, we have become accustomed to instant gratification. Amazon Prime is so successful because their customers can order in the morning and receive it by the end of the day, or the next day. This process is great for consumers and is good for the manufacturing and delivery industries. However, when this mentality is carried over to application development, we end up with the same problems we had with the Waterfall methodology. The client wants it now, the developer wants to get paid, so again, we cut corners and deliver a product that is poor in quality.

Why We Do It!

When you want a house built, you create a design, make blueprints, buy materials, and hire builders. The hired contractor has a pretty good idea of how long it will take from groundbreaking until the move-in date. We don’t question this or ask for it to be done in half the time, and we know government paperwork and weather can have an impact on delivery. However, when it comes to application development, we ask the client what they want, we mock it up with our feature-rich graphics programs, send the Statement of Work with the graphics, and an estimated date of six weeks for the first core implementation. The client says it shouldn’t take that long since you already have the User Interface made and they want it in three weeks, or they are taking their business somewhere else. So, we gulp, agree, take the first check, and hand the SOW over to the project manager with a statement of “get it done.” The PM throws together some Agile Stories and Features, hands it over to development with a comment of “get it done.” The developers put on their cowboy boots and dive into the code. Six weeks later, after multiple false starts, the client takes delivery and hesitantly hands over the payment. Ten weeks later, we scratch our heads wondering why the client does not want any more work done, and we lose the client. Yes, we got paid, we’re not sure if we really made a profit, and we go hunting for a new client.

Results

There can only be a few results from the above scenario. The business will continue to skip quality design and tracking, continue to be unprofitable, and will eventually go out of business. Alternatively, the business will figure out the need to use a quality design process and track their efforts for measuring their success, and thus continue to grow and make their clients happy. As I used to tell my teenagers before they started driving, if you want to continue to live and not kill anyone, you have to follow the rules. As soon as you start ignoring the rules, you put yourself and others in danger. Yes, a grim illustration, but the life or death of a business can be traced to the management’s ability to follow or ignore the rules of the processes.

Part 2 — Expectations

In the next article, I’ll go into why it is essential to set the level of expectations at the very beginning of a project.

Feel free to let me know what you think of this first article for “Agile Design and Tracking,” and if you have any specific content, you would like to see me cover in future articles. You can respond here or contact me via my website at www.timothytrimble.com

Timothy Trimble

I’m a published author, freelance writer, technologist, and software developer! Basically, a geek who likes to write. TimothyTrimble.com

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade