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.
'Sprint' also implies something unsustainable. It suggests that this rate of change is a short-term thing with a defined goal. It does not suggest any broad change in policy.
Don't forget that a sprint is followed by a period of rest and recuperation, i.e. the retrospective and planning period. Only then does the next sprint really begin. So in that sense the metaphor is valid, and you can keep sprinting indefinitely.
I never found the planning period at all restful or recuperative. One of the reasons I'm falling out of love with Scrum is the relentless pressure of sprinting.
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.
> Does anyone see value in the huge emphasis on the "sprint" term?
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.
You are so right about the "cross-functional team including the primary users in the room"
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
In the best of circumstances, sprints are in contrast to marathons. Realisticly, the death march is the point of reference.
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.
You're a perfect fit for government! Object to something meaningless and then make a conflict out of it. We should make a committee to discuss what words to use and then go forward. I'll book a conference room.
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).
>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. :)
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.
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.
"Sprint" and "agile" are googlable. There is a stable body of literature to support a person adopting the terms when communicating about workflow processes...even a person who doesn't agree with their utility has the opportunity to at least know exactly what they are objecting to.
"Project" has a lot of baggage with the audience, and implies a lot of things that the approach here is in contrast to, so would be particularly bad.
"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.
I think they lose a lot of the meaning. And it's not like the government has any aversion to jargon! If we called it a "cyber-sprint" they'd eat it right up.
Agreed, but this wasn't really about Agile methodology as much as the generic notion of fast iteration, which can certainly exist outside a specific agile regimen. From my experience, if your government audience is not already familiar with a piece of jargon, then introducing it risks 1) distracting from what you're actually trying to communicate, 2) giving them a false sense of understanding that will later be unintentionally used as a bludgeon against you or others in some planning meeting (a slightly caricaturish example: "No! Sprints are two days, why are you doing two week sprints!?").
"Sprint" only says the "short-term goal" part (along with "unsustainable pace"). You have to infer the "working session" part from context, and "cross-functional team" isn't even suggested by "sprint". And maybe you could even ditch the "unsustainable pace" part.
My comment is not related to whether or not it is jargon or whether someone is going to confuse this kind of "sprint" with literal running. Perhaps you replied to the wrong comment by mistake, or just have no idea what I'm talking about.
I don't think anyone is going to confuse a "sprint" for literal running. You're going to have to learn the new term just like any other word: either from context or being given a definition.
Not everybody knows what the word "sprint" means in this context. (And it's not entirely a positive connotation-- after all, people can only sprint for so long before they collapse.)
"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.
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.
"It should be something that any clerk can handle and that doesn't become obsolete."
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.
How elitist have we become that the top comment says staff will become confused by the term "sprint" or using Microsoft word, the most ubiquitous document writing software in existence. Would I use it? No. Would I suggest it here? Yes. I mean we are talking about PRINTING a 500 page document and carrying it around so we can't reach for the stars here, but I will grant them 2nd grade english and 5th grade typing proficiency.
Okay, invoking Word vs LaTex automatically makes your argument a straw man. I would have compared word to e.g. Adobe InDesign.
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.
As an aside, how does Ghostscript handle if the original pages aren't letter? I'm wondering if a command like this isn't doing more than it needs to. The way page trees work in the PDF file format, it's pretty easy to just create a new root page tree node that has as a child all the root page tree nodes of the other documents. This would maintain the individual paper size and orientation of each source document. The only "fun" part would be reindexing all the objects as you bring them into the new document.
"As an aside, how does Ghostscript handle if the original pages aren't letter?"
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."
It can perform lots of other functions on pdfs (hence the name!) during the process like setting printing permissions and quality, and performing encryptions.
Actually I think they mean process. Instead of going back between the right people over the course of months with perfect mockups, sign offs, conference calls, etc they were in the same room and shortened or threw out various parts of the process.
How would you describe the typical government worker?
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 should probably have been more descriptive and said "typical US Federal government IT worker". And I would describe a typical USFG IT worker as someone who's OK with lots of process (because otherwise they would likely have a different job). Certainly not all of them, but many (I would venture to say most).
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.
Just so I understand: Over twenty years ago you taught a class on a Microsoft branded "slightly agile process" and you were surprised how resistant people were to the advice of a short-term consultant. From that you've extrapolated that government IT workers are stubborn and stuck in the past.
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.
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?
Not on the technical side. But I would consider that to be almost secondary - I think the important part is demonstrating that you can do this over a span of days and have real, serious improvement; and that the outsiders (18F/GSA) work to build something with the interested organization rather than for.
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.
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.
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)
You could have the same title as a lessons-learned post about the post-mortem into discovering why the time server for an org was 20 years fast, diving into the machine to discover to their horror that some intern modified the time service to think about years, seasons, and months in a very human perspective.
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.
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.
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.
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.