11 Replies - 1284 Views - Last Post: 09 December 2015 - 01:06 PM

#1 atraub   User is offline

  • Pythoneer
  • member icon

Reputation: 835
  • View blog
  • Posts: 2,271
  • Joined: 23-December 08

Organizing the organization

Posted 09 December 2015 - 09:36 AM

Hey all, long time no see.

I've started a new role recently and a big part of my position will be bringing some management style stuff to my shop. I'd like to implement a style guide, a code review process, and daily progress report meetings. I know, I'm going to be THAT guy, but I think it'll ultimately be good for everyone to get this stuff in place. I'll probably leverage Google's Style guides with a few of my own tweaks. I'm thinking that the rest of the stuff will be covered by implementing Agile.

I'm basically just looking for some thoughts and suggestions on the topic. Is Agile as great as everyone says for a small but growing organization? Are there any books that you'd recommend on the topic?

Thanks guys!

Is This A Good Question/Topic? 0
  • +

Replies To: Organizing the organization

#2 modi123_1   User is offline

  • Suitor #2
  • member icon



Reputation: 15806
  • View blog
  • Posts: 63,313
  • Joined: 12-June 08

Re: Organizing the organization

Posted 09 December 2015 - 09:47 AM

Do you have a lot of people working on a lot of different things, or many people working on one large project?

Also - I find weekly meetings to be better than daily.
Was This Post Helpful? 0
  • +
  • -

#3 jon.kiparsky   User is offline

  • Beginner
  • member icon


Reputation: 11993
  • View blog
  • Posts: 20,332
  • Joined: 19-March 11

Re: Organizing the organization

Posted 09 December 2015 - 09:55 AM

If you just say "Agile" you're not saying much. What do you have in mind? Our team works in Scrum, and that's working really well for us, but I've been on teams where it was just "we're going to do Agile" and that never worked at all.
Essential elements of Scrum, off the top of my head:
  • Daily standup
  • Weekly estimation meetings (real estimation, whole-team participation)
  • Maximally cross-functional teams
  • Regular and predictable sprints, ~2 weeks
  • Broad stakeholder participation for sprint review and planning (at least a few stakeholders actively involved in this meeting every sprint)
  • Full-team sprint retrospective
  • Kaizen


The standup is the part that people usually think of when they think "agile". It's important, but it's just the most visible element. One thing that a lot of people omit is the kaizen - to me, that's really where scrum starts to work. If you're not coming up with a kaizen at the end of a sprint, you have no reason to expect increased velocity, and you're not going to get the benefit of doing scrum.
The other parts are all really important as well. Check out Essential Scrum by Kenneth S. Rubin if you're not sure you've got the whole story, it's a pretty good overview of the core.
Probably the most important part - and this is something that you're going to have to put in some work on, as a manager - is that you need a team with a strong buy-in. If people are really involved in the final product, scrum will help them make it better, faster. If they're just kind of there, then scrum will seem like a waste of time.
Was This Post Helpful? 0
  • +
  • -

#4 jon.kiparsky   User is offline

  • Beginner
  • member icon


Reputation: 11993
  • View blog
  • Posts: 20,332
  • Joined: 19-March 11

Re: Organizing the organization

Posted 09 December 2015 - 10:01 AM

View Postmodi123_1, on 09 December 2015 - 11:47 AM, said:

Also - I find weekly meetings to be better than daily.


Weekly meetings suggests, at a minimum, that tickets are far too big, and thus difficult or impossible to estimate effectively. It also suggests that team communication is point-to-point, which obviously doesn't scale and risks creating fragmentation and friction in the team. A daily standup, 15 minutes, is well worth the time IMO
Was This Post Helpful? 0
  • +
  • -

#5 modi123_1   User is offline

  • Suitor #2
  • member icon



Reputation: 15806
  • View blog
  • Posts: 63,313
  • Joined: 12-June 08

Re: Organizing the organization

Posted 09 December 2015 - 10:08 AM

I've never seen a daily meeting that was fifteen minutes, or caught anything major that a weekly Monday meeting did not. Though I am not certain what "friction" in the team means outside of conflicting personality types or when the Apple fanboys decide to start an OS flame war..
Was This Post Helpful? 0
  • +
  • -

#6 atraub   User is offline

  • Pythoneer
  • member icon

Reputation: 835
  • View blog
  • Posts: 2,271
  • Joined: 23-December 08

Re: Organizing the organization

Posted 09 December 2015 - 10:15 AM

To clarify, the team is basically 4 guys working on the same large project.

My thought on the daily meetings that, while tiresome, if a developer chooses a course of action that is wrong, the mistake can be caught after 8 hours of development rather than 40. That being said, I'm certainly not married to the idea of a daily scrum (and who knows how all of this will be received by the team).

Also, I'm no manager. Hopefully one day, but not yet. However, I am trying to bring more structure to the team so I'm taking on some managementy responsibilities. While we all work in a single open room, the room is frequently very quiet. I personally feel like it's uncomfortable to talk to a single other dev because it might disturb the others. We don't use any sort of in-house chat stuff because everyone probably thinks, "Why would we want that? we're all in the same room".

I don't think we currently run on sprints, so that's yet another apsect of agile scrum I'd like to implement. Any suggestions on agile books? Agile for dummies looks well-received.

EDIT:
I am trying to consider scalability, our team is small but there's no guarantee it always will be. It's a small company, but seems to be highly profitable.

EDIT 2:
Again, while not a manager, there has been talk of me improving the processes here.

This post has been edited by atraub: 09 December 2015 - 10:23 AM

Was This Post Helpful? 0
  • +
  • -

#7 BetaWar   User is offline

  • #include "soul.h"
  • member icon

Reputation: 1651
  • View blog
  • Posts: 8,523
  • Joined: 07-September 06

Re: Organizing the organization

Posted 09 December 2015 - 10:44 AM

At my company we use a more "nimble" methodology. We don't have sprints or daily standups currently, but work off of a task chart of things that are assigned to us, that includes reassigning things as appropriate/ necessary. If a developer is getting low on work, we can go and look at the tasks that other members of the team have and get those transferred over to us to work on.

We don't have a set in stone coding standard, though there has been a slight push by a couple of people to try implementing one. The big thing is code reviews, which we require are sent to at least 2 people, and they both have to sign off on it before you can check in (though we don't have any automated rejection/ blockers of checking code in except when a branch goes on lockdown (at which point nobody can push to it), and the majority of people don't actually want to have those blockers anyway to avoid bogging productivity down by process).

That last part is a big one: Don't bog down productivity with process. This is significantly more important with a small group than with a larger one since the larger the group is the more people can be doing things, even if each are getting less done things are moving faster overall. As our joke newsletter for the month says: The empire has unleashed a new weapon capable of destroying engineering productivity: the Death Scrum. A small group of rebels have dispatched to thwart their evil plans by bogging down the last patch with enough features and bugs to ensure it never releases.
(I have removed anything specific to the company, and as such it is less funny, but it goes over the original Star Wars movie plots).
Was This Post Helpful? 0
  • +
  • -

#8 atraub   User is offline

  • Pythoneer
  • member icon

Reputation: 835
  • View blog
  • Posts: 2,271
  • Joined: 23-December 08

Re: Organizing the organization

Posted 09 December 2015 - 10:57 AM

Your point is a very valid one, I don't want process to inhibit productivity. Off the top of my head, I definitely want us to implement a proper code review process. We don't have one, so I ask the guy next to me to review anything before I do a check in. I'd like to make something a bit more standard though.

I also want to implement a robust style guide. I think very few organizations enforce an appropriate level of documentation... but I probably demand more documentation than most people!

However, if I can encourage some other processes that can improve productivity both short term and long term, I'd really like to drive that too.
Was This Post Helpful? 0
  • +
  • -

#9 jon.kiparsky   User is offline

  • Beginner
  • member icon


Reputation: 11993
  • View blog
  • Posts: 20,332
  • Joined: 19-March 11

Re: Organizing the organization

Posted 09 December 2015 - 11:12 AM

View Postatraub, on 09 December 2015 - 12:15 PM, said:

To clarify, the team is basically 4 guys working on the same large project.


We're a three-man team, so it's a similar situation.

Quote

My thought on the daily meetings that, while tiresome, if a developer chooses a course of action that is wrong, the mistake can be caught after 8 hours of development rather than 40. That being said, I'm certainly not married to the idea of a daily scrum (and who knows how all of this will be received by the team).


This is one good side-effect of a standup. (I've never been sure why the daily meeting got the name "scrum", but that's a tangent) The main benefit of the standup is that it ensures that the whole team is synced up daily, at minimal cost. And yeah, if you do it right it's a very quick meeting. "Doing it right" means you have one person talking at a time, they are giving a brief answer to the three questions (what did I do yesterday, what do I plan to do today, and what roadblocks do I need help with), and there's no interruption or discussion. You should be able to get that done in about a minute. If not, this indicates that something is going wrong, and you're working on multiple issues at a time, or being interrupted, and you need help - which is certainly a bad situation, and it's very good to have it revealed so it can be addressed.
Some other things to make it work right:
  • it should always happen at the same time. You don't schedule conflicts with it, and if someone's late, you go ahead without them. Make it part of the routine, and it'll be easy.
  • vary the order of reports. One way is to make a game of it, each person picks the next speaker (and if you can catch them not paying attention, you win)
  • if you need to, pick someone keep the meeting moving and prevent in-depth discussion. (move it to after the standup)
  • we typically reserve a window post-standup for things that come up which need discussion


Quote

However, I am trying to bring more structure to the team so I'm taking on some managementy responsibilities.



Quote

While we all work in a single open room, the room is frequently very quiet. I personally feel like it's uncomfortable to talk to a single other dev because it might disturb the others.


Can you "throw the coffee sign" at someone? Catch their eye and visually suggest stepping away for a minute? (usually for me, this means going to get a coffee, which is about enough time to either answer a question or to realize that it has to be scheduled for bigger discussion)

Quote

We don't use any sort of in-house chat stuff because everyone probably thinks, "Why would we want that? we're all in the same room".


Sounds sensible to me. Chat systems are pretty interrupty, and should be avoided if possible.


Quote

I don't think we currently run on sprints, so that's yet another apsect of agile scrum I'd like to implement. Any suggestions on agile books? Agile for dummies looks well-received.


Sprints are a great good. Definitely recommend. They're how you measure your velocity, and they allow you to see yourself improving. (or else, they allow you to see yourself not improving, which is important if you want to improve)
Again, Rubin's book is a pretty complete guide, and I recommend that. I tend to stay away from books aimed at stupid people, but your mileage may vary.

Quote

I am trying to consider scalability, our team is small but there's no guarantee it always will be. It's a small company, but seems to be highly profitable.


Scrum has been shown to scale pretty well. The sweet spot for team size is 5-9, by most accounts, but you can easily have multiple teams.

Quote

Again, while not a manager, there has been talk of me improving the processes here.


Scrum defines two roles that some organizations ignore, but they're kind of handy. One is the "product owner" - this person is responsible for ordering the backlog and determines what issues go into a sprint. This person works with stakeholders to make sure that the product being built is the right product, but they make the decisions about what the team works on. The other is the "scrum master" - this person is responsible for ensuring that the scrum goes along in good order. They will typically see that the meetings go along well, run the sprint review, and take charge of clearing obstacles that the team encounters. This sounds like a good role for you. (I'm the scrum master for our team, it's pretty satisfying)
Was This Post Helpful? 0
  • +
  • -

#10 jon.kiparsky   User is offline

  • Beginner
  • member icon


Reputation: 11993
  • View blog
  • Posts: 20,332
  • Joined: 19-March 11

Re: Organizing the organization

Posted 09 December 2015 - 11:19 AM

View Postatraub, on 09 December 2015 - 12:57 PM, said:

Your point is a very valid one, I don't want process to inhibit productivity.


This is a bugaboo that I've heard a lot, but seldom seen. If the team implements the process, the team can tune the process to their requirements. Don't let fear stop you from getting shit done.
Was This Post Helpful? 0
  • +
  • -

#11 xclite   User is offline

  • I wrote you an code
  • member icon


Reputation: 1481
  • View blog
  • Posts: 4,336
  • Joined: 12-May 09

Re: Organizing the organization

Posted 09 December 2015 - 12:52 PM

View Postjon.kiparsky, on 09 December 2015 - 01:12 PM, said:

"Doing it right" means you have one person talking at a time, they are giving a brief answer to the three questions (what did I do yesterday, what do I plan to do today, and what roadblocks do I need help with), and there's no interruption or discussion. You should be able to get that done in about a minute.


This is the hardest part, in my experience. I find value in daily meetings, but most standups I go to are a colossal waste of time - people go into far too much depth discussing their stories, they interrupt one another to ask side-tracking questions... if you can keep each status to a minute, they are a cheap way to sync. If people can't abide by the rules, daily standups become a chore.
Was This Post Helpful? 0
  • +
  • -

#12 jon.kiparsky   User is offline

  • Beginner
  • member icon


Reputation: 11993
  • View blog
  • Posts: 20,332
  • Joined: 19-March 11

Re: Organizing the organization

Posted 09 December 2015 - 01:06 PM

"Yesterday, I worked on AC-1158, that's the one about deprecating the startup.user field and relying on startup.team_members, and I handled an interrupt from the UK, where they needed a fix to their permissions. Today, I expect to finish up AC-1158 and address pull request comments on AC-1904."

Done.

You need a scrum master.
Was This Post Helpful? 0
  • +
  • -

Page 1 of 1