I have worked for companies that produce commercial software and for companies that don't produce commercial software. Those who don't produce a customer product typically create software to support their internal tools. They are concerned with things like internal integrations between databases and systems like an ERP, CRM, SalesForce, Data Analytics, reports, etc. Well, in either environment it's easy to slide into development patterns that look this...
A business manager has an idea to improve a product.
The business manager tells the developer to make the improvement.
The developer takes notes.
The developer makes the change, tests it, and shows it to the business manager.
The business manager disapproves of the change and the developer starts over.
The business manager eventually approves of the change.
The developer pushes the change to the production environment.
If I were to draw it, it may look something like this:
There you go. Not exactly an SDLC (Software Development Life Cycle). In fact, where is the cycle at all? This looks more like a Software Development Line. Unfortunately, this is reality for many businesses and it can be a challenge to convince business leaders that a better approach to developing software exists. To them, it can sound like just another eager software dev manager who wants to spend more money on something that isn't needed. Consequently, the design is not well thought out, the developer's time is not planned, there is no commitment to completion except ASAP, there is minimal testing, and the developer is constantly in the production system, GULP!
I learned a lesson as I saw executive leadership's increasing concern that production systems were buggy and nobody could give a solid answer on resources, capacity planning, or time predictability. I turned pale when the CEO looked at me and asked for metrics and key performance indicators. I wish I had the right answers for him at that moment, but over time I learned that despite what anyone around me may think about a software development life cycle, I couldn't provide any answers without one.
So what do you do in a situation where you know the benefits of an SDLC but others don't. There are two strategies I recommend in these situations:
First, implement a simple SDLC immediately
If you do a quick study on the internet, you may find an elaborate SDLC that looks perfect for you. In fact, I recommend that you read about my approach to how the SDLC can evolve all the appropriate processes, artifacts, metrics, KPIs, OKRs, and tools that you need to create a mature engineering system. However, your product may already be in jeopardy so start simple and get a handle on the situation. For instance, implement a Plan, Build, Test, and Deploy life cycle.
Plan - You may not have a product manager or even a backlog yet to gather features and stories, but you do have a business manager that can help you plan. Before you pass the requirements to your developer, sit down with the business manager and be sure you understand each feature and priority. Organize the work by stories if possible to capture the requirement and actors. Once you feel organized, talk with the developer and have her list the tasks that apply to the work. If possible, have her estimate the time it may take to complete the tasks and divide the tasks into blocks of time called sprints. Sprints work well in two week increments. With this information, return to the business manager and communicate the plan including any other issues that may block the developer during the build phase.
Build - When you create the tasks in the planning phase, the developer will also need to think at a high level about how she is going to accomplish the task. At this point, bring in your tester. If you don't have a formal QA, then designate someone to act as the tester. The tester should understand the plan early in the build process. The tester should start anticipating how to test the solution. The developer can also start vocalizing with the tester how she anticipates testing will proceed. This way she is always thinking about quality. Then give the developer and tester time to work on the first sprint.
Test - During the sprint, the work should be tested as much as possible. Start formulating tests around the testing pyramid. Start documenting test cases and find golden test records for future regression testing on the system. Most of all, ensure that the solution works with quality and does not negatively impact any surrounding pages or logic. Be sure someone other than the developer, even if it is you initially, and the business manager approves the delivery before it is released.
Deploy - If you don't have a deployment manager or deployment pipeline to govern the overall quality of the process, try to at least have a different person beside the developer deploy the code. Start a product release notes document that can be distributed to any customers that use this system or software as education and prove that you have control over what is deployed to your systems.
Second, continually advocate for a formal SDLC, Agile development, and tools
As you start a formal SDLC you have the beginnings of a process that will save your "you know what". You have also begun an Agile process similar to Scrum. Don't wait for leadership to come to you again, demonstrate what you are implementing with them now and explain how this is intended to fix the immediate problem they have observed. However, also be sure to let them know that what you have done so far is not the final destination to success. At this point, draw the full picture with diagrams and standard operating procedure documents that explain the long game that will make you successful. Explain that you need help from the Executive team and business managers, and you need tools. Be specific about what leaders needs to do that will back your decisions and help enforce these new processes. Ask for tools like Jira, Azure DevOps or Jenkins, and Confluence. These tools will help you organize feature requests into a backlog, create and monitor sprints, deliver metrics and KPIs, provide a pipeline for CI/CD (Continuous Integrations and Continuous Deployments), and organize documentation and notes. Make sure they know where you are heading and keep them appraised of your progress.
I realize that I am leaving out some important components to a complete software engineering team and some processes. I add it to my pipeline. Please read more of my blog to discover additional ideas and best practices.
On my journey, I try to consider my career as a continuous improvement and continuous deployment pipeline. For instance, as I study and learn more about creating amazing cross-functional scrum teams, how to collaborate with other departments, how to make and groom backlogs, etc. I find where this new knowledge belongs and what it replaces in my pipeline. I encourage
If you have any questions or comments about this article, I would love it if you reach out to me with me using the chat or email features provided on this blog.
Take care and go do something amazing today!
Comments