Who should read this: Software developers or other participants in IT projects who want a high level overview of what is needed to make projects succeed, with a technical bias.
All work in a project must be done to increase the likelihood of success. The process imposed, the roles involved, the people chosen and the technologies used should all work towards this goal.
For the record, I apologize for simplifying, not covering and simply forgetting important areas. I am trying to give you the pure and simple truth, however:
The pure and simple truth is rarely pure and never simple.
- Oscar Wilde
Process
IT projects are complex. The Standish Group’s Chaos Report has attempted to cover this over many years (2009 report in pdf). To handle the complexities of software, the industry appears to move towards streamlining project processes in increasingly agile ways. A common denominator for this work is the well known manifesto for Agile Software Development devised in early 2001:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a planThat is, while there is value in the items on
the right, we value the items on the left more.
As anyone involved in real projects know, you need to adapt to changes and challenges, deliver and receive feedback on a variety of levels, and continuously work to reduce waste. You’ll never know everything in advance, and unexpected changes will occur.
The process within IT consists of both the main methodology used and the more technical practices followed.
Overall process
The industry today is steadily working towards being agile, solving problems through iterations and improving continuously. From a developers perspective, this is usually something you will have to accept. Even if it’s not your responsibility, it doesn’t mean you couldn’t or shouldn’t influence the process. Being part of a project team means you have a responsibility for the project’s success. Communicate your concerns. Help inform your coworkers and management.
Within agile there are many different processes; Lean, Scrum, Kanban, and many more. Which is the right one? The choice depends on experience, your organization and the challenge ahead. But never forget: mix and match what works for you - being agile certainly apply to both the product created and the process used. (And be wary of certified [process]-masters. Are you sure it means what you think it does?)
Whenever you care about the results of what you are doing, skilled people are a must. But even the brightest people fail because of misunderstandings or general problems with communication. One very import point to focus on is to improve the feedback loop. Have the customer and business experts work close with you throughout the process, and increase the frequency of releases tenfold (At least to test environments). Training on and delivering new releases reduces the risks involved, increases the feedback from users, and enables you to deliver the right functionality at the right time.
Before moving on, I thought it proper to address a common misconception with agile - that agile equals little or no planning. I have to insist that this is a false claim, and the reality is quite the opposite. If you want to learn more, this is a good article explaining the importance of it, and at what levels planning should occur.
Technical process
The technical process is pretty much anything that directly relates to what is produced; estimation, tasks, quality assurance, and releasing new versions.
In project and sprint planning, estimation is usually considered an important practice. Estimation is useful to consider what is involved in producing a feature, visualizing the cost of implementing it, and ensuring that everyone has a similar understanding of the scope. How estimation, planning and tasks are handled varies, and you should experiment with what method works for you. Do ensure that you work to build transparency and trust, as described in this quote from Gabrielle Benefield, Director of Agile Product Development in Yahoo!:
Keeping everything transparent, and letting the business know of any changes as they come up, means that the business can adapt quickly to make the best decisions. At my last company I saw us go from a state of permanent chaos, where we had an extremely ambitious roadmap but couldn’t deliver products, to a predictable state where we could genuinely sign up for projects that we could deliver. The business said they might not always like the answers (they always want things tomorrow, after all), but at least they believed our answers and were not frustrated from feeling that they were being consistently lied to.
The quote, and significantly more, can be found in Agile Estimating and Planning by Mike Cohn.
There will often be doubt when planning something; which technology is right, what main flow of logic is appropriate, and so on. Don’t be afraid to use prototyping to verify assumptions. Creating an end to end working example and/or ensuring that the toughest problems can be solved can save you a lot of time in the future.
I mentioned feedback earlier as a key principle. Within the technical process, this should be supported through a few good practices. Code reviews, pair programming and static code analysis are tools useful to get quick feedback on quality. Automated tests are another, with unit, integration and acceptance tests (and sometimes a few more) as common categories. Continuous integration is another practice that helps increase feedback and quality. By automating compilation and running of all tests for each check-in, you add another step for ensuring quality, increasing feedback and helping visualize the current state of the code.
The practices mentioned above are often introduced more from the technical personnel in the project. But to support the overall process need of more frequent releases to test and production, a number of practices are key: automating deployments, including moving code, configuring machine and web servers, handling environment specific configuration settings and setting up the database. It won’t come free of charge, but can bring about great benefits.
A lot more can be said about improving the release and deployment process. I recommend reading the book Continuous Delivery to get a better overview.
Technology
Beyond the general practices, what is important in technical development?
At both higher and lower levels, having a good overview of alternatives is necessary to select the right technology or solution (Never forget the hammer nail analogy). It is impossible to know the details of everything, but learning of qualities plus pros and cons of alternatives enables you to better select the correct one. Subsequent tests might find your initial knowledge about the technology was wrong, but that’s why you use prototyping anyway.
When it comes to code, I am a strong supporter of simplicity and readability. If what you’re creating can’t be understood without hassle, how is anyone going to be able to maintain it? Refactor as your understanding improves or changes occur, or be aware that you will end up with code that in near or distant future will take time to understand, even more energy to change and will undoubtedly create bugs. And automate testing of anything moderately complex. Pretty please?
Beyond mastering the technologies chosen, what more is there? Never forget that your system will go into production one day. Security, logging, monitoring, error handling, integrations, multithreading, scalability, hardware and firewall issues are areas you need to focus on. Now is the time to go ahead and read Release It!.
So much more can be said about technology and technical development, but it is hard to generalize. Find the right people and all will be good with the world.
People and roles
A software project can consist of a variety of people. You can have software developers, UI specialists, database administrators, operations, business experts, testers, project leader, project owner (and a variety of other project something roles).
No matter what roles exist, make sure the communication is frequent between all related parties. If you can co-locate it will help reduce misunderstandings.
Management 3.0 has a lot to say about leading people in IT projects. As the author says
I think that people are the most important parts of an organization and that managers must do all they can to keep people active, creative and motivated.
