Agile projects have been around for years now, but for companies that are still new to the concepts and process, some simple pitfalls can delay your project. I have seen projects at companies that have run into challenges so here are some ideas for successful starts and pitfalls to avoid.

What could be so hard about starting a software project? Right! Well sometimes when pulling a group together to form an agile team you will get different ideas from each person about what agile means to them. In addition, being on a long project may only expose you to the project inception once a year perhaps. To give some ideas of the activities involved in an agile project inception, I thought I would give some suggestions for getting off to a good start, and list a few pitfalls to avoid. This isn’t a comprehensive list, I only wanted to share a few activities that are key. As a project manager there may be more activities to do. So here are a few important ones.

1. To get your Agile project off the ground create a project charter with a problem statement or opportunity statement and then a context document for the project. The context document will explore and document the domain and shows the users and their goals and actions that they will perform on the domain. I like to see a User Goal Diagram or Use Case Context used to achieve this, and I have found this type of document allows all business persons to describe what will need to be created or perhaps what doesn’t need to be created. I have seen some spreadsheets used in place of a context diagram that list out the features and or components to be created, but usually they do not describe dependencies or relationships between the items in the domain. I would suggest a visual document so that all on the team may understand and see the ownership and relationships. From this point we come up with a list of stories or Use Cases that represent all that is in scope for the project. So reviewing this document is a good way to flush out missed stories, and prevents missed scope before an estimate is done. The pitfall here is missed functionality and inaccurate estimates, which leads to missing the project target dates.
2. Explore the domain with the business contacts and subject matter experts to gain knowledge and gather ideas for your context diagram. Create a context diagram to map out your domain organizing users to their goals or actions they will perform.  The more involvement by the subject matter experts and stakeholders for the project the smoother the project will go. Holding working sessions and a review sessions with stakeholders and subject matter experts is imperative to get this task done. One pitfall that arises often is no commitment to complete the definition from your business folks who are too busy to be on your project. Not always, but on some of my projects the companies either didn’t prioritize the project high enough to allow these business resources to have the time needed to create these important documents or the subject matter expert was overbooked and had no time to meet. Commitment from company resources is necessary so the project is not delayed and the content of the diagram and stories is accurate. Other resources are over looked during this important discovery period like including the QA staff during discussions so they have a reference when writing test cases. It is also good to have the tech lead available so they can answer questions about design possibilities and helping with setting a priority for stories.
3. Hold an agile project kickoff meeting for sharing the rules of engagement and agile process that will be used.  This documents the behaviors and gives all team members an idea of what to expect while being a member of the project.  If you miss this step the team will not know what behaviors they should follow and the project will miss out on standards for operation.  Development standards are mentioned here as well as rolls are assigned for the project.  This is a nice way to create basic order in your project around the flexibility of the scope and features in the project.
4. Get involvement from your subject matter experts or product managers. As much as you can get business and subject matter experts (SMEs) to participate, encourage them meet and help describe all the user’s goals and actions. As a Business Analyst, ask as many questions as possible to get your SMEs to think of alternatives and missing content. The more a business person talks through functionality the clearer the picture gets in their head. Business Analysts should get signoff on stories for content and completeness. No signoff review or further discussions may mean missing components or features. Often having more team members available during these reviews will spar important discussions. After this update the project charter with necessary scope changes.
5. Create a list of the stories or use cases that are needed to start the process of estimation and then prioritization of the list (the stakeholders will need to decide the precision and content of the schedule and estimate for the project). It is good to give a measure of the accuracy of the estimate. Then a priority can be assigned for the stories based on business priority and technical cost. Some churning may happen around the estimation based on the feature complexity and scope desired. One pitfall that comes up with the estimate is the level of details known in the early story list isn’t enough to give a good estimate. In some cases additional meetings maybe needed to clarify the scope and functionality so that a better estimate can be given. Often a sign of minimal involvement from the SMEs.
6. Before the first release and iterations are planned we need to come to a decision about the resources needed, project costs, and schedule. The three are related and must balance as planning is done. One pitfall here is that a schedule has been predetermined without regard to staffing and cost. The size of the project can sometimes limit the number of developers able to work on the same project at the same time and therefore the earliest point when the project can be completed. One other pitfall is not giving the business analyst time to detail out the stories for the first iteration(s). For determining the schedule, extra time after the developers are done coding for QA to test out the last components developed. QA needs a few weeks to finish the remaining testing and retesting. If the estimate and schedule looks good to the project sponsor, then the team may start to plan out the first iteration and release for the project.
7. Plan for project setup and planning. Planning the first iteration and release for the project is important to get your project off to a good start. During the first part of the project an iteration 0 is needed to get an environment setup and to do a proof of concept for the technology to give the stakeholders confidence in the project. Pitfalls for planning out the first iterations and releases are not having the resources available to plan out the amount of work that can be done in the time period for the iteration. A good method of planning during the first iterations is to layout subsequent iterations to get an idea of how many total iterations will be needed and to make future planning easier for business to look and decide story or use case priority. This planning is NOT set in stone and is only a tool for the BA or PM to use to plan out what stories to detail out next.

Hopefully this has given you an idea of how you can get your agile project started and everyone moving in the same direction.  Agile projects may have different work products and process from start to completion and an agile project may be different at different companies.  I try to keep a consistent process for starting out a project and share my vision with the team so they know what to expect and how to participate.  These steps have given me success on the projects I have done and may help you to get your project off to a good start.