Stakeholders weren’t really sure how ratings would work, but at least for now they were okay with saying an item’s rating could be based on the total of the ratings of all descendant records.

I’m not positive that’s the best idea, but it’s a reasonable one anyway. If your comment spawns a tree of comments-upon-comments that overall garner some high ratings, that may suggest your comment was pretty interesting. By the way, in this application you can have Comments, Questions, and Answers, as well as uploads of PDFs, video, and the like. They’re all interspersed in the Conversation tree. They can all get ratings.

The glaringly obvious solution

Well, you’d read a main record, then all its child records, then all of those records’ children, and so on. “But,” said our star Ruby guy, “that’s not gonna work.”

Rather, he went on,  what if we cached some intermediate results along with something like a cache timestamp, and (if I recall correctly, and I’m sorry if I don’t) feed some of the ratings up a level or two as kind of a precalculation. Posting the comment might be a little slower, but at least the ratings display gets a lot quicker in the bargain.

Trying to pull rank and be Mr. Super Agile, I said something like, “Dude, Do The Simplest Thing That Could Possibly Work. DTSTTCPW!” And I suggested we just skip the caching and pull all those rating records on demand–because a tree scan is drop-dead easy to code and doesn’t require a lot of deep thinking.

Also, I have to admit that the other part of my skepticism had to do with my faith in modern database engines. We hadn’t even chosen a production platform, but something like Oracle can optimize the heck out of a massive self-join operation. Why optimize it in Ruby code if the database knows best?

Our developer shot back: “But that can’t possibly work! You’re forgetting the W part!”

It’s not “Do The Simplest Thing,” full stop.

It has to be the simplest thing that could actually possibly work. And our guy was saying my admittedly oversimplified implementation concept couldn’t. Which brought me back to the idea of iterative releases.

Remember I said this isn’t a Scrum shop?

Well, it’s not. That means we don’t have Scrum Planning meetings, we don’t have Scrum Retrospective meetings, and we don’t have a true Scrum-style product backlog. And we don’t have a release at the end of each sprint, because there are no sprints.

There are intermediate development milestones though. When the star Ruby guy brought up the definition of “working” I went “Aha!” because he was thinking in terms of a completed, rolled-out, popular, busy website. When you have thousands of active users, caching queries can be important. I, on the contrary, was thinking in terms of iterations, and this iteration was going to be used by… like four people maybe. And query speed wasn’t their main momentary concern. And they might have come up with a totally different rating algorithm that would invalidate the caching strategy.

I don’t know. I’m not saying that throwing together something slow and crummy is “good enough” just because it’s a limited demo situation. On the other hand, I’m nervous about anything that smacks of premature optimization. But when you’re trying to do the simplest thing that could possibly work, it’s important to know what you mean by “working.” And I guess it’s important to guage how much the project is likely to change after the next iteration.

Where do you draw the line between slapdash and overkill? Is it an iteration thing? What do you consider “working” when doing the simplest thing?

• #101: “I want to be able to comment on a comment.”
• #102: “I want to be able to post a question in response to a comment.”
• #103: “I want to be able to post a comment or a question.”
• #104: “I want to be able to post an answer to a question.”
• #105: “I want to be able to comment on the conversation as a whole.”

This is oversimplified and (only very slightly) dramatized, but you see the overlap and the potential for confusion. These story cards are blocking a ton of other work that needs to be done in the next couple of weeks. And they’ve been claimed by different developers!

How did that happen?

Let’s see. Many of our team members are part-time, and by that I mean they tend to work nights and weekends. Not all the same nights and weekends.

The project’s “marketing guy” isn’t that familiar with the story card concept, but he’s the one with his hands on the requirements, so he writes most of the cards. There’s an extra level of indirection there, because I don’t get to talk to some of the primary stakeholders, and things can get lost or duplicated in translation.

I’m more of a Scrum person myself, so I’m not that good at enforcing story-card-writing discipline in a KanBan environment.

And a couple of our sharpest Rails people just joined the team recently; they’re making significant (very well thought) changes in the data models, but the rest of us are a little slow to catch up.

If it’s not one thing, it’s everything.

We went through about a week of finely parsing where Alice would implement the regular comment because it was on her card, but Bob would implement comment-on-a-comment because it was on his card…

Call me dense, but I figured out eventually that when you see a bunch of overlapping cards in a kind of mixed-circular blockage, it’s time to refactor the board.

So that’s what I did.

I posted this on our BaseCamp site the other day:

Just sharing my observations on what is and isn’t done in the whole cluster of [certain story card numbers]:

1. Discovered case sensitivity in Ubuntu (and thus EngineYard) servers when finding partials. You should always :render ‘foo/partialname’, never ‘Foo/partialname’. The Mac OSX platform will forgive you, but staging will not.
2. You get “grayed” text from the jquery placeholder plugin even when you’ve already started to enter text in the textarea.
3. I’m not sure questions are fully implemented.
4. Answers are definitely not implemented.
5. Uploading videos, images, and PDFs–not implemented.
6. Post a comment to a conversation, it shows up nested as a reply to the last added comment.
7. Comments render in an overlapping manner.
8. Not showing user avatars or profile pics, so alt text is always seen.
9. You should be able to comment/question/answer/etc. anywhere in the discussion tree, not just at the end.

It’s really intertwined. These cards overlap like crazy. But this is what it takes to get the whole comment/rating/question/answer/asset thing working and looking good.

Then I started hanging out and pairing more with Kevin, the new guy. He’s new to projects of this size, and I have way more development experience, but he’s also concentrated on Ruby and Rails way more than I have. We worked our way over this list yesterday, refactored a little, implemented a lot, and spotted three more issues that brought the fix list to 12.

(Along with Kevin, I agree that relying too much on JavaScript is a recipe for stress and heartbreak.)

Kevin’s off this weekend, because not all grownups work seven days a week, but I’m on a roll with the remaining six items on the list of twelve. So if it goes well this blockage will be cleared by Monday.

The uptake on this

The KanBan is made for the project. The project is not made for the KanBan. Let’s just refactor this complex blockage into something we can fix, and move on.

A note on process…

…as well as a reminder of today’s Weekly Scrum meeting. I’m notifying everyone (including executives and non-technical managers) because you’re all invited to join today’s meeting as chickens, and because you might be interested in the process summary. If this stuff bores you, sorry about that. [And something about how to turn off the notifications.]

First off, the Scrum will start at 5pm. If other “pigs” will be in the office I will join you, so let me know. But we will also be on Skype (where I’m MarkWSchumann). Other pigs are: [names elided]

If you care to join the Scrum as a chicken (i.e., involved but not committed), that’s fine–let me know and we’ll include you.

End of announcement. Beginning of process talk.

For those newly tuning in or just standing by, the Scrum meeting is really really simple. Everyone in turn answers Three Questions:

1. What did you get done since the last Scrum meeting?
2. What do you plan to do before the next Scrum meeting?
3. What obstacles do you have?

I’m gonna say something here.

The answers to these questions are often a variation on “I screwed up, and this is how I screwed up, and this is how it’s affecting my team.” Let me be clear about one thing: The process doesn’t work if you can’t be totally honest. Okay, two things: People aren’t gonna be totally honest next week if you make them regret this week’s honesty.

So if Alice admits she caused a blockage because she bit off more than she could chew, no fair scolding her about the same exact thing on Monday. She already spilled her guts. Don’t make her do it again. (She’ll wonder why she bothered to suffer that experience the first time if it didn’t count.) And if Bob tells you he botched some code and has to do it all over again, appreciate the fact that he said so. Don’t make it all dramatic. Just help him fix it and move on.

Got it?

And the Scrum should go really quickly–maybe about three minutes per pig I guess. And zero minutes per chicken, because chickens don’t get to talk in Scrum meetings. If an obstacle can’t be resolved instantly, we take it out of the meeting to talk about later.

This is not really a Scrum shop.

That’s been implicit all along, but now I’m actually saying it.

Scrum has burndown charts and a different kind of backlog system and an explicit kind of connection to management, among other things. We don’t need those. I think.

We’re more of a Kanban shop that has Scrum-like meetings. Which a lot of teams do.

I’m gonna draw everyone’s attention to the online Kanban system we have at AgileZen: [url elided] If you don’t have access to this, you should. I don’t care if you’re technically on the dev team or not–there is really one team here, and in a face-to-face workplace the Kanban would be an actual physical board placed where everyone can see it.

If you want to know why the heck stuff isn’t getting done, this would be the first place to look. That’s the transparency thing.

Very briefly, each “card” is supposed to move from the (sometimes hidden) Backlog column at way left, through the various columns, and into the (sometimes hidden) Archive column at way right. Cards edged in green are Ready to be pulled to the right. Cards edged in red are Blocked and need help.

I encourage everyone on the dev team to watch for Blocked cards throughout the board. You can often help with one that’s not currently in your own primary area of work.

I was doing this Clipper-on-Unix project (yes!) in 1996. It was a really big deal. The idea was to migrate a rather large vertical application from FoxPro on SCO Xenix (doesn’t that make you smile already?) to FlagShip on Linux. We would add a few major features, mainly interfaces to credit cards and some application-specific hardware. We had a few months to do it, and I was the only Clipper guy. (And by the way, can I just say that FlagShip itself was all kinds of awesome?)

By “we” I mean I was subcontracting this work. I was being paid by the vertical systems vendor, not the end client. Very important point.

One part of the specification was “interface to the Central Registration System.” This software was going to be in a few hundred locations, and every location had to run real-time-ish transactions into the Central Registration System (CRS). So it had to work over modem lines (remember the timeframe here) and with reasonable speed. The client supplied fairly good interface specs too. This looked really hard, but on the other hand our existing vertical product only supported a slice of CRS functionality anyway, like 10%. So the “interface” part of it would be only 10% too. Right?

We flew out to the client headquarters to show off the nearly-completed application. There was a horrible, horrible problem in my modem-specific code–something to do with sign extension in C!–but I solved that in the hotel room around 4:00 a.m. the day of the demo.

But then…

…one of the acceptance testers said something about not being able to perform a certain operation on our software, that the CRS had an interface for.

I was surprised. Very surprised. The spec called for a straight port, plus Feature A, Feature B, and Feature C. It did not mention Features D through Z. And this operation was definitely in Feature Z territory.

So I said, more or less, “That’s Feature Z. We don’t have Feature Z.”

And the client said, “It’s part of the CRS interface!”

Obviously we’re unclear on what an “interface” is.

I think it’s pretty clear that an “interface” is a connection between systems. If my application doesn’t create widgets, and the “interface” spec says, “If you’re creating widgets, here’s the transaction you have to send,” then my response is “We’re good here. There is no widget creation.”

The client took it to mean our application is supposed to make widgets now. And it didn’t.

The vertical system vendor, facing a disappointed client on one side–a really big disappointed client–and overworked me on the other side, figured it made more sense to blame overworked me for not implementing the widget creator code.

Let’s get this straight.

I’d brought this up in conference calls a couple of months previously. “Hey Management Guy,” I said when reviewing the interface spec, “There’s this whole section on Widget Creation Messages. Our app doesn’t do that. How would you like us to handle the interface on that?”

And the Management Guy said, “Then that doesn’t apply to you.”

All righty then! I didn’t give it much thought after that. Over the succeeding months, when we made progress calls with various client personnel, the Widget Creation feature never came up. They knew we didn’t do Widgets.

But then we showed up. Not for the first time.

With the application. Also not for the first time.

And that time the lack of Widget Creation was an issue.

My point, and I do have one.

I might have a few points.

• Maybe it’s write a negative spec. Detail what isn’t in the scope of work in addition to what is.
• Maybe it’s make sure you know who the client is. The “kid” who busted this open was not someone with a lot of rank in the client company. She wasn’t in any of the planning, design, review, or status meetings.
• Maybe it’s do frequent releases. So the client at least has a chance of spotting the discrepancy sooner rather than later.
• Maybe it’s watch your contractual language. This part is what saved me; I made sure the vertical systems vendor warranted that their existing code base already had the required functionality except for Features A, B, and C. You could draw a Venn diagram and show that Feature Z was either the client’s responsibility (because it wasn’t considered “required”) or the vendor’s (because it was “required” and they had “warranted” it) but definitely not mine.
• Maybe it’s keep asking the same questions over and over again. You know what? I have no patience for that. I need to be talking to the decision maker, or someone who has authority to represent the decision maker. If they lack authority to commit, then asking for feature decisions is a clear waste of effort.

So that’s my little horror story for today. Maybe later I’ll fill in the “not letting me refactor” bit of the saga. What a nightmare that was.

I was talking to a client the other day about a thousand things, in the space of half an hour. There were a few things that stung badly, but one of them was to the effect that I wasn’t managing the developers very well.

It’s true…

…that I rarely tell the other guys what to do. I don’t particularly evaluate their work, not in a keeping-score sense anyway. I don’t set up rewards or incentives. I don’t make a Gantt chart. Nobody gets called into my office.

From the outside of things, actually, you wouldn’t even know I was in charge.

Backing up for a moment

At that time, the team was just me and two part-time contributors: one Rails specialist and one User Experience expert who is also pretty good with Rails. They’re highly skilled and have Agile Mind. The UX guy even introduced me to AgileZen, a nice little web application that simulates a real KanBan board.

So… yeah. What’s to manage? There’s a board, you can see it, it has story cards… it’s easy to see blocks and backlogs… you might ask a question once in a while.

If a queue looks light you can either prompt someone to take on more cards (if that makes sense), adjust the queue size (if that makes more sense), or encourage people to work different queues from their usual.

The thing is

In this environment it rarely takes more than a nudge. Strike that, it rarely takes even that. This team really truly does self-organize. At this point they need to continue communicating among themselves and maybe remind me to push my own work to github more frequently.

Does that look like I’m not managing?

Probably.

Would it help if I started handing cards directly to the part-timers and asking for status every day?

It sure would! It would help me feel super-duper important! It would reassure the client that I’m in control! It would reinforce my position!

On the other hand, it wouldn’t get any more work done. It would probably get a lot less done, since sharp developers have a really good sense for what should be worked on next.

I’m sure you’ve seen it

This always happens. The Gantt chart says today you work on Task A, but your brain just isn’t ready to do Task A. You’re in a Task B kind of mood, and you woke up with a really simple algorithm for implementing it.

Classic management says write it down, put it aside, and get cracking on Task A. Agile says pull the Task B card, create some tests for it, write the code, make it build and test out, then mark the card as Ready.

Guess who gets Task B done first?

Guess who will probably actually get Task A done first?

Guess whose hands on the wheel are going to be more effective? Not mine!

KanBan has priorities

You arrange your Story Cards into queues, which are vertical. You move cards from the leftmost (backlog) queue, through whatever steps your process requires, and finally into the rightmost (archive) queue. Cards within a queue carry a priority number.

You don’t push cards to the right when you’re done with them. Nope. You pull cards from the left when you need something to work on!

Sometimes a card has to go backwards because redesign is needed after some code gets added. Sometimes you skip a higher-priority card to pull a lower-priority one because you had an idea, or because it fits the time you have available, or a resource you need to do the higher-priority card is unavailable.

Those are not management decisions. Those are team member decisions.

So in a really well-functioning KanBan system, what the heck does the manager do? By traditional measures, not that much. It’s less Vince Lombardi and more Mary Poppins: giving smart people a goal and letting them figure out how to get there a little bit at a time.

But today I’m re-encountering an issue not on my original list of eight. It’s the one where you can’t possibly fulfill expectations because the client is not your client.

So the other day…

I’m hearing from the client. He says “the clients” are getting kind of nervous about not seeing our running code on the QA server.

Yes, I said that right. The client–this one guy–is referring to “the clients” in third-person plural.

We’d had this discussion before. I’d asked the one guy, like three weeks ago maybe, who specifically is the client. Who is the decision-maker? Who is this for? And at the time he’d said yeah, it was just him.

Okay. Got it. We meet with you only, with talk with you only, we provide updates to you only.

Sure.

I know there are customers behind the customer. That’s fine. You don’t implement projects in a vacuum. They are done for reasons, and those reasons usually have to do with other people. But you still have to have a clear definition of who’s in and who’s not in.

Very briefly, and oversimplified a little, if someone thinks they need access to your QA server they are either part of your team or they are the client. If they are your client they need to be at your standups or represented at your standups. If they are not your client then the project is a black box to them.

It goes like this

One of the awesomest things about the Agile concept is transparency. We’re used to thinking of it in terms of the client seeing what’s going on via wall displays, virtual boards, listening at a Daily Scrum, and so on.

But transparency is inherently a two-way phenomenon! The dev team needs to see the client, preferably face-to-face but directly in any case. Communicating directly is hard enough. Going through the fake client to figure out what the real client wants is… impossible.

What’s beyond impossible? Whatever the word for that is, it applies to doing this all when the identity of the client is in flux depending on how anxious everyone is feeling.

See, when there’s transparency one way and not the other way, you don’t call it transparency. It’s like one of those windows they have on cop shows where the lieutenant watches the interrogation but all the suspect sees is a mirror.

My solution

Project owners, you simply have to pick a story. Either the project is yours and you take responsibility for everything behind you, or you have to  bring the actual client into the process. Having invisible clients isn’t playing fair, and it will not get you what you want.

I don’t remember where the proof was supposed to end up, but I had about seven handwritten pages that sort of got me there. Not quite.

Professor Adelberg, sitting by my side at his desk, said, “Look, this is a 200-level class.” He paused slightly. “There are no seven-page proofs in a 200-level class.”

In this class, he said, you know you’re on the wrong track if your proof is more than about two pages. It’s a class full of people maybe a year and a half out of high school; we’re simply not at the level where theory gets that heavy.

Why am I telling you this?

I don’t remember very much in differential equations–I’ve always been more of a finite math and number theory kind of guy–but I remember that encounter because the lesson is always fresh. An answer that’s too hard is likely to be the wrong answer.

This morning, I had coffee with my homeboy Joe Fiorini, as a high-level pairing exercise. He was kind of busy, so we only hung out for about 45 minutes, which turned out to be an advantage. I’d been poking around at this JavaScript code for a day or so. All it had to do was maintain an array of user-selected IDs from a database table, show an HTML DIV of the IDs already selected along with descriptive data, open an HTML DIV to show a picklist of those not already taken, and let the user add the selection of another item, by choosing it from the picklist.

Its a “200-level class” sort of problem, isn’t it? But wow… I was cranking out that seven-page proof. Initializing the array. Refreshing the DIVs. Embedding links as A tags into the generated HTML. Making Ajax calls to repopulate the list in case it changed. I was getting a lot of mileage out of Firebug, which is never a good sign.

That’s about when Joe walked into the coffee joint.

I told Joe the story about Adelberg and the seven-page proof.

Joe said, “Let’s step back a minute. This is all in an HTML FORM, right? Why don’t you keep a hidden INPUT field containing the record ID in each LI? Then your array is right there. Not in the JavaScript.”

While I sat there flapping my face like a fish, because of course Joe was right, he went on: “And since this is a many-to-many relationship, you can set the NAME of that hidden field by convention to let Rails save it automatically to the join table.”

Which makes my Model logic drop-dead simple. It might even work by default. 130 lines of JavaScript will probably get cut down to a couple dozen.

Professor Adelberg, meet Joe Fiorini.

How it came together

Mark tells one of THOSE stories

You know this saying?

It is amazing how much you can accomplish when it doesn’t matter who gets the credit.

Organizing GiveCamp was like that. I was the nominal Leader of our semi-formal organizing committe, but I always cringe when saying that. Jon Stahl was the de facto leader, at least in part, because a) he’s organized big events before; b) he’s hooked up with the larger GiveCamp movement; c) he took charge of a huge portion of the logistical details; and d) it’s his boat. I’m not remotely comfortable giving orders or even strong suggestions, so it was often hard for people to tell it was “my” event. To me, “leading” stuff looks more like finding out what people need and connecting them. It’s a middle child thing.

Based on the capacity of the LeanDog boat, the organizing committee figured that 75 volunteers would be an ideal number. Working back from that, given an average of five volunteers per team, we thought it would be good to do projects for fifteen local nonprofit organizations.

Those goals turned out to be challenging. We didn’t have a surplus of applications for help from nonprofits, and while it seemed that we’d probably reach our volunteer goal we didn’t expect to go very much beyond it.

Then Margaret Bernstein visited the boat, and this article hit the Plain Dealer. Within a week, the requests came in by the dozens and we eventually received sixty-eight. About 130 volunteers registered in advance. I openly asked my fellow organizers, “How many volunteers is too many?” After all, that was nearly doubling the capacity of the boat.

And it’s a boat. It can sink.

That’s when Jon asked about using the terminal at Burke Lakefront Airport, which is less than fifty yards from where the LeanDog boat is moored. Burke said okay, and we became a two-site gathering.

Who did what

Among many, many other things that got done by other organizers:

• Andy Craze went to a zillion user group meetings to recruit volunteers, and assigned them to teams a day or two before the event;
• Larry Mingle made the Cleveland GiveCamp website;
• Matt Beyer collated all the volunteer registrations;
• Trish Rouru networked with many of our nonprofit partners, solicited food donations, and (together with Deb Stahl and Jane Winik) prepared all the meals;
• Sam Nasr served as our Sponsorship Coordinator; and
• Nick Barendt set up our fiscal sponsorship with IEEE Cleveland, talked to media people, and took care of many, many site details.

In summarizing like this I am leaving people out, and minimizing the accomplishments of those I did include. It really is amazing how much work goes into an event like this, and in the heat of getting things done it’s hard to remember who did what.

While they were not part of the organizing team, I especially want to pick out two other volunteers:

• On Friday night, Amy Wong told me she was available to help write website copy for any and all nonprofits. Amy was busy all weekend with this. I think her words are on at least half the websites we did.
• Also on Friday night, Heidi Cool (who was there as part of our social media team) foolishly reminded me that she can help with WordPress and design issues. We ended up doing about fifteen WordPress sites! Heidi was incredibly in demand. She also taught an hour-long seminar on WordPress content management for our nonprofit partners on Sunday.

What got done

Bottom line:

• We took on twenty-two projects in software and website development.
• Twenty of them were successfully completed during GiveCamp weekend.
• All the nonprofit clients got training on using and maintaining their new software and websites.

That makes Cleveland’s the largest and most successful first-time GiveCamp. Anywhere. Ever.

Retrospective

Jim Gorjup solicited “retrospective” notes from all the volunteers and nonprofits. We wanted to know what worked really well, what could have been better, and what really sucked about this year’s event. Mostly, I took these handwritten scraps and passed them right along to Jim so he could collate them and talk about the themes, but one line got my attention. It went something like this, approximate quote:

I liked the way everyone cooperated and shifted from team to team as needed.

This was particularly evident when a scheduling application for the Richmond Heights Fire Department looked like it wasn’t going to get done. Jon–being pretty much the King of Agile around here–collected what we called the “rockstar team” of Ruby developers who were done with (or could be borrowed from) their other projects and prompted them to self-organize. The upshot, unfortunately, was that the project simply couldn’t be completed in a weekend. It was just too ambitious, and since the project was a last-minute addition to our lineup it was hard to know that ahead of time.

I count that as a win for the Agile concept. At least we were able to conclude that project wasn’t going to go, which gave us permission to drop it (for now) and reallocate our developers to something that had a better chance.

What’s next

In my closing remarks to the assembled GiveCamp community, I referred to “next year” even though there weren’t any specific plans to do this again. I caught myself and asked, “Wait, who wants to do this again next year?” I’d say the response was strongly in the affirmative. So we’re on for next year.

Which reminds me. There is still time to contribute cash for next year’s event!

My idea was something like this: “Tell me about a time something broke, how you felt about it, how you tried to fix it, and what the result was.” You may recognize this as “behavioral interviewing,” which I learned a little bit about in my very first job after college.

Just between you and me, I’m not personally sure of how well this technique works to identify the best candidates or whether it gets a working relationship off to a good start. It’s not like I’ve done enough sustained interviewing and hiring to pick out a trend.

But it makes sense to me. You ask a question like this because:

• It forces the candidate to be specific. Instead of saying “I’m good under pressure,” she has to talk about what kind of pressure and what “good” meant in those circumstances.
• Examples from real life are so much more compelling and detailed than things you might have done or think you might try.
• It’s a reality check. As the link above states, “It is very difficult to make up behavioral stories.” Even if the candidate succeeds in snowing you on this account, at the very least she’s displayed some imagination and enough knowledge to simulate the claimed experience. Which is actually not a bad thing.
• It especially gets at the candidate’s problem-solving ability, which is a high priority when hiring a network administrator. It’s the kind of job where adaptability trumps theory.
• And have you ever known a really outstanding network admin who crumples under pressure? You want at least anecdotal proof of resilience.

So if I could ask a candidate just one question, that would be the one. How about you? What have been your favorite questions, from either side of the table? If a candidate, what questions do you wish you’ve been asked?

Wow, I do weekend things on a weekend, come back to the computer, and there’s all this action.

What’s this about needing something done by end of month? I’m pretty sure [name elided] already handled the demo, which is why those cards are in archive. If there’s something I’m supposed to do by month’s end, there should be a card for it in the backlog. And the progress of cards is how you know things are getting done. If I’m doing things that aren’t on the cards, the funders are going to ask what the hell I’ve been doing. And I won’t have a good answer for that.

A decision is made to do something when a card gets added to the backlog. If it’s not in the backlog, the decision to do it hasn’t really been made. Among many other reasons, this is necessary because it keeps the project owner from making half-assed decisions. You either have to do it, and add points to the project, or admit that it’s not really on the agenda. You can’t pester the team to do stuff that’s not in the backlog and then hold them responsible for the backlog not getting done.

Bottom line: Agile is the exact opposite of doing whatever the hell you feel like. It’s very disciplined even though it looks informal. It will absolutely not work if you keep trying to circumvent it or make it be something else.