In practice, most places I've worked treats sprints much closer to how you describe your iterations than to a fixed amount of work.

Most of the time, the sprint planning just provides some ceremony around ensuring important stories are discussed and points allocated, and priorities set, and the planned sprint is pretty much a line in the backlog that suggests an aspirational goal that is likely to change. The point is rarely to hit exactly that, but for it to serve as a means of talking about what needs to be done first - whether something needs to fit into this round, or can wait for the next. It also serves as a means of talking about inter-dependencies and sequencing of changes.

I think you've been lucky in where you have worked. You read some of the other responses and it isn't the case at all. I've seen some really tragic examples.

Pivotal has 3 regular meetings: daily morning standup (short), iteration planning (monday), retrospective (friday).

Any new stories during the week that haven't been pointed get pointed in the morning meeting.

Maybe. But the point is that there isn't really that kind of sharp delineation, but a spectrum where you really can't assume that people talking about "sprints" means a fixed amount of work.

The process you describe fits precisely within the Scrum framework; a key point of the retrospective in Scrum is not just to understand what has been delivered but what caused deviation from the estimate at the start and why. The assumption throughout is that the forecast from planning is just a forecast and that what will be delivered will pretty much never be exactly that.

Maybe there are other things you do that does not match Scrum, but the above fits Scrum better than attempting to turn it into static/fixed releases - after all the entire point of pretty much all iterative development processes is the acknowledgement that we do not know how to precisely estimate software development with sufficient accuracy to create precise estimates for specific sets of tasks.

If you want to put a name on it, Pivotal is just a type of scrum. They have their own sauce. I personally called it the Pivotal Process... but I'm probably the only one.

At Pivotal, the forecast of what will be delivered changes all the time and it is tracked in a single tool that everyone can look at and keep up to date with (along with a few short meetings to keep everyone on the same page).

> They have their own sauce. I personally called it the Pivotal Process

What Pivotal does is fairly vanilla Extreme Programming. Indeed, the vanillaness of it is something of a selling point. In the London office, we would start projects by giving client PMs and programmers a copy of Extreme Programming Explained and telling them that was what we were going to do. It's easier to coax them into following a process if it's a documented industry-standard one rather than some special sauce.

Pivotal does have a few extra bells and whistles that fill in spaces around the XP core - "discovery and framing" [1] and "inception" [2] being two that spring to mind. And as you say, there is less emphasis on iterations as a unit of work - the planning meeting is weekly, but it feeds a continuous flow of development and delivery. But the daily pattern of work should be familiar to anyone who knows XP.

[1] https://content.pivotal.io/blog/what-we-did-on-our-summer-in...

[2] https://www.infoq.com/articles/project-inception-meeting/

I was told that the main thing that makes Scrum Scrum is that the team chooses the sprint goal, from amongst the tickets at the top of the backlog, and the team commits to hitting that goal.

In my experience more typical is that the PM chooses a set of tickets and asks the team whether they can commit to them.

According to the constraint above, neither that, nor the “pick from the backlog” process you’re describing would qualify as “Scrum”.

I doubt it’s luck. In every place I’ve ever seen Agile in use, they treated 2-week sprints like you describe iterations. It was generally expected that portions of stories would roll into the following sprint and there was a high degree of trust and autonomy in letting teams organically decide if & when any stricter deadline needed to be imposed.

One week sprints are also fine, but I’ve always found everyone hates them for doubling the number of planning / backlog / etc. “process” meetings.

One month is often too infrequent for these meetings, one week is too frequent, so 2-week sprints appear from this sort of naturally. As long as you don’t conflate the timing of the sprint with the timing of work tasks (eg accept there are single work tasks that cannot be chopped up into two week incremental subtasks) this seems fine.

The problem I've seen over and over again, and others have mentioned here in this great thread, is that when you have a 2 week sprint... if a feature misses the sprint, it is another 2 weeks before anyone sees anything... so now it is a month, which can be really unfortunate.

It gets especially bad if there is a lot of fire fighting happening as well because someone might get pulled off that feature and now the time goes to infinite...

The idea is to try to prevent that type of common delay.

That’s not how I’ve seen it work anywhere. If you do 2 weeks of work and the feature is a few days away, the portion of work that continues into the following sprint is just a few days, and then you see it.

Fire fighting is just as likely to prevent completion in one sprint as the other, so there is no net change in how the effects of context switching for firefighting slow progress.

Of course, restructuring teams and work so that firefighting effects are reduced is always the goal, I’m just saying it doesn’t matter at all in terms of when the arbitrary cadence for syncing and planning are chosen.

We have tried 1, 2, and 4 week iterations. The problem with 1 week was that we didn't feel the planning and retro overhead was worthwhile for such a short amount of work time. 2 weeks was our sweet spot. 4 weeks was just too much time between larger re-orientations.

Sounds more like a sprint than an iteration since iterations are 1 week.

As I mentioned already in the thread, retros are not just about the work... it is a check in on what went good, meh, bad during the week. It can be about anything, not just work. The idea is to have one hour at the end of a week closeout team bonding where anything can get laid out on the table.

Your iterations are 1 week. An iteration could be any length of time. And retros are exactly what you said. During our retros we have talked about iteration length multiple times and tried varying ones. In our retros everything is on the table for discussion, but it sounds like that's not the case at Pivotal.

'Your' is Pivotal. I'm just talking about how they do things and what I learned there.

At Pivotal, an iteration is a week and it doesn't make any sense to make it longer than that. What would a longer than 1 week iteration really be? Are you making them longer only because you don't want as many retros?

I said: "The idea is to have one hour at the end of a week closeout team bonding where anything can get laid out on the table."

You said: "In our retros everything is on the table for discussion, but it sounds like that's not the case at Pivotal."

There is a disconnect somewhere cause I'm pretty sure we are saying the same thing. =)

> At Pivotal, an iteration is a week and it doesn't make any sense to make it longer than that.

It might. For example, if your team is distributed (eg development in the Pivotal office, infrastructure in the client office), you might prefer to have retros once every two weeks, rather than either drag the infrastructure people across town every week or have retros remotely.

On some projects i anchored, we had planning meetings twice a week, because planning went more slowly, relative to development, than usual, due to complexity of features, multiple stakeholders, etc. We still had retros once a week. Was our iteration one week or half a week?

The truth is that iterations don't really exist. You have planning meetings at some frequency. You have retros at some frequency. You have client liaison meetings at some frequency. You may have various other meetings at various other frequencies. Sometimes the frequencies are the same, but it doesn't mean anything.

I came across as argumentative in my first response. I didn't mean to :)

> There is a disconnect somewhere cause I'm pretty sure we are saying the same thing.

Sort of. In our retros everything actually is up for discussion. If people think 1 week iterations may work better for us, we may try them out (and we have). We got rid of daily standups because of a retro discussion (they may come back if we feel communication is lacking). The point is there are no sacred cows.

You already stated a few things that appear set in stone. 1 week iterations, pair programming, daily stand ups, and everyone at the office for the same hours every day. From my standpoint that appears very rigid, and I wonder what there is to talk about in the retro if the development process is static.

Late to the discussion.

Many Pivotal teams hewed closely to the default practices, but not all. The most dogmatic is Pivotal Labs, because its job is to teach the basics. Having a rigid, predictable structure works better to start folks off.

I've seen every sacred cow at Pivotal slaughtered by Pivots and guests, when it was felt that this was the right and effective thing to do.

out of curiosity what value do you see in morning standups? 15 yrs and i still don't see it (i've really tried).

I just asked the same thing because I've had that experience too. I'm curious: are you usually working on things that require close collaboration between team members?

My hunch is that standups are pretty useless on teams where each developer is working on an independent change where there isn't much opportunity to get blocked by teammates aside from waiting for code reviews and the like. That's most of the teams I've worked on, and the standups inevitably turn into a verbal form of, "Hey manager, here's my status report for the day even though you already know all this because I've already said it in Slack," because you have nothing to ask of the other people on the team but you're required to say something every day.

Where I've seen standups work effectively is when an engineer has a bit of context on a problem that someone is dealing with, or an insight that might unblock someone. I've had many times I've mentioned in an (async, written in slack) standup status update, and someone's chimed in with something like "Oh, I've dealt with that before - let's pair for 10 minutes so I can walk you through some gotchas".

Another plus for me personally is that it has a focusing effect on myself as a developer - if I say I'm going to get something done in standup, I'm going to force myself to focus on that task, and not get distracted by something else unless it's really important. I can see how that's a totally personal thing though - I need to have some sort of external "deadline", even if it's self-imposed and soft, to keep me focused.

All of the above can be solved with async updates in Slack though, and that's probably actually a better medium. Having folks get in the same room seems a little pointless to me, especially when you have remote folks and timezones are an issue.

The problem I've had with async updates is that they often get ignored because everyone that could help is busy at the time, so you still need the actual standup to just remind them about it. How do you get around this?

I don't have a great solution for that, really, other than ensuring that updates are highly visible in a room where people are likely to read them and have a good culture around helping folks.

I've been in environments like the one you describe, and I think at the end of the day it's more of a cultural issue than something that can be solved using a tool.

this ^^^^^^^^^^^

I get around it by pinging people directly (usually I reply to my question as a thread in Slack and @-mention them, so the main channel doesn't get cluttered with my reminder) if a couple hours go by without a response. Still usually faster than waiting until the next day to ask at standup.

   My hunch is that standups are pretty useless 
   on teams where each developer is working on 
   an independent change where there isn't much 
   opportunity to get blocked by teammates aside 
   from waiting for code reviews and the like

Personal anecdote, but I like to know what my teammates are working on even if we're not collaborating directly.

I could (and do) read their commits and PRs, and standups are not a replacement for that, but I think you can usually get a better idea just by chatting for a few minutes each day.

I view the cost of a daily standup as very small (they should be only a few minutes long!) so while some would call the benefits modest, I think the "time spent vs. value obtained" ratio is still very good.

For me the cost is much less about, "It's just a few minutes long" and much more about, "Having to get up from my desk and talk to people about their projects kills my flow state." It's a short meeting but it's still a meeting and has the same effect on focused thinking as a longer meeting. Losing focus is totally fine if there's benefit to it, but for standups where I neither learn nor teach anything new, it's all cost and no benefit.

I too like knowing what my teammates are working on, but I already get that from the team's Slack channel where people talk about what they're doing as they do it.

I agree about the frustration of having my flow disrupted, but my like of daily standups is related to my experience that they create an overall reduction in interruptions.

Of course, that's my experience. Others may have had different experiences and I respect that. If you formerly had 0 interruptions per day and now you have 1 interruption per day, that would be frustrating. I would also like to work where you work!

>I view the cost of a daily standup as very small (they should be only a few minutes long!) so while some would call the benefits modest, I think the "time spent vs. value obtained" ratio is still very good.

My problem with a morning standup is that it completely destroys my productivity if I come in early and really get cracking on a problem, then have to stop and task-switch. I'd much rather make it optionally asynchronous.

Yeah, I feel the same way sometimes regarding the timing. I don't think they should be in the morning. The older I get, the more of a morning person I am... that's my productive time.

I personally would rather do those meetings in the early afternoon, like before or after lunchtime.

Pretty sure there are plenty of studies that show early afternoon is our least productive time anyway.

(TBH, and I'm being completely serious here, my ideal schedule would also involve siesta time in the early afternoon)

Standups are for "weakest" devs, to break silo of "I am working on my thing don't bother me".

"weakest" devs - you know not everyone is outspoken and will communicate without issues, new young devs will be afraid to ask an experienced guy. Some experienced guys (also "weak") will be assholes to young devs for asking questions. Just getting team to talk to each other at least once a day is positive. Unless you work only with senior people who are experienced and don't have any issues talking to each other, I would still try to get people to gather for standup.

The best dev on my team is also a very reluctant communicator.

This guy is a beast at getting things done, and is a good communicator once you get him talking. Overall, a joy to work with. However, you do typically have to make the first step. He kinda stays dark without scheduled meetings.

To me the key is to keep the daily standups VERY brief. They help the "reluctant" communicators. And they don't cost the "active" communicators very much time.

I am a fairly "active" communicator myself. I'm gonna spend 15 minutes talking to my freaking team every day anyway. So a brief 10-15 morning standup is no problem at all.

Weaker? Senior? We have something to learn from every one.

Nobody should be an asshole. Nobody should be working alone.

Both of these are great ways to create a really toxic working environment, please don't perpetuate it.

Counterpoint: comment was fine and non-toxic, describing siloing as weak no matter who's doing it is an accurate and a pretty tame criticism, and ensuring that's not happening is indeed the only real point of scheduled daily stand-ups. As long as we're gonna have the term "senior"—and we do have it—I'd abso-friggin'-lutely reserve it for people who can avoid siloing without a formal, daily ritual, and a team of such folks don't need stand-ups. Don't worry about it, ozim.

> Nobody should be an asshole. Nobody should be working alone.

Ozim advocated neither being an asshole nor working alone, so is perpetuating neither. Standups have a place and it's to fight both of those problems, when some ICs on a team can't handle it on their own.

How would you express that thought, to get through to a person I replied to who wrote he has 15 years of experience and he did not see any value in standups?

Do you think he is not a senior person? Is he a bad person for pointing out his years of experience? Maybe I am bad person trying to express in BOLD that there are people with less experience, social anxiety, assholes and we have to work with all those personalities. With strong emphasis that standups are good tool for getting rid of toxic work environment and getting teams together.

I agree that the whole typical 'what did you do yesterday' is indeed lacking value.

The standups are mostly just pointing the stories that need pointing, covering any questions and picking the pairs for the days work (pivotal is 100% pair programming). The meetings can be done within 5-15 minutes at most.

I'm currently living at a yoga retreat center in the mountains of Vietnam. I can see from the practice that the first few minutes of silence is good to clear the mind. I think having standups is a similar good way to start the day with a positive attitude.

I also find value in standups, but the problem is they constrain the team to some daily meeting time. For example, I start work around 6am. A co-worker does morning kid duty and tends to start closer to 10am. There is no good way to start our days at the same time, and there really is no need.

What we have been trialing for awhile is a simple Slack checkin. Everyone reads them when their day starts, and if there are any questions or comments a Slack thread is started from the checkin message. It's worked quite well.

Pivotal solved that by requiring everyone to work the same exact hours. It is a bit military in that regard, but it works for them. You don't get a job there unless you buy into it. Their reasoning is more around their culture of pair programming.

It sounds like you have found a solution that works for your company and that is great! The way I look at it is that as long as we are shipping software around the time when we say we are going to and the quality is high and people aren't killing themselves (weekends) to make it all happen, all good. =)

First off, I'd say that a good daily standup meeting shouldn't be more than 15 minutes. If it's longer than that, you are probably getting bogged down in details that don't belong there.

Let's be generous and call the "real" cost 30 minutes of productivity... 15 minutes for the actual meeting/call, and 15 minutes of context switching cost.

That is 6% of an 8-hour workday. You can still code up to 94% of the time, not bad. And I think it has been shown many times that most developers don't really pound out code for 8 hours per day. We might work 10+ hours per day but it's not necessarily 10+ hours of coding. So I feel the cost of these daily meetings is very small.

What are the benefits?

1. For one thing, it is good to know what the rest of your team is working on and what challenges they are facing. This jogs a lot of useful conversations in my experience, where Developer A turns out to have some experience in the area in which Developer B is stuck. You may be thinking, "good teams communicate and can do this literally any time... why schedule a daily meeting for it?"

Yes. If your team is operating and communicating flawlessly, sure, standups are redundant. However, I've been at this for 22 years and this is not typically the case, and the brief daily meetings are a real upgrade.

2. These meetings help prevent "drive-by shootings." That's what I call it when management randomly stops by your desk and wants to know what you're doing and if you're stuck and wants to see your work in progress. I hate hate hate hate these. I would rather just briefly chat with leadership on a predictable basis. And when I am leadership, I would prefer not to subject my team to these "drive-by shootings." A lot of teams are already paying this cost, which I feel is much greater than the cost of a brief morning standup. Again, if your team is already communicating at a super high level, maybe you don't need standups. I feel this is not the case for a majority of teams.

3. For remote teams, these give folks a chance for some regularly scheduled face time and chitchat. We kept our morning call to < 15 minutes today and talked about Star Wars. As a remote worker myself I truly cherish this. If you have a remote team I would call video chat standups more or less a requirement.

Out of curiosity, how valuable are these three meetings in a typical week? What do you get out of each of them as a developer?

I've worked at a few places that follow more or less the same practice and I've found that the planning meeting is hugely valuable but that standups and retrospectives are a waste of time more often than not.

Remember, meetings are what you make of them. If you can't find value in them, either change the topic to make them more valuable or don't have them at all.

The retrospectives at Pivotal are actually quite fun. Usually involves optional booze and doesn't last for more than an hour. The goal is to make them about anything, not just talk about work. It is like an end of the week team building exercise. Think about it, most of us spend more time with these people in the office, then we do with own family. So, we might as well have an hour where we put down the phones and keyboards, reflect on how the week went, find things that can be improved, talk about life events or anything really. Find the positive aspects and focus on those as well as quench any negative things so that they don't carry onto the next week.

When you say, "devs just pick the next one off the top", that sounds very much like Kanban instead of Scrum. Kanban is radically different but considered "agile". When Scrum degenerates into mgmt screaming, "you missed all your deadlines - again!", Kanban is often a great source of relief, because the only deadlines that count anymore are the "real" ones. It also allows much more flexibility with shifting priorities, which stakeholders love. Absolutely worth a try when Scrum has become a tool of oppression & misery.

I wouldn't really try to put a name on it other than Pivotal Process or Pivotal Methodology... I was just googling around to see if they even name it and found these articles...

https://infocus.dellemc.com/rahul_bhandari/software-developm... (corporate version)

https://pivotal.io/agile (this one bugs me a bit since it really just compares against waterfall)

https://medium.com/@ryanjjones10/what-is-the-pivotal-process... (this one is more accurate)

Okay well it looks like they've put even more emphasis on pair programming, which Kanban certainly doesn't require, and... I'm not gonna advocate for that part.

Pair programming all the time comes from XP. Almost no one does it, not even Kent Beck. In fact, the only place that I know of that tried "real" eXtreme Programming was the Chrysler Compensation project, which ultimately failed.

I'd be amazed that Pivotal actually does pair programming all the time, except that they are in the business of selling tools to facilitate exactly this process.

Many Pivotal teams do full time pair programming. Many don't. Pivotal Labs is pretty close to 100% because of its teaching role. Large parts of R&D practice 100% as a default with many local variations. Other parts of R&D don't practice anything resembling pairing.

All of this is presumably going to be in flux, now that the acquisition by VMware is complete.

I've been in tons of agile places that do pair programming.

You don't understand how agile development actually works and appear to be confused about terminology. There is no difference between a sprint and an iteration; they are two words for the same thing. A sprint is a planning cycle, not a deadline. Many other tools such as Jira or Rally work as well or better than PT. Recommend you broaden your experience.

The end of the sprint should not be a deadline, but a goal. Wasn't that kinda the point of the article?

No one ever said a story has to fit within a sprint, that's not how agile or sprints are supposed to work. Some stories take multiple sprints. You should always break down large stories into sub-tasks that do fit within sprints.

This iteration thing your describing sounds almost exactly like sprints to me, just reworded to sound like their own thing.

Ah, the difference is that with iterations, there is never an 'end' and goals are just epics.

Correct, all larger stories should be broken down.

To be super clear, this is not my own thing. =) It is Pivotal's thing. I am just explaining the process as it was taught to me.

>Ah, the difference is that with iterations, there is never an 'end' and goals are just epics.

Jira uses epics in the same way. And I'm not sure what you mean by "there is never an 'end'" - how does that differ from sprints? Iterations and sprints are just two words for exactly the same thing.

> Sprints have deadlines and a set amount of work...

Well, they shouldn't: https://www.scrum.org/resources/commitment-vs-forecast

What is the point in an iteration?

Good question. An iteration is a marker to generate velocity.

All of the points collected in that week are summed together and the average of those points across a configurable threshold (typically 3 weeks) is the velocity. Once you have a velocity, you can start to make predictions about the future.

For example, if velocity is 10, that means 10 points worth of stories can fit into an iteration. If the PM moves another story into the iteration, the last story would be automatically pushed into the next iteration. Makes it easier to answer the question of 'when will a story be done?' as well as 'how will changing the flow of stories affect deliverables?'

Highly recommend you read the documentation, it has been formed over many years and is excellent.

https://www.pivotaltracker.com/help/articles/quick_start/

Because then we'd call them weeks and Sprints would be Fortnights :)

In all seriousness I'm curious about the story pointing. Does the team meet together for that at Pivotal?

Repeated from above:

Pivotal has 3 regular meetings: daily morning standup (short), iteration planning (monday), retrospective (friday).

Any new stories during the week that haven't been pointed get pointed in the morning meeting.

Sounds like Pivotal combines elements from scrum and kanban in a way that works well for them. That's what you're supposed to do with agile -- keep adjusting the process until it's working well for your organization.

this ^^^^^^^^^^^