Simple Scrum: Part 1

Scrum that works (and doesn’t) for software and security professionals

One of my posts on Scrum.

Free Content on Jobs in Cybersecurity | Sign up for the Email List

2nd Sight Lab uses scrum to create our class materials and labs. We assign testers stories for labs and class slides they need to review and test. I use the simplest version of scrum I can because we have a small, agile, lean (insert your favorite buzzword here) team. But I’ve always preferred a simple version of scrum. Since I’ve been revisiting this topic for a new team member, I’ll share my version of scrum with you — that works.

Where did I get my viewpoints on scrum?

I have a track record of delivering successful projects that deliver business results with very few bugs to production. I helped a startup with five people grow to a multi-million dollar company as the primary technical person who wrote a lot of the code myself. I also worked on complex back-office banking and tax systems for companies like Nordstrom and Capital One that saved or made millions (possibly billions) of dollars. I’ve got over 25 years of experience as a software developer, security professional, and business owner. I understand the alternative viewpoints when it comes to completing projects — like the one we are completing now: A new cloud security class on AWS Governance and IAM.

Security professionals need to understand scrum

When security professionals want development teams to help them implement new security initiatives, they need to understand how development teams work and get the work into the backlog. I taught my cloud security class to a team of penetration testers at a major financial institution in the U.S. At one point, they said, “The developers hate us.” I already knew, but I asked them why. They said because when we bring them all their findings, they get mad at us for delaying their project. I explained how to fix that, and I’ll explain it in this series of blog posts. I’ll also explain a bit about my version of scrum. But first, I want to tell you why scrum fails.

By the way, security teams can use scrum too! You’ll understand how after this series of blog posts.

When scrum fails

Before I tell you what scrum is, I want to address when and why it fails. You may be apprehensive about leveraging scrum because you’ve dealt with it in the past, and it didn’t work. Here are the reasons I’ve seen scrum, and projects in general, fail. I’ll tell you how to deal with — and fix — all these problems.

Uncooperative Team. When I was both scrum master and team lead for a development team at a major financial institution some people called our team “The Dream Team.” Why? We got stuff done without a lot of drama. Of course, that also was in part the people I worked with at the time. A team needs to work as a team. If everyone doesn’t do their part, it’s going to be hard to be successful. At one point, someone joined my team who later blatantly undermined me. I told my boss I wanted that person off, and he was gone. The team thrived after that. (This happened twice, actually.) There are other ways to deal with an uncooperative team member, and you can’t just kick everyone you don’t like off your team. But success for team leaders ultimately depends on having leadership support, such as those two bosses did for me. I feel this is especially important for women and minorities.

Overhead. In addition to having an awesome team, we followed the process I will explain to you. That same team struggled to deliver under a certified scrum master. Bleh. The company brought in professional “scrum masters” for some unknown reason and forced our already successful team to bring one on board. That’s when it all went downhill. My team got dragged into meetings every five minutes — one to do a team-building exercise where we had to describe each others’ shoes and one where we had to build a gingerbread house. We had to sit through meetings of pontification about scrum and project management. Maybe that sounds fun to you, but I’d rather be getting work done, personally.

Even more overhead. By the way, I took a PMP class for security professionals also, and after decided I would never get that certification as there’s no way I’d want to ever have to do that. Way, way, way too much overhead, and paperwork. Project managers can be more successful with 1.) less paperwork, 2.) simpler reports, and 3.) more effort on getting time-wasting distractions away from teams so they can focus on deliverables. You also need to understand how to ask the right questions and define a transparent, simple tracking system to get accurate project status. More on that in upcoming posts.

Lack of over-arching project management. Scum has components that can help you define an overarching project management framework, but some fail to use them. You can’t just let people throw whatever stories they want in a backlog whenever they want to change something and hope to deliver a project on time. When something goes in, something else has to come out to meet a deadline. A change management process needs to include adjustments to project schedules. You need to understand how fast individual teams work and their capabilities and plan accordingly. I’ll show you some simple tools to add project management to your scrum process to meet deadlines in upcoming posts.

Security at the end. Related to my last point, if the security team comes in at the end of a project and finds several security flaws, this can derail a project schedule. Sometimes a security flaw requires a complete architecture overhaul to fix it properly. Teams need to perform threat modeling during the initial architecture phase, and each time an architectural change is proposed. On-going testing will help as well.

Shifting Priorities. Teams need to be able to focus on a project from start to finish to complete it quickly. When teams are constantly distracted by shifting priorities, they can’t work as effectively. Security teams need to understand this as well and how to get security priorities inserted into the software development workflow.

Poor project requirements. Project requirements should define what not how. This includes security requirements. Developers may have a more creative way to meet your security requirements than you can imagine. Include error handling and reporting in your requirements. I always asked for the reports management needs to see and the questions they are trying to answer because that drives the data you need to store and how it needs to be structured.

During one project, the requirements were not sufficient so I asked to go sit with the people performing work to process complex financial processes. Once I understood how they worked, I added stories to the backlog. One of those stories was a screen to view and filter all the errors in the process. The manager on the team said that was her favorite feature delivered in that project. Security teams can sit with developers to understand the impacts they are proposing on system architectures and how teams work.

Bloated deliverables. Keep your deliverables small. Focus on the minimum you need to get a working product out that makes money. At one company we went in circles discussing and revising dashboards when the product didn’t even have a login screen yet because the product managers were more focused on graphics than a working product. I love dashboards, so don’t get me wrong. But if the customers can’t log in, you can’t release the product. You may be able to release a product with a simpler dashboard and enhance it over time, so you can get customer feedback before you pour a lot of time, money, and effort into those fancy screens. Additionally, you can start making money.

Lack of effective metrics. You need to understand what to measure to have an effective scrum process. Measuring how many stories you complete each sprint doesn’t tell you much. I’ll explain some of the formulas you can use for effective scrum metrics.

Lack of leadership support for a working process. Been there. If the leaders of your organization undermine the process, then it won’t work. In any aspect of your work — design, development, team management — lack of support by executives will kill an otherwise successful product or project. A person with a proven track record of delivering value who is undermined by their executives will not be successful over time. Often, politics are at play, and executives need to spot this and deal with it effectively.

Shortcuts! Shortcuts in development and security may help a project get done faster in the short term but will cost you in the long run. One company I worked at had two teams working simultaneously on delivering products to market. One team took shortcuts to get a project to a live state. Afterward, the product crashed repeatedly in production.

The other team built-in security, failover, disaster recovery, and governance for management of security later in production. I can’t tell you how this ended up since management undermined the process, but I can tell you rushing the first product to market was a disaster. We can also see from news reports and statistics about security incidents that lack of governance and security configuration best practices in cloud environments is driving numerous massive data breaches.

At another company, I built a solution to process hundreds of thousands of records and planned for errors with built-in error handling. The timing worked out that it was delivered while I was on vacation so I was incredibly nervous. It worked perfectly. A handful of records were trapped by an error handler and were resolved by the time I got back. Another team developed a similar solution and said the error handling wasn’t worth the effort. They spent months trying to get through their dataset as error after error popped while trying to process the records. I know this because my boss complained to me about it.

As I always say, pay now, or pay later. Put those security and architecture stories into your backlog!

Inexperience and lack of engineering skills. Having been there, done that, will help some architects and developers eliminate unnecessary steps without weakening the integrity of the security or architecture. I’ve also witnessed too many times where a manager allows an inexperienced or less-skilled part of an architecture to be “nice” or because they like the person. The end result is that the project blows up in production or critical components need to be re-written, making the project take longer. It’s hard to know who can and cannot build a critical piece of your system but looking at someone’s track record when things get released will help.

Who delivered rock-solid software that made the company money, and who delivered software that failed repeatedly upon release into production?

How to fix the problems with scrum

Follow a simple process geared at getting things done. I’ll explain that in my upcoming posts and where security needs to fit in.

If your management team doesn’t support a working scrum process, you can attempt to convince them to improve it, possibly by providing the information in these blog posts. However, at some point, people may have their viewpoints locked in and are not change their minds. Arguing about it with them is futile. As we can see from people’s reactions to vaccines right now, some people’s minds are made up, and they are not going to change (except in some cases when they become one of those people in the news regretting their decisions — or not). Currently, it’s up to each individual to make their own choice unless new laws go into effect. You can spend all your time trying to convince someone to do something, or you can move on to another organization (or state in the case of the vaccine) that aligns with your viewpoint.

That’s exactly what I did. I tried to convince my upper management to remove our scrum master (and resolve some other process issues). I explained by demonstrating the project delays, overhead, and cost of employing the scrum masters versus returning to developer lead scrum masters as we had in the past. When the company refused to resolve the issues, that’s when I made my move (and it was probably a good thing!) to the original Capital One cloud engineering team. Sometimes change is the best thing for your career.

My boss (who was a great guy, by the way, and one of my favorite bosses ever!) asked me why I cared so much and to stop worrying about it because I was making a lot of money. I explained to him that, having run a business, I knew that if the company couldn’t successfully deliver new products and features in a timely manner, the company would not be in business much longer. I moved on. The parent company later sold off that division of the company to their most despised rival.

Projects need to get completed — with architecture and security in mind. Get security baked into your scrum process and get projects done. Stay tuned for more information on how to do that.