How a two-day sprint moved an agency twenty years forward
18f.gsa.gov
18f.gsa.gov
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.
"Period" doesn't connote activity, just time, so its not a great name for an activity.
"Effort" is a perfectly generic name for an activity, and carries no connotations related to what is special about this activity; even (perhaps especially to those unfamiliar with its use in software development jargon) "sprint" carries connotations of a fast, focused effort over a short time frame, which is quite appropriate here.
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).
"Sprint" connotates a methodology. "Cross functional team" barely describes personnel vaguely.
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. :)
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.
I'm guessing because it's like you said, it encompassing a clearly understanding of what will be happening over the specified time frame.
"Iterations" is definitely more appropriate than the Scrum use of "sprint" for each cycle in a continuous cyclical pattern of development.
OTOH, the "sprint" here was not such a cycle, and is actually something for which "sprint" is a better term than "iteration".
That does not seem to be how it is used in the popular / consultantified version of scrum. Which is the most likely source of hearing it used within context.
For a team using development by marathon changing time scales is likely to increase flexibility and navigation. A team operating in death marches is perhaps in need of change...one of those rare cased where "we must do something and this is something" might be a reasonable approach.
What huge emphasis?
> 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.
Not really: the term is a fairly precise metaphor for exactly what it is (nicely, moreso than the usual use of "sprint" as software development jargon -- if anything, its more confusing to people with experience in development with the use of the term for one in a series of continuous cycles that it would be for the target audience than it would be for people without that experience.)
> 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.
Its used 8 times in the article, and the whole article explains how it works.
> But it's not -- it's just a time period with goals.
Not really; actually a key part was not having concrete goals going in (beyond deliver something that provides value in the timebox given) and defining specific goals by the team as part of the work effort. This actually is an important contrast to lots of other work styles, where a work effort, timeboxed or not, has very specific goals defined by people distant from the work effort before the team is gathered to execute.
> 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.
Arguably, the real win came from having a cross-functional team including the primary users in the room, in a working session, with a clear timebox and the freedom to define goals.
But the piece isn't about presenting conclusions as to why the effort worked, but to provide facts about how the effort was done and that it worked.
Back in 94 I and another developer did a similar RAD/DSDM project for British telecom we delivered in 28 days what had been quoted as taking 2 years by another part of the company.
I recon that that single month I did more for the company than he rest of my 15 year time with BT
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
("gs" is the Ghostscript command.)
"Source --> PDF --> docx --> HTML --> json" is just nuts.
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.
This is an important statement. in that it is a reasonable goal, but nearly impossible.
Even using word, once one gets past a simple document, and starts having TOC, index, etc. and is "four five-inch binders" full of pages, then not just ANY CLERK will be able to maintain the document.
It has been my experience that while almost everybody can create a passable document in Word, something technical/government-ish with 500 pages and all of the publishing accouterments that come with a document of size, purpose, and complexity, you're getting into specialist territory, and almost all of the DTP specialists I know start by importing Word files in to InDesign.
This reads like someone who doesn't have an understanding of the enormous power that word has hiding under it's shell.
I have no idea. Most of the PDFs I deal with happen to be letter. I found that command a few years ago and haven't bothered to investigate further, since it suits my purposes most of the time.
"I'm wondering if a command like this isn't doing more than it needs to."
I wouldn't be at all surprised.
pdfunite *.pdf ALL.pdf(But older versions of poppler-utils don't include pdfunite, so the "gs" solution might still be useful.)
pdftk *.pdf cat output combined.pdf
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!
What characteristics would you ascribe as 'typical' among the nearly 2,800,000 federal government employees? What do think of the engineers at NASA? The biologists and mathematicians working on the human genome project? What character traits do you think are shared by Park Rangers fighting fires and educating people about the value of wilderness in Yosemite, and FBI Agents working undercover to investigate organized crime?
I'm genuinely curious.
And I speak with some experience here. In the early 90's I taught a class about Microsoft Solutions Framework to a group of government IT people, and they were less than thrilled to have to learn a new way of doing things. MSF is a slightly agile process, more so than many others at the time, nothing like XP or even Scrum though. They had been using a waterfall process for a long time and were just fine with it.
While one class doesn't automatically mean that everyone in government IT is that way, from my experience in consulting with several government agencies and other large companies, there are a lot of people who don't want to change. I think that many people who have never had to work in that environment don't realize how it is, certainly nothing like a startup - and I've also worked at a startup in the past as well.
Got it.
Process is the biggest issue not people.
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.
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)
If "it" is part of the core work of the agency, shouldn't that agency learn "how to fish" and develop that capability?
By comparison, I'd imagine the standard gov process is something more like:
* decide something needs improvement
* create spec as far as what they want (weeks)
* find contractor to implement that meets all rules/reqs (weeks)
* pass specs to contractor, contractor builds product (weeks)
* get finished product that doesn't work very well because spec was created in a vacuum and contractor didn't discuss issues unless they were game-breaking
I feel like the emphasis here is more on process improvement rather than the end result.
Of course, now they have two versions to be kept in sync. But that was a "non-goal", so it's not their problem.
:p
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?)
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.
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.