Matt RaibleMatt Raible is a Java Champion and Developer Advocate at Okta. developer.okta.com

The JHipster Mini-Book The JHipster Mini-Book is a guide to getting started with hip technologies today: Angular, Bootstrap, and Spring Boot. All of these frameworks are wrapped up in an easy-to-use project called JHipster.

This book shows you how to build an app with JHipster, and guides you through the plethora of tools, techniques and options you can use. Furthermore, it explains the UI and API building blocks so you understand the underpinnings of your great application.

For book updates, follow @jhipster-book on Twitter.

10+ YEARS


Over 10 years ago, I wrote my first blog post. Since then, I've authored books, had kids, traveled the world, found Trish and blogged about it all.

[DJUG] Ship it! and Distributed Teams by Jared Richardson

Jared's first book is called Ship it! and it's been wildly successful (translated into several different languages). During the first hour, Jared talked about his book and practices defined in it.

Ship it! is an attempt to talk about the holistic process of software development: techniques, infrastructure and process. For Techniques, there's a Technical Lead, The List, Code Reviews, Code Change Notifier and Daily Meetings. Infrastructure involves Version Control, Script Builds, Continuous Builds, Track Issues, Track Features and Writing/Running Tests. Process is Propose System Objects -> Propose Interfaces -> Connect Interfaces -> Add Functions -> Refactor, Refine, Repeat.

Martin Fowler's definition of Architecture: anything that is difficult to change later.

The majority of Jared's talk was about implementing TDD, continuous integration and many other things driven by audience questions. I didn't take notes because it was more of a conversation than a presentation. Jared's second talk was on Distributed Teams and my notes from this talk are below.

Agile is not XP or Scrum, those are implementations of Agile. The Manifesto for Agile Software Development is the interface for Agile Development. It contains the following principles:

  • Individuals and interactions over processes and tools
  • Working software over comprehensive documentation
  • Custom collaboration over contract negotiation
  • Responding to change over following a plan

To re-word these principles: Agility is...

  • People interacting
  • Software that runs
  • Fast Feedback
  • Frequent Change

Scrum principles are often not about developing software, they're about making people talk. The important thing is to get people in the habit of communicating. The best way to get people interacting is to do Daily meetings. One to two minutes per person. Same time. Three questions (what did you do yesterday, what today and any blockers?). Scrum style.

How do you do a daily meetings when you're remote? Conference calls are the most common, but don't let anyone local dial-in or they will get in the habit of doing it. Video is best, but it's often expensive to setup. One good strategy for daily meetings is IM. The beauty of this is that there's a transcript of the daily meeting that others can read. Conference calls are usually bad b/c you can only hear the guys that are close to the phone. It's even worse when the speaker phone is a cell phone. Whatever you do, you should never skip the daily meetings.

Peer Code Reviews are another good way to get people interacting. The first rule of code reviews is that anyone can refuse to do one. If you're not doing code reviews or pair programming, you'll end up with inefficiencies and broken windows. Address the behavior head-on. Peer Code Reviews remotely: e-mail, Skype headset, IM, VNC or SubEthaEdit (works awesome). NetBeans (collaboration module) and Eclipse (communication framework) have plugins that allow SubEthaEdit-style functionality.

How do you keep software running? Continuous integration and automated testing. Keep a list of atomic features. Prioritize. Don't let people work for 2 months. All tasks should be broken down into small chunks. Tests are a good way to communicate. Don't tell me you're done because you think you're done. Show me a test that proves you're done. Don't allow broken windows. Broken windows give the impression that no one cares and more bugs happen because of this. Continuous integration is essential for remote teams.

What's the best to get fast feedback? Fast compiles, fast tests, running CI 24/7. Another good strategy is the The List. Make sure and get feedback from your Tech Lead and from your Customers (they like to be involved). If you have a list that doesn't change after 6 weeks, you're working for a team who's list is dead.

There's nothing wrong with documentation and a plan, but its the things on the left that are more important. Offsite teams should have a single tech lead. Writing Tests might be better than writing requirements. When the tests pass, you'll get what you asked for. If you care about the design, write unit tests. If you don't care about how it looks, but want it to work, use integration/MCT for functional tests. Don't separate development and QA. To deal with time zones, make the tech lead stay up and rotate. For documentation, DRY out your Docs. Generate documentation instead of manually creating them.

"Docs are a cache ... flush often"

For Customer Feedback, have the tech lead translate.

I really enjoyed Jared's talks. The first one (on Ship it!) didn't provide much new information for me, but that's likely because I've worked on several open source projects and I've tried to bring those procedures and practices into any company I've worked at. I'm very grateful that LinkedIn does a good job with continuous integration (Hudson), bug tracking (JIRA) and documentation/planning (Confluence).

The 2nd talk on Distributed Teams was enjoyable because I'm in the heart of that - managing a remote team in Denver. We've experienced the awful conference calls where you can't hear anything or when we're on speaker on a cell phone. We do have all the video conferencing equipment purchased (10K worth) and sitting in our office, but haven't set it up because we're waiting on IT to setup a persistent VPN (which is a requirement to make it work). I've had some communications issues with my boss (mostly related to him not knowing what we're working on). We do daily stand-ups and use many of the practices recommended by Jared. One thing I think we can do to increase communication with headquarters is to start doing our daily meetings over IM and posting the transcript to a wiki page.

If you get a chance to hear Jared speak, I highly recommend it. He has a style that's very conversational and fun to listen to. You feel like you're a part of a self-help group rather than listening to someone preach about how you should be developing software.

Posted in Java at Sep 10 2008, 09:56:52 PM MDT 4 Comments
Comments:

Matt,

I'm currently faced with a rather interesting communication problem. I manage a team of 8 developers co-located with me in Memphis, as well as a team of 5 offshore contractors located in India. We're all focused on one large enterprise project as well as a couple of smaller ones. Communication has been a huge challenge.

We do daily standup meetings with the local team, but the vast majority of our communication with India is via emails and a weekly conference call. We have roughly a four hour overlap between our work day and the Indian work day, so do you think IM daily meetings would be feasible for us?

Also, I've always thought that part of the value in the daily meeting is the face time...getting folks away from their desks and talking together at least once a day. Do you think this benefit is lost by doing IM (you mention not letting local developers dial in for a conference call - what about local developers "IM-ing" in?)?

Regards,

Matt Stine

Posted by Matt Stine on September 11, 2008 at 08:30 AM MDT #

The biggest challenge in my opinion is to get people to communicate effectively. What I experience far too often is that people babble along during daily standups or conference calls or, which is equally bad, don't listen to each other. Sadly the only person genuinely interested in the "daily scrum" is the project manager. It should be each team member.

In our office where we develop an agile collaboration and planning tool we have decided to skip any kind of meeting and instead rely on a live project status display on the dashboard page of our product plus we talk, switch to pair programming or other forms of live collaboration whenever two or more have an issue with something and want to get together.

I have to admit that people may slip away and just goof off or get disconnected, if not reminded frequently to deliver something. My opinion is that you can't solve that problem via technology or process. It's a people problem and has more to do with work ethics and the motivation. Either you have people who want to contribute and collaborate or you don't. If you don't, there is no other recourse than to remove a person with lack of motivation - we had to do that as well and doing so is healthier for the remaining members of the team, as they don't get dragged down anymore.

Posted by Stephan Schwab on September 11, 2008 at 09:39 AM MDT #

@Stephen - I agree your solution can work when everyone is in the same office. But how about when the manager is at HQ and the developers are remote? I talk to my boss once a week in a 1:1, but apparently that's not enough for him. I do believe there may be a trust issue which I might not be able to solve.

Posted by Matt Raible on September 11, 2008 at 09:45 AM MDT #

Our point of view is that transparency should be able to solve any trust issue. So the information about what's going on should be easily available and then anybody might look at the details to get a clear picture.

Actually I've been traveling for quite some time earlier this year while the guys in the office were working alone on the product. So I was kind of in the position of the manager in the HQ with developers being remote. I could get enough information just by looking at the progress on task and story/bug level and the comments in there. Whenever I had time I did an svn update and tried the new features to provide some feedback and guidance. For us that worked great.

I think that the person playing the role of Product Owner may be geographically anywhere but needs to be engaged in the details of the product development day in and day out. It's a tough job and quite a bit more challenging than what most PIM educated project managers are used to. It's really about owning the project and the vision so that one can proxy the customer, provide feedback and guidance. The less important thing is people management in the way a line manager would do.

Posted by Stephan Schwab on September 11, 2008 at 12:14 PM MDT #

Post a Comment:
  • HTML Syntax: Allowed