Friday, December 8, 2017

Continuous Integration: Let's Talk Turkey


Why practice Continuous Integration? What is the Goal? What is the Business goal behind improving engineering practices? What if we were to make this into a user story? What would it look like?  “As a business I want the ability to introduce features and functionality to my customers with very little risk, so that more people will buy and use our products without disruption.”

How would we accomplish this goal? You might start with a shift to agile. This would shorten the feedback loop between customers and the developers of features and products, thus ensuring you are giving them what they actually want. You might design your teams around products instead of subdividing the company by “IT” and “Business” and then further subdividing technical teams around technological silos and businesses around domain silos.

Those would be great steps to take. So how then do we deliver the product? We have product teams of comprised of business people and technical people that have all the knowledge needed to create the product. But how do we get it, and subsequent changes, to market in a world that wants everything right now, without exposing the company to the huge risks currently associated with big bang software releases? 

The silver bullet seems to be “CI/CD”. After all, it is on everybody’s lips. And they may be on to something. But do they understand it? Most people think CI/CD is a hardware/software pipeline where things get checked in to a repo and automagically "delivered/compiled" by Jenkins. But is it just software and hardware with some automation mixed in? When I ask people if they need help with engineering practices or with continuous integration, they often respond with:

“We are already doing it. We have Jenkins. We use git.”

“Hmmmm. So ‘having Jenkins’ and a repo means you are practicing Continuous Integration?”

“Well… we check into git and then Jenkins runs a build.”

“Ah! Cool! So all your code is integrated together and then you execute a test of all your functionality automatically through a test automation suite?”

“Well, no. Not all our functionality. Actually we don’t really have a lot of automated tests.”

“So you are just… verifying the compile??”

“Um… yeah.”

And there are other varied responses to this question. But the bottom line is that when we start probing we find that the practice of CI is not being followed. (And CD? They don’t really distinguish between the two.) So… They have the hardware. They have the software to kick off a build. But they are lacking in test automation or at least lacking in “good tests”.

assertNotNull(Object) does not qualify as a good test.

“Continuous integration is a practice–it is about what people do, not about what tools they use. As a project starts to scale, it is easy to be deceived into thinking that the team is practicing continuous integration just because all of the tools are set up and running. If developers do not have the discipline to integrate their changes on a regular basis or to maintain the integration environment in a good working order they are not practicing continuous integration.” https://less.works/less/technical-excellence/continuous-integration.html

Giving CI to dev teams without teaching them how to practice it, is like giving a hammer to a six year old. Just because the six year old is able to lift the hammer, doesn’t mean he should. To use a hammer properly one must know its purpose, the right applications for its use, and develop the proper motor skills and coordination to use it effectively. Without that knowledge in place, things just get smashed.

CI is no different. It is a tool used by developers. Developers must know how to employ it as it is a practice. They must change the way they work and change their habits. This is hard enough to do for a small scrum team without the proper coaching. Attempting to implement it at scale without the proper coaching is pretty near impossible.

The six year old may be able to pick up the hammer, but that doesn’t make him or her a carpenter. It just makes them dangerous.

We can talk about CD on another day. I think we should concentrate on nailing CI first.  

Wednesday, October 25, 2017

Sprint Zero - some just can't let go of the Waterfall Mindset

Sprint Zero is NOT a part of Scrum. You will not find it in the Scrum Guide or any Scrum Certification Course. Sprint Zero is an anti-pattern.

So where did it come from? People that have little understanding of Scrum but LOTS of Waterfall experience must have come up with this term.

A “Sprint 0” clearly does not deliver a potentially releasable product. In fact it perpetuates the Waterfall mindset of Big Up Front Analysis and Planning. It is almost identical to what most of us remember as “gathering requirements” before a project.  I cannot emphasize enough how “anti-agile” this concept is.  Does that mean we don’t put together a Product Vision and a backlog before we start Sprinting? No. Of course not. But we do it BEFORE we start Sprinting. If we want to eliminate the waterfall mindset, we need to start by eliminating the concept of a “planning Sprint” or a Sprint 0. Plan all you want. Just don’t call it a “Sprint”. Clearly, it is not. Don’t just take my word for it, you can consult Mike Cohn, the Scrum Alliance,  Alex Ballarin Latre, and the Scrum Guide.


The heart of Scrum is a Sprint, a time-box of one month or less during which a 'Done', usable, and potentially releasable product Increment is created.” - Scrum Guide 

A Sprint 0 is the name often given to a short effort to create a vision and a rough product backlog which allows creating an estimation of a product release… that activity does not meet the definition of a Sprint in Scrum, so it is better not to call it so.” - Alex Ballarin Latre

“Sprint zero is usually claimed as necessary because there are things that need to be done before a Scrum project can start. For example, a team needs to be assembled. That may involve hiring or moving people onto the project. Sometimes there is hardware to acquire or at least set up. Many projects argue for the need to write an initial product backlog (even if just at a high level) during a sprint zero.
One of the biggest problems with having a sprint zero is that it establishes a precedent that there are certain sprints or sprint types that have unique rules. Teams doing a sprint zero, for example, will dispense with the idea of having something potentially shippable at the end of that sprint. How can they have something potentially shippable after all if the goal of the sprint is to assemble the team that will develop the product?” – Mike Cohn, https://www.mountaingoatsoftware.com/blog/sprint-zero-a-good-idea-or-not


Some "Reasons" given to justify a Sprint Zero:

[we need some upfront] "planning, product backlog setup, and design. This is my favorite, as it clearly indicates two things:
  1. Someone is finding it hard to move away from Waterfall.
  2. The organization is finding it difficult to give up control and empower the team.
Introducing a long Sprint Zero at the start and a long validation at the end helps keep the love for Waterfall alive. In addition, it hinders the effectiveness of Scrum.
If Waterfall works for you, then by all means, you should use Waterfall. This article focuses on teams that follow the Scrum rituals but keep the Waterfall soul…

planning, product backlog setup, and design is a proxy for "big design up front" (BDF). In Agile we try to stay away from that. Often, an associated symptom will be a very hierarchical organization, thus preventing the Scrum team from being really empowered.
Personnel who are most active in Sprint Zero may be different from those most active in other sprints.
The Sprint Zero leaders will "guide" the team through sprints but may not feel bound by the time and other constraints that the rest of the team has.
This creates a two-level organization instead of the flat one that Scrum promotes. A two-level organization tends to follow a task-assignment and status-reporting culture, instead of a mind-set of ownership and delivering value.
Scrum believes that every sprint should deliver potentially usable value. None of the above Sprint Zero items produce any value for the customer. They cannot be demoed.


In other words, there is no valid reason for a Scrum Team to have a Sprint 0. It is for people who cannot let go of the Waterfall mentality and/or do not fully understand Scrum. As a coach that has been practicing Scrum since 2004, I can tell you there is no need – and plenty of reasons against – creating a “Sprint 0” and calling it Scrum.

Thursday, October 19, 2017

You Just Might Be Waterfall...

  • If you have a "Sprint Zero" that lasts 12 weeks to get a "jump on planning"... You just might be Waterfall.
  • If you have a test team that works a "sprint behind"...
  • If you have a test team that performs all of your regression tests. Manually...
  • If you have an "Agile Project Manager" who drives you to "increase your velocity"...
  • If you have a partially allocated resource on your team...
  • If you have a Technical Lead on your team who is responsible for all decisions regarding software...
  • If your team and the people around your team often use the phrases "but we’re not true agile" or "but we’re not pure agile"...
  • If you plan on completing System, Integration, and Performance Testing in your last four Sprints...
  • If your leadership complains that they need more Status Reporting and they have to know what the "Gap to Green" is...
  • If your daily standup consists of going through all the tickets on your board and giving a progress report on each of them...
  • If your Scrum Master has more than three letters behind his or her name (SPC4, CSP, ICP-ACC, SA4, CSPO, PMPO, PSPO-I, CSM, SASM, PSM-I, PMI-ACP, SSM, TKP, PMP)...
  • If your Release Plan looks like this: Sprint 1-4 Analysis, Sprint 5-8 Design, Sprint 9-15 Coding, Sprint 16 and 17 Test... You just might be Waterfall.
  • If you have a pre-planning meeting to prepare for your planning meeting...  
  • If at any time, anyone ever utters the phrase "steering committee"...  
  • If your teams spends a “Sprint” on estimation...
  • If your “Agile Project Manager” tells you that your estimation (which you wasted a whole "Sprint" developing) “won’t work”...
  • If your dev team members tell you that their stories are done “except for JUNITs”...
  • If your dev team members feel that assertNotNull(someObject) is a comprehensive test...
  • If your testers “have nothing to do” because they are “waiting for the coders to finish” ...
  • If your Product Backlog consists of a long list of technical tasks...
  • If your Product Owner insists on the team performing Release Planning every two weeks...
  • If your “Agile Manager” starts to “grade” individual team members on the number of stories they finish each Sprint...
  • *If your stakeholders start deriding you as a “purist” because you insist they AND the Product Owner attend the Sprint Review...
  • If your PMO…  Wait? You STILL have a PMO..?  You just might be waterfall.
  • But seriously, If your PMO starts looking for “metrics like velocity” to measure teams’ success...
  • If your Enterprise declares that all story points must be normalized... You just might be Waterfall. Or SAFe Certified. (But what’s the difference, really?)
  • Finally, if you think that developing a Big up Front Design, Fixing Scope, Fixing Delivery Date, AND Fixing Dollar cost, to create a software application built by partially allocated resources conducting a series of hand-offs to different teams comprised of geographically dispersed contractors across the globe, and then throwing it all together at the end and believing that it will all work, (pause to breathe here) is a better way of building software... You just might be Waterfall. And live in an alternate reality.