Automated Unit Testing “Slows Us Down”

Have you ever experienced this? Vendors or teams of developers claim that being forced to write automated unit tests slows them down? How do you answer this? Even more importantly, how do you correct this misconception?

In my experience, this issue is particularly prevalent (a) with large consulting companies and (b) with inexperienced developers. Most of us have been on projects where bait-and-switch occurred with a large vendor – the A-team troops in for the vendor selection meetings; the project starts and suddenly the A-team moves on to the next procurement cycle and you are left with the “green team”. That’s “green” as in inexperienced, not “green” as in “efficient”.

So, scenario A results in scenario B and the true problem is … inexperienced and/or unprofessional developers!

I maintain that, if you hear claims that unit testing is slowing down a team, you should realize that you are dealing with inexperienced and/or unprofessional developers and act accordingly.

You have to ask what is the product that is trying to be achieved and does the vendor’s or developer’s idea of that product align with your organization’s view of that product? Here is a true example.

The “product” of one vendor with whom I worked on behalf of a client could be described as “the ability to bill for the next milestone payment”. The contract called for a milestone payment for “the completion of coding” with no criterion for quality included. Here was an example of the contract wording precipitating a problem in the execution of that contract. Naturally, any activity outside of strict coding, such as creation of automated unit tests, was frowned upon by both the vendor program manager and vendor account manager. Why? Because it delayed their product – being able to bill. It was very shortsighted because the result was incredibly poor performance in functional test – the worst example being that 83% (five out of every six) functional tests for one code drop failed upon first execution.

Interestingly, unit tests had to be delivered as part of the contract but the vendor, behind closed doors, talked the client into not requiring them until after functional test (and hence after the payment milestone). The client was not technically savvy, as you can no doubt tell. The unit tests were coded last – mostly by even more novice programmers than the developers of the feature under test – and ultimately delivered. Upon inspection, they were found to not provide proper coverage and, in many cases, did not actually test anything. The only way the test would have failed was if an exception occurred. The vendor fought against automated testing throughout the project even in the face of the evidence of functional test failures.

What was the overall result? For that one code drop, coding took about eight weeks, but then it took more than eight additional weeks to pass functional test. [Yes! This was a waterfall project … at least initially.]

It can be demonstrated that writing the automated tests first or in parallel actually speeds up the development cycle. So instead of taking 8 weeks to produce a fully tested and testable product, it took over twice that long, which caused a domino effect with all dependent projects having to re-plan to take into account the delay.

A bunch of untested line of codes that have “been finished” only because the developer clicked “Save” and went on to something else is not a valuable or a final product.

As the principal architect and technical lead, the product that I want has nothing whatsoever to do with billing cycles. It has everything to do with a finished, quality product. I want the product to be the programming, the tests which verified that programming, and any documentation needed to make that programming understandable and maintainable. That is the definition of a true product.

In Scrum this equates to the Definition of Done.

Scrum emanated from the Toyota Production System. How efficient do you think an automobile production line would be if components and assemblies were not tested before they were bolted on to a car or truck in its progress along the line? Not efficient at all. In fact, such a company would likely be out of business in the twinkling of an eye.

Quality is not injected into a product by some magic incantation during the QA cycle, it has to be built-in from the very beginning. Automated unit testing is a key ingredient of that quality.

Any developer who has any pride in their professional standing would want to ensure that the code he or she produced was guaranteed to the utmost of his/her ability to work correctly. I have worked with true professionals who have shared my mantra that “if someone else finds a bug in my code, I would consider that an insult”. However, with inexperienced developers and vendors pushing to get paid regardless of the quality of what they produce, this level of professionalism is often not present or has been beaten out of the developer culture.

Let’s stop trying to “quickie” development (rush through something without concern for quality) and produce true quality software products that will keep the assembly line flowing without costly stoppages.

Learn more about how to make automated unit testing a pillar of your software quality and do it in a real scrum environment in the Scrum Adventures CSD course.

--Ivan Biddles

Scrum Developers of the World Unite! Now is the time to get your CSD!

Did you know that there are close to half a million Certified Scrum Masters in the world but less than six thousand Certified Scrum Developers? And yet in any scrum team, there are likely to be between four and seven developers (team members other than the product owner and scrum master) for each scrum master.

So, for half a million CSMs, there should be millions of CSDs.

Being a software developer does not necessarily mean that you will be effective and efficient in a scrum environment. There are development practices and there are developer activities that apply to scrum.

It is also not true that a non-technical (hands-on) person such as a project manager who takes the CSM course is going to be able to come back and lead change management in development practices. Those practices are not taught in the CSM and the new scrum master is not versed in them either. A CSC (certified scrum coach) who has never been a true hands-on developer is also not going to be able to help the scrum developers in improving their development skills.

A CSM course teaches a person to start on the road to becoming a scrum master, but it does not teach a developer to become a scrum developer. That is not its purpose.

That is the express purpose of the CSD course!

The CSD course is a hands-on course applicable to architects, designers, “coders” and QA personnel. The Scrum Adventures CSD course is unique in that it teaches the skills and practices of the ultra-successful software companies (activities and philosophies that set them apart from others) while building an actual product within a scrum team, iterating through a series of actual sprints with all of the scrum ceremonies. You truly demonstrate that you know how to do and have even done scrum development.

It is up to developers themselves to take the responsibility to be effective in a scrum environment. Your managers may not understand that it takes more than a project manager retrained as a CSM, or a non-technical coach, or even developers sent to the CSM course to make scrum effective in your organization. Developers should be able to identify when their scrum team is being effective but also to identify situations where what is being done is “not scrum”. Scrum is incredibly successful if it is being done, but when one or more essential aspects of scrum are omitted, especially in the development arena, that success can be elusive. It can even make things worse.

Having the Certified Scrum Developer designation sets you apart as a developer. It makes you one of just a few thousand who develop professionally using scrum practices and are certified as such.

--Ivan Biddles

Empowerment and Borrowed Authority - A Cohesive Relationship

What is Empowerment? For those of us who have experienced it, Empowerment comes when oneself comes to the realization that they are self-powered to make things happen. For example, “As a Scrum Master, I am empowered to protect the development team.”. Not only is it my job, but it is expected. This is the embodiment of Empowerment.

There are many types of authority, you’ll see some in government, education, healthcare, business and familial. For the purpose of this blog, let’s introduce Borrowed Authority. Borrowed Authority is authority that is granted to you from someone who naturally has authority. The person who naturally has the authority might be a world leader, executive or matriarch. Thinking about this Borrowed Authority from a business standpoint and how it relates to Empowerment, a person of authority might hire you with an expectation that you are empowered to perform the job for which you are hired. However, this does not naturally mean you are able to perform the job effectively. Let’s continue with the example of the Scrum Master. As a newly hired Scrum Master, you start to perform the job and protect the development team. However, you tend to notice that the sprint goals aren’t being met. Upon further examination (i.e. retrospective), there are members of the development team that are performing outside work. Since this development team is embracing the retrospective – good job – you learn that an executive is directly contacting the development team and requesting special work.

Are you seeing the picture? “Wait, I’m empowered – why is the team taking on special work? Oh wait, I don’t seem to have Borrowed Authority! Why am I here?” Don’t fret, this can be fixed.

Since we have now realized team success will come with your Empowerment and Borrowed Authority, it is time to talk with the executive. “Hey executive, I’d like to be the Scrum Master that I was hired to be. In order to create a self-directed team, I need your authority – as in Borrowed Authority. Please meet with me and the development team. You can state that I am acting on your authority and the team will work through the Scrum Master so we can do great things. The Scrum Master will bring any blocks to my attention that need resolving.”

Is it coming together? By having the executive, who we discovered is the root of the cause for missing the sprint goal, grant his/her authority to the Scrum Master, with public display, the Scrum Master can now act on the Empowerment of the role.

We have now come back to the title, “Empowerment and Borrowed Authority – A Cohesive Relationship”, Empowerment is great and necessary, but to be truly effective, add the cohesiveness of Borrowed Authority.

What do I do with my Project Managers?

I was recently asked this question by a Project Manager who is undergoing a transformation to Scrum within her company. Scrum tells us that there are three roles, the Product Owner, the Scrum Master and the Scrum Team. No mention of a Project Manager...hmmm. What to do? As you might do on an assembly line for a new product, let's retool our Project Managers. They might want to become a Scrum Master or Product Owner. Generating awareness about these roles to each Project Manager will create excitement and a renewed energy. It might also remove any fear about being out of a job. As part of retooling the Project Managers into trained Scrum Masters and Product Owners, they will need coaching. No, not soccer coaching, although that is one of my passions, but Scrum Coaching. Transformation for an organization, company, enterprise, department, classroom, squad, etc.. requires new skills mixed with experienced personnel.

You're reading this and might be thinking, "sounds good, but what about all the duties that a Project Manager performs?" Ideally, these are now Scrum Team activities. These duties become part of the product backlog to support a product feature, but that's another blog. A lingering thought is to add a coordinator, as in Project Coordinator, to the Scrum Team. This coordinator is a member of the Scrum Team that has skills such as finance, invoice, contract, staffing, etc.. Just remember, everything they do must be all about the product.

Let's talk money. Retooling your Project Managers requires an investment. As a rule of thumb, the cost of replacing a resource is equal to their annual salary. Wow! A Project Manager earning $100k/year would cost you $100k to replace them with a new hire of a Product Manager or a Scrum Master. Training will cost about 10%, or $10k to retool your Project Manager with costs for the CSM or CSPO course, travel and time away from the office. You just saved $90k, great job! But wait, do you recall I mentioned Scrum Coaching? Good recollection. Coaching is invaluable to take these burgeoning skills to use. Scrum Coaches typically work with a multiple of Scrum Teams, thereby spreading their cost into productivity gains. Much less than the remaining $90k.

Retool your Project Managers and create a Happiness factor, also another blog, and supplement with Scrum Coaches.