Easy/Hard vs Complex/Simple

This may help estimating your stories in agile:

	Easy	Hard
Simple	Washing car	Pushing car
Complex	Driving car	Building car

Why it's important to merge upstream at the end of every sprint

The whole idea of agile/scrum is to regularly and frequently provide value to the business.

If you already deploy to production every few weeks, or tag your feature branch and deploy it to a Testing or Production environment for users or other stakeholders to see, then that's great! You probably don't need to merge to master or trunk in that case.

But say your release cycle is every two months so new features won't actually reach production for some time after being built. If you don't merge the sprint's work to master and don't deploy it anywhere, then it weakens all the good habits of agile working. Every sprint the developers will feel slightly less motivated to complete the work on time because it won't really matter, nothing is being done with the work. In this situation, merging to master is a proxy for deploying to production. But an even better proxy for deploying to production is: Deploying to an environment, preferably an environment of which the stakeholders have visibility.

If you don't like using master/trunk, then designate a common feature branch, release branch or any other kind of special branch to merge each set of changes to. The point is that branch should not be under direct control of the feature developer anymore. Any new changes require a new issue/branch to be created, reviewed and merged separately. It's psychologically cleaner.

There are many benefits to keeping branches small and merging upstream frequently:

• The whole team gets to review the code, even (especially) people who haven't seen it yet
• Smaller branches are easier for the team to review
• Mistakes are caught earlier so less work is needed to rectify them
• The new code can be more easily tested in continuous integration, which probably already runs off master
• Reduces conflicts with the rest of the codebase
• Makes it easier to work on new features in parallel (the alternative is using a common feature branch and sub-branches)
• Keeps you honest by "publishing" your work, prevents feature creep, makes iterations clear, etc.
• Makes it more efficient to work on and think about, you keep fewer things in your head because it's not all "up in the air"

How to communicate within an IT department or tech team

Communication is difficult, it's easy to get wrong. Here are some ideas about how to get it right.

• Mailing lists: Make them public (within the company). Archive them. Make them discoverable. Let users administer them. See GNU mailman.
• Wiki: Only have one. Keep the software up-to-date. Have an 'information architect' role, who manages the structure, so that the information is in predictable places. Make sure the search works (test it regularly). Unlock all the permissions. Let people delete pages. React to user feedback.
• When you upgrade, ideally migrate/import the data to the new version. If that doesn't happen, then export or otherwise safely archive the old content. Publish it internally, make sure it's available, even if static.
• Use the Gliffy plugin or equivalent (e.g. on Atlassian Confluence an open source wiki) or equivalent to allow users to publish diagrams of unlimited complexity, that can be edited and kept up-to-date by anyone.
• Issue tracking system: Keep the software up-to-date. Don't install a million plugins (looking at you Jira) that make it difficult to upgrade. Make sure the workflows match reality, give people standard ones and document how they work. Be very careful when making changes to workflows, try to keep them as general and re-usable as possible.
• Write high quality tickets.
• Service Desk: Use the same system as the bug tracker, which will allow all staff to track their tickets' progress in a way they understand. If this is not possible, make the service desk ticket system no less usable/visible than the staff issue tracker system.
• Ensure the service desk issue system is no less usable than email, i.e. original message chain quoted in all replies, and CCs honoured with reply-all.
• Have a special email address for people to CC which will copy the email to a ticket. Publicise it regularly.
• Choose software that makes a healthy development environment.
• Things to publish internally, and regularly re-post:
• instructions for transferring phonecalls internally
• instructions for setting up a conference calls (for all phone models in use)
• instructions for setting up video calls from conference rooms
• instructions for setting up a laptop/desktop with the big screen in meeting rooms/presentations
• List all regular non-stream tasks, define roles to triage, co-ordinate and communicate them to the rest of the team, with a view to improving and streamlining the work of the team. Examples:
• Failing tests
• Environmental issues
• Live bugs
• Supporting the release
• Inter-team liaison
• Monitoring reports
• Business investigations
• Ideally don't have any remote members of the team. But at the very least, don't inconvenience the co-located members for the sake of remote members. This means:
• Don't hold scrum via phone or skype, hold it in person. Figure out some way for the remote people to attend that doesn't take anything away from the people in the room. If there's no way, they can attend their own scrum, or not at all.
• Update: Video chat (e.g. Zoom) works well when there is a large TV screen and dedicated room microphone device. Whoever is in the office goes over to that TV & mic area and starts the video call so anyone working remotely can dial in and participate.
• Don't force people to communicate via headsets when they're standing next to each other. That would discard the many benefits of face-to-face communication.
• Make sure everyone actually stands up around a physical board (Update: Jira scrum/kanban board works fine over video chat, if updated outside the meeting). If headset range is too far to work, don't use them.
• Don't have the scrum at a weird time of day to accommodate other time zones.
• If it's difficult to hear the remote members then have them email points to the team.
• Try to arrange for the remote members to work one-on-one with each co-located member, to build rapport
• Put ALL work in the issue-tracking system to make it visible, even non-development work. If it's not tracked, you didn't really do it. Each task must link back up to team "epics" or long-term goals, and ultimately to a company goal. Must be extremely easy to create tasks with one line of text and no other info, i.e. prevent unnecessary overhead for simple tasks.
• Specific to large companies:
• Instant chat client for ALL members of staff, with zero configuration, it's just there waiting to be used. Hooked into Outlook and the O/S so that it knows when you're in a meeting or away from your desk and updates your status accordingly (e.g. MS Office Communicator)
• Have a meeting room booking system that is painless (is this even possible?) and transparent with regard to: higher-ranked employees permission to "override" bookings, policy for block-booking rooms every week, etc. Above all it should be obvious what is happening and why.
• IRC/Slack or equivalent for all. Make it clear that all communications will be logged.
• (crazy idea) Employ a person/team whose sole remit is to make it easier to communicate within the company. This is definitely not the usual "Internal Communications" team that sits with HR and serves the Executive. It's a team that is there to support IT workers.
• If the office is very large, publish a map of where each team sits. Make sure it's always up-to-date, either by giving a team the responsibility to do it, or making it editable by anyone on the wiki.
• Link from the team map to official wiki pages, etc. org chart, make everyone's names and roles discoverable and visually represented.
• Put signs up around each area so you can see which team sits where.
• Use scrumblr.ca or funretro.io or similar (virtual post-it note boards) for retrospectives, to allow ideas to be captured throughout a sprint, not just on the day. Also a wiki page does just fine. But it's also important to keep real, physical post-it notes and pens in the meeting for people to jot down ideas they just think of at that time.
• Create the following types of wiki pages, for each team or development group:
• Tech Debt / Yak Shaving / Infrastructure to-do list / Ideas / Suggestions (use your judgement if this should be one page or several). This is a list of things that people want to do, changes they want to make that are not on the roadmap, or don't obviously provide direct value to the business. The team may need help explaining where the value lies.
• Proposed technical discussion topics. Topics worthy of group discussion. Schedule a regular meeting (every 2-4 weeks) to discuss whatever is on this list and make a decision as a team about how to proceed.
• Developer FAQ. Either per-team or per-department.

Source: My own experience working in IT.

What a healthy development environment looks like

In my opinion, the best set up would include:

Software

• Jira for issue tracking 
• A wiki for information sharing 
• Git for version control
• Continuous integration and continuous deployment (e.g. with Jenkins)
• Use an existing package provider like Redhat, don't compile publicly available software yourself

Environment

• Full commit history available with details of developer name and change ticket ID
• Full ticket history available to read, with no historical tickets in the "old" system and unreadable
• /etc/init.d scripts ('service') for starting, stopping and restarting software
• VMs for development 
• Identical production, development and test environments
• Continuous Integration: Every check-in to any development branch is run through the test suite, and any failures are emailed to the author
• Immutable infrastructure: Servers are not changed. All changes begin with pushing to a repo, and a new server is then built and deployed to a subset of users, tested, then to all users.
• One-touch deployment, identical in both production and development environments 
• Continuous deployment: Every commit to trunk that passes the test suite is deployed
• Refactoring code as required, restricted only by the need to pass the test suite
• All major software components described on wiki with details of source code, restarting, troubleshooting, owner, etc.

Tests

• Easy to run the entire test suite for any branch
• Test suite should complete quickly
• A test suite that is comprehensive and well understood by all
• Test coverage stats are visible to everyone
• Tests for hallmarks of quality like 'use strict' and embedded documentation (even if a blacklist of legacy code is required)

Code

• Clear model-view-controller separation
• All code contained within re-usable modules (scripts are thin wrappers around classes)
• No "utility classes" (inherit/use roles if common methods are needed)
• No "god classes" (split up methods into meaningul sublclasses or roles)
• All logic contained within meaningful "noun" classes designed for problem domain
• Meaningful variable names in domain language and no unnecessary abbreviations
• Plentiful comments, written in the language of the problem domain
• All classes/modules to have embedded documentation

People

• For every piece of work, three people should discuss it together for a few minutes after a technical design has been proposed, and before any development work is started - a representative of the business, a QA tester and a developer.
• They should ask questions like "Are the requirements accurate and high quality?", "Does the proposed solution fulfill the requirements?", "Is the proposed solution high quality?", "Can the proposed solution be easily tested?", etc.
• The product manager as well as the people coming up with requirements must be readily available to answer questions.
• To facilitate communication. teams should *not* be split across timezones
• (separate) Scrums should take place at the beginning of the local day