>> I just started writing a summary of our standups and told them they didnt have to do it individually any more,
>> it was appreciated and mgmt still get the info they need.
I'm skeptical that management would need a daily status.
You don't need nightly builds either - but they can be useful. Shorter feedback cycles / faster iteration has a lot of benefits. Also depends on how far up the management chain you're going.
If you've got critical bugs live in production, "management" may be the ones ensuring all the hot potatos are in fact being handled by someone - that nothing is falling through the cracks, that everything is being addressed, that QA is on top of testing hot new changes that need to be rolled out ASAP. Daily isn't frequent enough in this context.
Burning through the QA backlog leading up to a big release in ye olde milestone driven waterfall style schedule? Daily might be frequent enough.
Long term feature work? Might be able to go weeks between updates - but a daily ping of "still working on X, still on schedule" takes what - 5 seconds to email, 5 seconds to read? Helps keep the mental burden of juggling everything in your manager's head down, maybe helps reassure them you're not going to pull a "so yeah, we've still got a month of work left at least" on delivery day when they're reporting up to their management. They might not be able to help you get your task done faster, but they might be able to rearrange other parts of the schedule to keep their stakeholders happy (e.g. X is running into delays, but we can give you Y ahead of schedule). Even if they can't do anything to help the schedule, they can start managing expectations ahead of time, prevent unseemly "surprises."
And hey, daily status reports are better than daily status queries.
Keeping management informed via daily email does not scale. Nor via phone or meetings. All this daily distraction nonsense.
Have a high-overview webpage where they can look it up by themselves if they need to.
This is faster than daily and gives much better and accurate info. It's your task to communicate
the metrics, scheduling problems, cost overruns and feature creep.
> Have a high-overview webpage where they can look it up by themselves if they need to.
Who keeps this up to date and well maintained? I see little fundamental difference between pushing metrics/status via JIRA and pushing via email. Both scale (or don't) just as badly. Both require distraction from your development tasks to properly estimate or summarize status/problems.
Don't get me wrong - keep the daily distraction the hell in check. But there's no magic bullet to make good communication free, and there are plenty of people and contexts where words and language work way better than attempting to abstract things with stats and metrics.
> This is faster than daily and gives much better and accurate info.
Maybe for you. Maybe for me. Definitely not for a lot of coworkers I've known. They do not context switch from "this is harder than I thought" to "track down the JIRA task and change my estimates". Getting some of them to even log work done is like pulling teeth. Hence hacks like the daily standup - poll, use words, get the real status.
Having worked for a company that used daily status reports via email, I can say that they are an absolute pain in the ass, but clients were delighted by them when done properly. Those status provide a clear hand written description of what your team did and next steps to take. I can honestly say that those reports did as much as the quality code to show us as a professional team in which the client could trust.
And yes, if you couldn't write your own status for each day, even after training and guidance to do so, you weren't a fit for the company.
It was one of the best companies I've worked for and where I learned the most.
It depends on the local environment. The way I think of it is: if I hire senior talent at $OMG annual salary, maybe more than managers make, I want to know they're DOING something. So daily status makes more sense. Then when a level of trust is established, should go to weekly, if management is at all competent.
The thing is, it's all about visibility. Can management look at your sprint board, either physical or online, jira agile board for example, or in some other tool, where they can see what's going on? That's a good place to start.
This is actually the case and I probably misused the term, mgmt is actually the founders trying to find out if the features are going to be pushed before the next client meeting 90% of the time
My approach is to learn the stack (read books, sketch/prototype).
Get the team to whiteboard the architecture with you. This is better than existing documentation because you will get the full commentary and start building a mental model of the software.
Ask the team about problem areas.
Don't push on major stack/architecture changes until you know the stack/architecture.
Make sure the base engineering practices are there. You should have a seamless workflow from pre-merge code reviews, testing, and deploy.
DECK Monitoring (deckmonitoring.com) is looking for senior developers and a sys admin.
Skills & Requirements
---------------------
* At least six years of programming experience, professional or unprofessional.
* You have tackled tough problems and developed large, highly-available applications.
* An excellent command of a high-level language such as Ruby or Python. We use Ruby extensively.
* Strong SQL skills.
* Best practices are in your bones. You write unit tests, pair code, peer review and strive to create beautiful code.
Bonus points if you have experience wih:
* Rails, RSpec, Cucumber, Sinatra, Git, Lua, R, Redis, Resque, JavaScript, HTML5/CSS
* Math and Statistics
* Energy monitoring
* Scrum/agile methodologies
About DECK Monitoring LLC
-------------------------
DECK Monitoring is the US market-leader SaaS renewable energy monitoring company. We make great software and take on complex problems (with the help of a whiteboard and some code). We hire the best programmers that we can find and treat them well.
* Competitive salary and benefit package (medical, dental, retirement)
* Conferences, books and other perks
* Choice of Linux or Mac, editor, etc
* Offices downtown Eugene and Portland
How to Apply
------------
Send a paragraph about yourself with relevant links to recent code and a plain-text or pdf resume to careers[at]deckmonitoring.com
Deckmonitoring.com is an energy monitoring company specializing in solar PV and green technologies. We are looking for really great people to join our development team.
The main application is Ruby on Rails. The client-side application is in active transition from Flash to HTML/JavaScript. We have massive amounts of data coming to us from solar installations all over the world and we display that data on a dashboard in near real-time.
Send an intro paragraph and links to sample code to: careers[ at ]deckmonitoring[ dot ]com
