Agile Peer Review
13 views
Skip to first unread message
Ryan McKay
Aug 2, 2015, 8:59:14 PM8/2/15
to Agile Austin Developer SIG
Folks,
I took some time to record some learnings on various types of peer review from nearly 2 years of intentional refinement by an experienced, high-performing agile team. Dev team members, architects, product owner, and even members of other dev teams participated and helped shape our thoughts on review. Like anything agile, it's a work in progress. Would love to get the groups thoughts in this area at some point.
Sukant Hajra
Aug 3, 2015, 1:34:14 AM8/3/15
to agileau...@googlegroups.com
Excerpts from Ryan McKay's message of 2015-08-02 19:59:14 -0500:
Hi Ryan,
I tried using the comments on your blog, but got frustrated by the interface.
The login lost whatever I wrote there; I'll try again here.
I think you're solving for a problem that's really bad in our industry. We're
not reviewing our designs early enough. I attribute this to a culture of
over-celebrating the power of pull requests. The interfaces of these tools
(GitHub, Stash) too often enable anti-social behaviors of engineers. A lot of
important social connections either don't happen at all or happen too late.
On the other hand, pair programming swings too far in the other extreme. Most
pairing I see has a nervous energy in which the pair is too focused on
short-term productivity. What results is often shallow hill-climbing and local
optimizations. It doesn't have to be this way; it just often is. I think this
is because a lot times programming just requires a bit of research and thinking
hard -- activities that don't always fit well into the pairing format.
The solution for me is what I think we all end up doing anyway, which is pair
designing rather than pair programming. The typing part of programming isn't
that interesting anyway. What's most important is types and invariants.
I'm guessing everyone will agree with all this, and perhaps I'm re-echoing
sentiments from your post.
I did have two nits:
1. I think you're perhaps getting too caught up in the 1-week sprint. Once a
problem is decomposed into small tasks, it's not that productive to force a
synchronization with weekly boundaries. It just creates an artificial process
that's not got a high chance of success. It's much more powerful for a
technical leader to set an expectation that work is reviewed early and often
without drowning the sentiment in process. Even better is to just lead by
example and hire towards the discipline.
2. You hinted at the idea that "architects" are a separate role from other
engineers. We have to tear down this false dichotomy. All engineers are
architects. I know you only mentioned it briefly, but it's a big problem I see
in a lot of non-small companies.
Hope this helps,
Sukant
I tried using the comments on your blog, but got frustrated by the interface.
The login lost whatever I wrote there; I'll try again here.
I think you're solving for a problem that's really bad in our industry. We're
not reviewing our designs early enough. I attribute this to a culture of
over-celebrating the power of pull requests. The interfaces of these tools
(GitHub, Stash) too often enable anti-social behaviors of engineers. A lot of
important social connections either don't happen at all or happen too late.
On the other hand, pair programming swings too far in the other extreme. Most
pairing I see has a nervous energy in which the pair is too focused on
short-term productivity. What results is often shallow hill-climbing and local
optimizations. It doesn't have to be this way; it just often is. I think this
is because a lot times programming just requires a bit of research and thinking
hard -- activities that don't always fit well into the pairing format.
The solution for me is what I think we all end up doing anyway, which is pair
designing rather than pair programming. The typing part of programming isn't
that interesting anyway. What's most important is types and invariants.
I'm guessing everyone will agree with all this, and perhaps I'm re-echoing
sentiments from your post.
I did have two nits:
1. I think you're perhaps getting too caught up in the 1-week sprint. Once a
problem is decomposed into small tasks, it's not that productive to force a
synchronization with weekly boundaries. It just creates an artificial process
that's not got a high chance of success. It's much more powerful for a
technical leader to set an expectation that work is reviewed early and often
without drowning the sentiment in process. Even better is to just lead by
example and hire towards the discipline.
2. You hinted at the idea that "architects" are a separate role from other
engineers. We have to tear down this false dichotomy. All engineers are
architects. I know you only mentioned it briefly, but it's a big problem I see
in a lot of non-small companies.
Hope this helps,
Sukant
Janelle Klein
Aug 3, 2015, 8:28:32 AM8/3/15
to AA Dev SIG
Hi Ryan,
I should mention, I had the same problem with commenting on your blog (comments are deleted on submission when you login). I rewrote my comments in an editor after that and cut/paste, but it was still annoying. So Sukant's not alone on that one.
On the 1-week sprint -- I've seen a lot of problems caused by sprint boundaries, esp. when there's a high level of uncertainty/variability in tasks. The rush to finish a task by the end of a sprint leads to insufficient risk analysis & testing being done, leading to greater fallout at QA, and making bugs way more expensive to track down and fix.
When the tasks are dominated by thinking time, it's easy to cut out "extra thought" when in a hurry as long as the "doing" is done. We can try to break the habit, but with management measuring things like "sprint complete" it's really tough not to fall into the mental trap.
Janelle
--
You received this message because you are subscribed to the Google Groups "Agile Austin Developer SIG" group.
To unsubscribe from this group and stop receiving emails from it, send an email to agileaustin-d...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Ryan McKay
Aug 3, 2015, 10:56:36 PM8/3/15
to Agile Austin Developer SIG
Great feedback guys, thank you! Sorry you ran into trouble with the blog comments, its just stock blogger.com...maybe thats a problem :)
On the 1-week sprint topic, its interesting, because I got my opinion changed on that one. I was pushing kanban and fighting scrum sprints for a long time. One of our team members used retro to say, lets try it for a while. So we did, and we liked it! The sense of urgency that I thought would work against us actually helped us focus and deliver. It drove a lot of behaviors we found desireable, namely:
* Favoring finishing over starting/limiting WIP/swarming in order to get whole stories done and not leave work on the table unreleasable
* Pushing back on story scope to make sure we were delivering the most valuable feature right now, and only that
* Naming/theming sprints so we could tie everything we did to delivering that big ticket customer value
Now maybe we should have had the discipline to do all of that without the artificial sprint boundary, but we found it useful.
We handled the uncertainty/variability you mentioned with explicit spikes.
I'm going to think on the architect comment and reply to that a little later.
On the 1-week sprint topic, its interesting, because I got my opinion changed on that one. I was pushing kanban and fighting scrum sprints for a long time. One of our team members used retro to say, lets try it for a while. So we did, and we liked it! The sense of urgency that I thought would work against us actually helped us focus and deliver. It drove a lot of behaviors we found desireable, namely:
* Favoring finishing over starting/limiting WIP/swarming in order to get whole stories done and not leave work on the table unreleasable
* Pushing back on story scope to make sure we were delivering the most valuable feature right now, and only that
* Naming/theming sprints so we could tie everything we did to delivering that big ticket customer value
Now maybe we should have had the discipline to do all of that without the artificial sprint boundary, but we found it useful.
We handled the uncertainty/variability you mentioned with explicit spikes.
I'm going to think on the architect comment and reply to that a little later.
Reply all
Reply to author
Forward
0 new messages