software solutions / project leadership / agile coaching and training

Wanted: Technical problem solvers

Posted on April 12, 2018

Most developers are used to working in a team environment, where a business analyst writes requirements, a developer writes the code, and a tester tests the code. This is a widely accepted practice, yet something about it is inherently inefficient.

Don’t get me wrong, I’m not saying that doing things this way is bad. Yet anytime you add someone else to a process, it becomes inherently less efficient because those people have to communicate and get on the same page. Generally the inefficiencies are outweighed by the benefits of having people using their strengths to help move the process along… but not always. Let me explain.

On Agile projects, requirements are not the deliverable, requirements are just a means to an end. Requirements often serve other purposes, for example, communication with business partners about what is going to be built in order to make sure you’re building the right thing. But if you think about it, requirements are in a way inherently inefficient.

Software development is a series of translations. Our goal is to take business ideas and translate them into working software. This is obviously easier said than done. On a typical project, there are many levels of translations: business person expresses ideas to a business analyst, who turns those into requirements with acceptance criteria, which developers turn into code and automated tests, and QA people turn into test plans, which leads to some UAT process with users, which eventually gets deployed to production. This process has been proven over the years to work well, but there are many translations that have to happen during this process in order to software to get created.

My argument is that there are some cases where this process is more than we need. What if for certain projects or functionality, a person or small group of people could just go solve a problem? Forget about writing requirements using the typical methods and just streamline the process and get something delivered quickly. Think about the average ticket that a BA has to write. It takes a long time to type that up, and when they do, there still isn’t any code written.

Doing this takes a lot of skill. If you developer doing this, you need to be able to communicate with the business, understand what they really want, be able to speak to them in their terms, develop a working solution, sufficiently test your code, and work with business people to make sure everything was built correctly. But if you can do this and write just enough requirements and develop and execute a comprehensive test plan, you potentially could deliver working software much faster.

I would argue that this should be the next step in the career path for senior developers. Are you able to deliver working software without the assistance of business analysts and the validation of QA testers? If you’re able to do this, you’re able to keep progress moving while freeing up business analysts and QA testers to have time to focus on areas where they’re needed.

One of the projects I’ve done that I’m most proud of was a 6 month BI ETL project where I was the only one on the team. I had to gather and write up all the requirements (I didn’t skip this part because people needed to know how it worked), write the code, test it, and make sure it continued to work in production. This code is starting its 5th year in production now, and it’s allowed people on several systems to develop against a data model that is going to be around for a lot longer than my code.

How long would that 6 month project take if we had a business analyst and a tester on it? Would it have taken much less time? Probably, but certainly not a third of the time, because so much communication would have to take place in order for everyone to get on the same page.

Now that I’m leading a team, I’m always looking for developers who can take ownership of a technical problem and deliver a solution for it. Are you able to do that? If not, what skills do you need to acquire to be able to? (It might not be coding skills.)

This is not an attempt of a team leader with a development background not appreciating business analysts or trying to cut them out of the process. I’m saying that as developers, sometimes we use business analysts and QA testers as a crutch. If you’re able to deliver technical solutions without this support, you can take your team and career to the next level.

No Comments »

No comments yet.

Leave a comment

I have over 15 years of software development experience on several different platforms (.NET, Ruby, JavaScript, SQL Server, and more). I recognize that software is expensive, so I'm always trying to find ways to speed up the software development process, but at the same time remembering that high quality is essential to building software that stands the test of time.
I have experience leading and architecting large Agile software projects and coordinating all aspects of a project's lifecycle. Whether you're looking for technical expertise or someone to lead all aspects of an Agile project, I have proven experience from multiple projects in different environments that can help make your project a success.
Every team and every situation is different, and I believe that processes and tools should be applied with common sense. I've spent the last 10+ years working on projects using Agile and Lean concepts in many different environments, both in leadership roles and as a practitioner doing the work. I can help you develop a process that works best in your organization, not just apply a prescriptive process.
Have any questions? Contact me for more information.
From Stir Trek 2017
Iteration Management - Your Key to Predictable Delivery
From Stir Trek 2016 and QA or the Highway 2015
From CodeMash 2016, QA or the Highway 2014, Stir Trek 2012
The Business of You: 10 Steps For Running Your Career Like a Business
From CodeMash 2015, Stir Trek 2014, CONDG 2012
From Stir Trek 2013, DogFoodCon 2013
(presented with Brandon Childers, Chris Hoover, Laurel Odronic, and Lan Bloch from IGS Energy) from Path to Agility 2012
From CodeMash 2012 and 2013
(presented with Paul Bahler and Kevin Chivington from IGS Energy)
From CodeMash 2011
An idea of how to make JavaScript testable, presented at Stir Trek 2011. The world of JavaScript frameworks has changed greatly since then, but I still agree with the concepts.
A description of how test-driven development works along with some hands-on examples.
From CodeMash 2010
From CodeMash 2010