
How a two-day sprint moved an agency twenty years forward - danso
https://18f.gsa.gov/2015/09/09/how-a-two-day-spring-moved-an-agency-twenty-years-forward/
======
kzhahou
Does anyone see value in the huge emphasis on the "sprint" term? Advocates
promote the word as a new way of working, but I see it as just adding
confusion for the audience it's trying to reach. That is, if I'm a person
entrenched in government and want to learn about this new way people are
working, and I see the word SPRINT everywhere, I might assume it's some
complex new idea. But it's not -- it's just a time period with goals. Those
have existed forever.

The real win in this short project came from having a cross-functional team in
the room, in a working session with a clear short-term goal. So just say that.

~~~
sp332
Why would you say that whole sentence when you can just say "sprint"?

~~~
kzhahou
Sprint is jargon and jargon alienates newcomers. One of the goals of this team
is to teach the government a new way of working.

The article title would be much better as:

> "How a two-day cross-functional team moved an agency twenty years forward"

I'll go even further and say that Agile terminology should be avoided as much
as possible, as we have already seen it corrupted into anti-Agile in the
enterprise. Stick to the basics (short work cycles, cross-functional teams,
clear explicit goals, quick constant feedback, etc) and a new organization
will better maintain the true intent of Agile, rather than mindlessly cargo-
culting the structures (sprint, iterations, agile team, scrum board, etc).

~~~
justinkramp
>as we have already seen it corrupted into anti-Agile in the enterprise

I've definitely experienced this. A large waterfall development group decides
to call themselves Agile. They start proclaiming their mutant fast-waterfall
as the One True Agile, adopting terms and structures to appear Agile.

Then you get invited to the hour-long "standups" attended by dozens of un-
involved people, "stories" that amount to poorly worded system requirements,
"grooming sessions" filled with chickens and "sprints" with
development/release cycles that look oddly similar to what we had before they
started calling themselves Agile.

It's just a rapid waterfall. Call it "rapid waterfall," or just keep calling
it "waterfall" and increase your velocity. It confuses things when people that
have worked in Agile shops come around and try to understand what you're
doing.

Sidenote - I'd probably title the article "How a ten-person team moved a
government agency forward twenty years in two days."

The permalink says "spring" so "sprint" is an improvement on the draft title
anyhow. :)

~~~
tbrownaw
But despite the piled-on bogosity, it still achieves some measure of
incremental development. And because of this, it also achieve some measure of
flexibility.

Which are two of the main benefits of Agile (the third being efficiency due to
process refinement).

So as far as enterprisey stuff goes, it's really not that (relatively) bad.

~~~
justinkramp
You're right, it's not that bad from a delivery perspective. We're getting
some stuff faster than before. To some degree my frustration is in the
semantics. It does get practical when bringing someone onboard who has worked
in a traditional Agile shop and it's like re-learning everything to figure out
what we're doing.

------
_kst_
"The handbook consists of four five-inch-thick binders containing printed and
photocopied pages. These binders are replicated and distributed across
numerous regional and local offices. The handbook also exists as online PDFs,
where each chapter or subsection is published as its own PDF. With these two
options, investigators don’t have an easy way to quickly access and search for
much-needed information that helps them complete investigations, particularly
when they’re working out in the field."

If I were working in that environment, I'd concatenate the multiple PDFs into
one so I could search the entire set from any PDF reader. It's probably not as
convenient as a web interface with a more sophisticated search facility, but
it solves _part_ of the problem fairly quickly.

To concatenate multiple PDFs:

    
    
        gs -q -sPAPERSIZE=letter -dNOPAUSE -dBATCH - \
           sDEVICE=pdfwrite -sOutputFile=ALL.pdf *.pdf
    

Adjust the paper size and the order of the input files to taste.

("gs" is the Ghostscript command.)

~~~
Splines
Longer term the team should track down where those PDFs are coming from.

"Source --> PDF --> docx --> HTML --> json" is just nuts.

~~~
dublinben
>Coming into the sprint, we understood that one of the major constraints is
that the handbook is created and maintained using Microsoft Word.

It's likely that the original source for the PDF/paper copies was lost. This
necessitated the process of using OCR to get it into Word.

Obviously maintaining such a large and important piece of documentation in
Word is wrong, but that's apparently how it's being done.

~~~
bwilliams18
I think word is actually one of the better tools to do this.

This reads like someone who doesn't have an understanding of the enormous
power that word has hiding under it's shell.

~~~
Splines
Recent versions of Word can also import PDFs, which is useful in a pinch. I
think it would have been a good fit for replacing OCR here.

~~~
ekimekim
Note that some PDFs contain actual text and markup, and can be imported
natively. But others (eg. ones that came from a scanner) are nothing but an
image of each page. Such images require some kind of OCR to turn into text,
which I doubt Word's built in import will do.

------
jbob2000
"Over these two days we demonstrated that with the right support and the right
people in the room..."

That's the solution, full stop. The right support and the right people. A
"sprint" is just a mechanism, it's useless without the right people.

So maybe that's the problem the government has? It's not the process, it's the
people!

~~~
dangerlibrary
What? Everyone in this room works for the government. 18F is a government
project - an arm of the General Services Administration (GSA).

~~~
bdavisx
Yes, but they were from the 18f team, not exactly representative of the
typical government worker.

~~~
whoiskevin
Replace "government" with "Apple", "HP", "Google", "Cisco", or "other big
company" and it still works.

Process is the biggest issue not people.

~~~
devonkim
The process of changing that process itself is what is completely different
between public sector and private sector though. Change from within is
extremely tough to begin with and companies with truly bad, inefficient
processes will likely be out-innovated by companies that can actually organize
to deliver results and that doesn't happen in the DC bureaucracy culture, you
just get less funding and your agency starts to look ancient and obsolete. For
tech companies that become obsolete, they become more sales culture driven and
tend to stick with non-tech customers in the F500 that are even further behind
technology / process improvement curves.

The kinds of folks that stay at jobs for 20+ years and retire are very, very
different from the HN style job hopping motivated go-getters and it impacts
work output drastically in large numbers. DC has a lot of the really motivated
types, but they are oftentimes not doing the tech work.

I've been a federal employee, contractor, employee of F500 companies, small
regional company, two-person start-up, and start-up employee for some frame of
reference.

------
irl_zebra
This is cool. It looks like the end result took the pdf chapters and made them
searchable and in html form, which is a big improvement. Is there more to it
than that that I'm missing?

~~~
dublinben
The end result isn't the end at all, but just the beginning of a more
comprehensive system. This was just a proof-of-concept to show that something
like this was possible.

~~~
DannyBee
So, that part has been known for years, and in fact, IMHO, part of the problem
(with no offense meant) has been that many orgs provide proof of concepts to
agencies or as part of sprints, etc, but in the end, the agencies really want
someone _who helps them maintain it forever_.

They want someone there to hold their hand and help make it work, forever. Not
someone who shows them what the future looks like, does a little work, and
then says "welp, gotta run, have fun building it!". Because then the agencies
go back to their multi-million dollar consulting contracts, and end up with
what they got in the first place: Someone selling them 20+ year old technology
at a high price.

(Sorry, i spent way too long in DC watching this kind of thing happen
repeatedly)

~~~
wslack
> They want someone there to hold their hand and help make it work, forever.

If "it" is part of the core work of the agency, shouldn't that agency learn
"how to fish" and develop that capability?

------
Domenic_S
URL typos are forever: how-a-two-day- _spring_

~~~
mojuba
I first read the title as "two day sprintf". Need a little rest definitely...

------
Beltiras
That's somewhat of a plum project thou. I'm amazed that stuff like this is
still printed out for reference [shudder].

------
revelation
How are people that work "often literally (sic) in the field", presumably
without stable internet access, be best served with a web app running
ElasticSearch?

This is the kind of solution you get when you go into a problem planning to do
some web app thing. It leads to an implementation that includes people
slapping on a "Word -> HTML" conversion with not a thought given to the
massive technical debt and complexity you are incurring there.

(Presumably, these PDFs come from somewhere?)

------
iamleppert
Umm, they took a bunch of PDFs and combined them together in two days?

~~~
bglazer
That's a super dismissive point of view.

Here's another: Working with a government office with zero technical expertise
they setup elastic search and converted hundreds of pages of Word documents
into a searchable, well designed form and saved government workers hundreds of
man-hours of fruitless searching. This process, in and of itself, was useful
to show the agency how technical change can be executed quickly and
successfully.

~~~
djcapelis
You're correct. That is a much more buzzwordy way to say they combined a bunch
of PDFs in two days.

The real point both of you are touching on is the surprising part of this
story has nothing to do with the technology. It's perfectly reasonable to have
accomplished a prototype like this in two days. The big thing here is in how
they overcame the entirely non-technical obstacles to do it.

I think there's probably two main things they did right:

* They selected an achievable project with immediate high impact on the organization's day to day work.

* They had the reputation, credibility and positioning required to make sure that their project didn't get bogged down by procedure or requirements imposed by external forces.

As it turns out, these two things are some of the most important ingredients
for affecting change with software and are relevant to nearly all teams. Many
teams only get one of the two. Sometimes you get none.

