As pointed out, cursors can't predict the future, i.e., they have no idea what is in the next row until they visit the row, which then makes it the current row and not the next row. Looking ahead with cursors involves iterating over the data set twice, either serially or in parallel.
Xander Bakker's code is serial, i.e., it loops through the data once, completely, to build a local lookup structure for the second loop. The approach is straightforward and will work in a majority, possibly vast majority, of cases. When working with very large data sets, especially with 32-bit Python, the size of the local copy of data may become an issue.
An alternate approach that doesn't involve making local copies of data is to use two cursors in parallel where one increments ahead of the other as both go through the data set. This eliminates the local copy of data, but it might create an I/O bottleneck with the back-end data provider depending on the data set and conditions. Adapting from Xander's example:
# access data and define fields to use
mxd = arcpy.mapping.MapDocument("CURRENT")
table = arcpy.mapping.ListTableViews(mxd)[0]
fld_in = "name"
fld_out = "another field" # I added a second field for output values
# use a with statement when working with cursors
# use the da module for faster access
# use UpdateCursor to update values
with arcpy.da.UpdateCursor(table, (fld_in, fld_out)) as u_cur:
# use Search Cursor in parallel to get "next" value
with arcpy.da.SearchCursor(table, fld_in) as s_cur:
next(s_cur)
for s_fld_in, in s_cur:
u_fld_in, u_fld_out = next(u_cur)
# compare values and do one thing or another
if s_fld_in == u_fld_in:
u_fld_out = # some value
else:
u_fld_out = # different value
# update the values
u_cur.updateRow((u_fld_in, u_fld_out))
With a multiple, parallel cursor approach, it is a good idea to include an "ORDER BY" statement in the cursor definition to ensure the two cursors are iterating over the dataset in the same order.
Overall, I recommend structuring the data so you can look backwards instead of looking forwards. Looking backwards involves a single cursor and single iteration, which is simpler to code and performs better.