1. Build solid relationships all of  your stakeholders.
   • Customers
   • Product Management
   • Executives
   • Business Partners
   • Business Units
   • Customer Support
   • Operational Support
2. Create a single intake process for all product requests.
3. Partner with stakeholders when prioritizing requests. Make sure they are part of any product steering committee meetings.
4. Always prioritize severity 1 & 2  bugs before accepting any product feature requests from your stakeholders.
5. Scalability, availability, and peformance enhancements should be prioritized very high in relation to product feature requests. Categorizing them as bugs also is way to make sure that fall high on the priority list.
6. Do weekly reviews of all production & QA bugs.
7. Do monthly reviews of production & QA logs to do trending for security issues, performance issues, and capacity planning. Aggregate this data into big visible charts where everyone on the team can see it daily.
8. The development team should have real-time visibility to system level stats from the production environment. Use tools like Ganglia and Cacti to give the team a real-time view into production.
9. Every person on the development team should spend time sitting with the customer support team listening in on support calls to get a deeper view into customer issues. Every 2-3 months for a few hours is a good schedule.
10. Define a clear escalation plan for production outages/issues. Who is the first line of defense? Who do they escalate to? How do they classify the issue? When should development get involved? How should data be captured for later root cause analysis? Pull data from the HR system for the escalation up the management chain, do not waste time maintaining separate team lists of contact information. Update you HR system to contain all contact info then pull the data!
11. Hire a technical writer to setup a wiki with a well designed information architecture for all product documentation. Run books, architectural artifacts, knowledge base, etc..
12. Ensure that there is clear requirements traceability back to the originating stakeholder request.
13. There should be design traceability from the high level design to the detailed design to the completed code.
14. Every person on the development team should be trained on how to do root cause analysis.
15. After any and every production incident there should be a root cause analysis performed with clear action items and associated owners to prevent the issue from re-occurring. This is not a witch hunt to find someone who to blame, but rather a way to identify what process or lack of process created the environment for the issue to have occurred.
16. Focus on eliminating waste in all SDLC processes. A good place to start is with any process outside of analysis and writing the code, ask the question is the process adding value?
17. Balance time to market vs. perfect architecture. What is a reasonable architecture to solve the problem today. If cost, resources, or time constrains the architectural design then have a story of how to undo the trade offs made in the design to meet the time to market demands. What is the plan for getting rid of the technical debt?
18. Make data driven decisions, but do not require that every decision be made with complete data. Identify the experts in the organization and trust them to make the right decisions based on past experiences. For example, picking the right initial architecture should be based expert judgment, past experience, and some amount of prototypes. But scaling that architecture over time should be completely data driven from the metrics collected on the production systems. Always be measuring, analyzing, and optimizing based on the data.
19. Everyone on the development team should have a professional development plan. This plan is a contract between the employee and management to ensure that the organization will provide all required resources and opportunities for the employee to realize the career goals.
20. Foster a culture that supports a healthy balance between work and family life for everyone within the organization. Let people go home to their families at reasonable times. Ensure that people are taking vacations on a regular basis. Value results driven work over duration driven work.
21. Create a respectful work environment where:
    • employees are valued
    • communication is polite and courteous
    • people are treated as they wish to be treated
    • conflict is addressed in a positive and respectful manner
    • disrespectful behavior and harassment are addressed
22. Every 2-3 months get the entire organization together to discuss the product roadmap, discuss successfully delivered work, answer questions, motivate the teams, and above all to publicly praise and reward the star team members within the team.

I just recently started working on large software development project that the management team decided to use SCRUM over some of the existing waterfall process used throughout the rest of the organization. When I first heard the news I thought great now the team can focus on building working software rather than following processes that only make the leadership team feeling like they have control over the project. The problem is that the team is spending large amounts of their time keeping information up to date in VersionOne the tool that was chosen by the management team to manage this project. VersionOne is a very popular tool that many successful companies have standardized on for SCRUM or XP, but from my experience effective agile development teams always choose low tech tools for managing the development.

What do I mean by low tech tools? Low tech tools are tools that do not require the team to sit in front of the computer to use; simple things like big visible charts or information radiator and index cards. Why is this so important? Because the team already spends a large amount of time sitting in front of the computer developing and testing the software, why make them spend all their remaining time updating and managing user stories, burn down charts, and tasks chained to the that same machine.

Low tech tools have a way of connecting people with the ideas and concepts in a much more clear, tangible, and meaningful way. For example, a team can sit down and write all the user stories on index cards then with some large wall space tape the index cards to the wall to create a product backlog. From that the team can do sprint planning by simply moving cards from the backlog section of the wall to the next planned sprint; all with no dual core’s required!

In a large organization or working with some remote team members the low tech way can be difficult and the organization may require that the planning be documented in a more formal project management or tacking tool. To address this have the PM on the team be responsible for keeping the low tech tools in sync with the high tech tools. They are the ones that need to communicate the status of the project to many different types of stakeholders so it makes the most sense for them to manage the communication; and leave the team to focusing on the code…

1. Developers, product management, and customers brainstorm ideas.
   

   What problem are we trying to solve?
   What market opportunity are we trying to meet?

2. Developers & product management write the core user stories.
3. Developers build an end-to-end web site skeleton with mocks to any external systems.
4. Developers spec out the core web site API.
5. Developers and product management iterate over the web site skeleton adding the core user stories.
6. Partnering with the customer; developers and product management push the product to market as quickly as possible.
7. From customer feedback developers and product management enhance, rewrite, or create new user stories and apply those stories back into the web site.
8. Repeat 1-7

It seems that in all my years of software development every company I work at seems to feel the need to pull people off of real work to have a meeting. Where they want to discuss some useless topic that just makes managers feel like the team is being productive by communicating status or issues. So what are good guidelines for meetings? Should we be having meetings? Here are my 3 golden rules:

1. Meetings should never be scheduled; you should strive to create an environment where meetings just happen. How do you do this? Create open development environments where there are no offices or cubicles just groups of desks with lots of couches and whiteboards. In this environments meetings become organic and happen only when people need to talk.
2. You should never have meetings to communicate status; that is why you use wiki’s and bug tracking tools. People who want status should just pull the status from those tools. It does not matter if you are standing up while you are giving status in a meeting or you call it agile. Status or issues should be an asynchronous activity where the people who need to know should be pulling those from the team, not slowing them down with a synchronous meeting.
3. You should only have meetings for productive things like brainstorming new ideas, doing use cases, group design, discussing code, or getting the team together for drinking beer.