What do you think the problem is? What's keeping your team from shipping? What slows down the development process?
http://www.quora.com/Engineering-Management/Why-are-software...
When I look back on my career the patterns that lead to good development were:
1) small team sizes, I'm a big believer that if version 1 of your product is developed by more than 4 people, its in trouble:) Small, super focused, and highly talented teams make the best version 1 products in my opinion, probably related to why some start ups can be more agile.
2) Everyone on the team has domain experience, ie its not the first time a product has been written. This is slightly at odds with the "second system syndrome". At my current company, when we wrote our algo platform, each member had done this before so we knew from a data, networking, machine learning, and trader's perspective what we wanted to get done. There was very little flailing around trying to learn the domain( ie no learning what ml techniques to use, how to connect to exchanges via FIX, no learning what a pairs trade was, etc).
3) 1, and only 1 person in charge of the vision. This might be obvious but debates, even when they are well intended, seem to slow things down. Having one person dictate what the next version will have seems to make things much easier. This is especially obvious in my current field of finance. Its very easy to spot the products developed by engineers for traders, vs the products developed by traders for traders, The former have lots of features that no one wants but they look pretty and the later, look ugly but make money:)
META NOTE TO ANYONE DEVELOPING A TRADING SYSTEM No one cares what it looks like. I'll say that again, no one cares what it looks like. The Bloomberg terminal is the ugliest thing on the planet and they mint money. Function over fashion, always. I'd go as far as to state that a small team developing a trading system having a designer is viewed in the same light as a small team having an mba. That person might add value, but you'll need to justify why you're there instead of another engineer.
I think alot of not shipping can be tied to these three things, too large of a team, not knowing what the final product will be doing and hence alot of experimentation and wrong turns and competing visions, or a lack of vision of what you are building.
Only informing them about this, in some cases, is not enough.
It would really be well if people realized their bias, but they rarely do.
A lot of engineers will say things "We need to use X, because Google, Facebook, etc use X". All the while ignoring the fact that Google and Facebook deal with massive scale, have tremendous resources to bear, and hardly get penalized by their customers when things break. The tech is only one small part of a much larger puzzle.
It's often easier to suppress such debates than engage in them, especially in the early days when you don't have the luxury of time. I'm not saying it's always the right thing to do, but it's often not the wrong thing to do for a team to continue shipping at a regular pace.
Us: "Well, we just got the roof on and all the walls sheetrocked!"
Them: "We want all the walls moved now."
Lately it's also been the strangely recurring request to do the impossible. I've actually been asked to use cross site scripting ("like the hackers do - why can't you do it") to implement features a customer just had to have.
* Bad estimates. When people are too aggressive with their estimates and miss them, it derails everyone that was depending on that team's stuff being done at a particular time. It causes blockages that cost way more than an over-estimate would have reserved as buffer time.
* Getting distracted. Dev should work really closely with design and PDM to get things done, but if Design / PDM has already moved on to the next project, it's distracting for everyone when they have to get pulled back in. Then, you have multitasking, and blockages, and stuff doesn't get done as smoothly as it should.
Years ago, that was called Build Management, now, we call part of it DevOps. But the reality is that most teams have forgotten about professional engineering.
Pausing to think about the 'how' rather than just hammering it out, and living with the consequences are enormous. The fact that I rarely see separations of concern anymore, let alone focusing on reducing build times or test run times, is massive. Ultimately, that means tradeoffs - the software triangle comes into play.
It's especially interesting to me, since I'm (today) working with a team I last worked with 12 years ago. There's been massive flux - only three of twenty originals are here. And yet, with multiple geographies, multiple age groups, multiple operating systems, and three distinct cloud providers (let alone the internal wannabe cloud) they push out a valuable release weekly, and micro-push to production ~3x daily. That's a testament to the engineer who manages the team, the same engineer I worked with on build workflows over a decade ago.
Unlike the captain who lost a mast passing through the storm and limps to harbour a hero who saved the ship, our engineer goes unsung.
I hope your Collegue has been able to capture for himself the money his employers did not spend on crash rebuilds, massive emergency development programs and lost productivity of the main Dev teams ....
No?
Like our captain friend ... Only work for admirals who have sufficient ships that outliers stand out.
Luckily, our deployments are automated and we deploy to our testing environment multiple times a week, sometimes multiple times per day. That at least enables us to get feedback from the test team, which results in tickets either being moved to 'really done' or moving them back to 'in progress'. It's not the same as shipping, but in such an environment it at least reminds you of the important fact that things are indeed still moving and getting done.
Hotfixes ship as soon as they're done
In reality, for the vast majority of launches very people are watching, and even fewer care about your features or lack thereof (that's just not how early-adopters think about products, in my opinion).
If founders realized how little traffic / how few downloads they were going to get out of the gate, they'd ship much earlier; unfortunately everybody thinks their project is going to be a TechCrunch headline, and that's just not the case.
1. Fear of failure. Too many people are afraid to ship too soon. They fear a bad product out the gate, rather than getting out the gate in the first place.
2. Lack of focus. You'll spend too much time focusing on things that don't really matter, such as building the perfect messaging system rather than reusing something that exists and works now.
3. Busywork. You'll spend your time doing things that really don't matter, such as optimizing your icons to use fonts instead of a PNG, and then dealing with trying to make it work in older versions of IE.
We'll start a project and then half the devs will go on vacation. They return, and then the other half go on vacation. I guess that's summer for ya, but why not just close the office for a month and let everyone know that they should take their vacations around that time.
Devs will raise complaints about the work environment or a poorly written (but critical) module, but nothing gets done about it.
If a feature doesn't have strong executive support, nothing really gets done on it, and 3 months later someone will ask "hey, what happened to that feature?"
I've been one of the "apathetic" people before, I've seen it happen due to burnout, too many times working with no recognition, lack of faith in the higher ups, etc...
I'm going to single one out though: tweaking: making changes without adequate anticipation of the effects, or without the theoretical backing to expect that it will be correct. When you have a well structured high level understanding you can make changes knowing approximately what the effect will be and converge on the solution. Without that you end up thrashing around and making changes at random. If you take a random walk you're probably not going anywhere fast.
When you are dealing with a well designed and executed system, then tweaking actually seems productive, because you begin from a good place in the solution space, when you explore the "local neighbourhood", then the modifications still produce a functional piece of software and it might actually be better in some ways that you care about.
When you are making something new, tweaking gets you nowhere.
EDIT: Here is a foolproof process to get me to automatically disregard all your future ideas:
1. Find some parameters that were chosen with theoretical justifications and a real analysis of historical data.
2. Modify one of the parameters based on some flimsy rationale.
3. Run some quick tests that are obviously designed specifically to confirm your expectations, declare victory and act like you've solved something.
What do you think the best solution is?
It also depends on what domain your company is in. If downtime doesn't lead to anyone's death, doesn't send you to prison or millions in lawsuits from Enterprise customers...sure ship daily.
Not having a clear and concise plan. For software development this means obviously a detailed and worked out feature set.
It amazes me how often a development team is set out on the journey of building a system without clarity of what it is it's trying to accomplish. Sure, the high level functionality is there but as developers you need to know low level stuff. Usually this due the lack of leadership. A word to the "CEO's" out there;
A vision that's not formalised in a document and shared with the rest of the team is not a vision, it's fantasy.
Sure, I get it. For you, the CEO, it's easier to make stuff up as you go along than it is to write stuff down and to commit to it.
As a developer, when you try to get functionality formalized then those meetings to discuss the functionality turn into "design" meetings where everyone has to come up with new "awesome" ideas which means that at some point the team stops having meetings to discuss things.
It doesn't matter how much experience I have as a developer, I simply can't cram the full time role of project/product manager and at least 40 hours of writing quality software into a single week. Something has to give.
You first need to figure out what the problem is, and you won't figure that out by writing a detailed and worked out feature set solving a slightly different problem.
Remote communication will have technical issues once in a while. If not that, then it's the "telephone tag" game you end up playing. Also timezones.
I'm convinced that good communication is a symptom of other things being good. Project has clear goals and everyone knows what they're doing? Communication is good! Project is unclear, scope is too big, or just plain boring? Communication is bad.
I worked on a team with deep trust issues between the product manager and engineers; PM didn't believe engineers were doing their best/giving fair estimates, engineers didn't believe the PM was asking for features that would lead us to success in the market. This lack of trust meant a big fight every sprint, and a lot of productivity lost to arguments and the ensuing distraction. Sample size of one, but the PM never had lunch with engineers or otherwise engaged with them socially. I can't prove it, but I suspect things would have gone a lot smoother if we'd all been friends.
tldr: Off-topic communication can still be good communication (in moderation) because it helps develop/maintain high quality relationships between the people you work with.
Problems are dam hard: What we do is really hard, so basically we have to trim our projects to the basics, instead of doing what we want to do, which is way more. Creative people want to start-create always way more projects that what they could finish, so we need discipline here.
*Complexity and lack of documentation. Another thing that needs a lot of discipline. People believe that what they know after thinking on it for a lot of time is evident for everybody else. It is not. Not only that, people forget what they know today if they do not document it, so if you do not document a year from now you will repeating most of your work, with the company's budget.
Tools: The longer it takes to release, the less it will be done.
Culture: The harsher the response to failure, the less risk shall be taken.
Only unchanging thing is the deadline.
Also *x increased chance of various debilitating diseases.
Not to sound like a crazy health nut - there are two stupendous studies on the citizens of Okinawa (The Okinawa project) and China (The China study) that leave little doubt on the long term effects of junk foods.
So yes, it can.