ÉnKép - takacsot

1. A Delivery Focus
Being delivery focused begins with releasing software the moment it is written (almost). Releasing means to get the software into the hands of real, live users. Nothing else counts - developer-done doesn’t count, deploying on QA environments doesn’t count, staging doesn’t count.

2. Clear Priorities
Without a source for rock-solid priorities, a development team will flounder. Rock-solid means that at any given time, anyone on the team can say what the next few most important things are. It also means that it is rock-solid until it is changed (which can happen at any time, based on changing reality and discovery).

3. Stakeholder Involvement
The one thing you can’t outsource is your product-owner function.

4. Business Analysis
. To help with analyzing requirements down into suitable chunks of work, they should be created with the INVEST principles in mind. On teams delving with sufficiently complex domains, having business analysts that both understand the domain and are able to create such stories is a must. Again, the important thing here is the role - and that someone needs to do it. Having a team of poly-skilled people that include this skill-set is enough as well.

5. Team Size and Structure
There is plenty of research and literature out there that speaks to the negative impact of having too many people on a team. Even empirical observation allows one to reach the same conclusion - after all, how many smooth and successful large projects have you seen?

you can’t always scale up the rock-star developers that are required for a project to be successful.

In other words, it’s probably Ok to hire less of those awesome developers you know if you paid them twice as much as your finance department thinks they’re worth.

6. Planning and Tracking

7. Technical Architecture

8. Testing, QA practices
Automated tests are the most important part of a code-base. Period.

9. Understanding software development
This one is actually the simplest to state, but I’ve noticed that a lot of people have trouble accepting it. Here it is - people who run software projects should know what software development is all about.
If your project is being run by someone who doesn’t really understand the nuances of software development, and heaven forbid thinks he/she does, then you’re in trouble.

Original