Saturday, December 4, 2010

Methodology Selection: Project Management (Part 2)


Previously we discussed 5 questions to ask when determining if a project will be successful when using an agile project management methodology like SCRUM.  Here are some additional questions to ask.

6)    Project Scope and Requirements: How well defined are the requirements and scope of the project?

If the scope and high-level requirements of the project are extremely well defined, you may want to think about a waterfall methodology approach.  However, if these critical aspects of the project are not well defined, an agile project management approach will work well.  This is because an agile approach allows the team to develop small increments of work based on small batches of requirements that can be defined as the project life cycle progresses.  Additionally, the business analyst can be working of requirements for sprint # 2 while the developers are completing design and development tasks from sprint # 1.  This creates a rolling sprint approach that promotes team self-direction and quick releases of the product.

7)      Team Composition: Is the team demographics small and cross-functional?

The ideal agile project team consists of a small group of cross-functional members.  For an agile project team to be self directing and successful the team should be 8 to 15 members consisting of the product owner, scrum master, developers, business analysis and testers.  Other functional members may be necessary to maintain corporate certifications such as CMMI.  In this case a quality assurance team member would be responsible for verifying the processes are documented without disrupting the team doing the requirements management and development.

8)      System Integration:  Can the majority of development be completed on a single isolated system?

When determining if a project should use and agile approach, we should consider how the development of the system will impact or be impacted by other integrated systems.  If there are multiple systems that need to be integrated, the development process could be hampered by external teams and external requirements.  For and agile approach the majority of development needs to be conducted on a single isolated system.

9)      Continuous Integration:  Can the project support test-driven development?

Agile project develop small increments of work product and implement those work products rapidly.  This approach creates the need for a critical link between requirements, development and testing.  An agile team should be able to develop initial work packages and refine the product of the work packages based on the test results and changing requirements.  This is also why it is important to have a small cross functional team that is co-located or has the tools to act co-located.

10)    External Dependencies:  Does the project have dependencies on external vendors, project or teams?

The agile project management methodology does not support extensive integration with other systems, projects, vendors, etc. because of the rapid pace of development and testing.  Extensive integration or regression testing can also slow product delivery. So is a project is dependent on the results of an RFP or delivery of hardware or software contracts.  An agile approach may not be the most productive approach to take.

So there it is.  Ten things to consider when determining if an agile project management methodology will support of successful project and product.  Some organizations have created tools to assist the project management teams in determining which project management methodology to use for each project.  An agile approach is not always the best and is no silver bullet.  Each project should be reviewed individually to determine the best approach based on the product, the project team and management support.

In January I will be presenting “Project Angels” to the Kentuckiana Chapter of PMI. And in March I will be presenting “The Great Divide” at CodepaLOUsa.  Hope to see you there.

Monday, November 8, 2010

Methodology Selection: Project Management (Part 1)


As a project manager, have you ever had a project sponsor ask “Can we use an Agile approach, this product needs to be developed ASAP”?   If you’re not expecting this, or have not dealt with it before, this could be a very challenging question.  Here are some questions to ask.

1)     Product Delivery: Can this product be delivered in pieces?

One of the core principles of agile is the ability to define a development strategy that delivers small pieces of the overall puzzle through short time boxed development periods.  This affords frequent product reviews and changes.  Even though some aspect of the product may take months to develop, there needs to be a clear strategy for delivering incremental pieces that when the project is complete, delivers the desired product.  Note that this is not limited to building just the product; this includes developing support systems such and an IT Infrastructure or an engineering design structure.  Anything it takes to deliver the final product should be considered.

2)     Project Team: Is the project team co-located and are they dedicated to this project?

Agile project function in short time-boxed increments because the core team is together and available.  Having the entire team physically located in a WAR room is ideal.  This includes the product owner, scrum master, developers, business analysts, testers and so on.  Anyone who has a stake in the project should be available.  Some of these challenges can be addressed with technology like live ongoing chat sessions, but for the most part the team should be together.  Availability is another issue, if you believe a project team member or members may be pulled from the project from time to time to assist other project team or team members will be required to be away from the office for travel, you should consider alternate team members.

3)     Governance: Can issues be escalated and corrected quickly?

Consider if the leadership is structured in a manner that supports frequent reviews and escalation.   Change is inevitable. Issues are inevitable.  Executive management needs to be available to review the product and make recommendation for improvement.  If you believe this will not be the case, request a governance structure or the delegation of authority to a team member that can support an agile approach to managing project risks and schedules as well as product functionality and quality.


4)     Commitment: Are the stakeholders committed and available?

If the answer is no, consider an alternate strategy.  Otherwise you will find the project team members waiting on decisions or guidance for the product specification.  Stakeholders such as the product owner or steering committee need to be able to adjust the direction and focus of the team when they deem it necessary to control product quality and scheduling.

5)     Testing: Is automated testing an option?

Testing of the delivered product is key to a quality product that functions within specifications.  This is in direct support of the time-boxed development approach of the product.  An automated testing approach can bring great benefit to agile projects so if that is available or implement able, do it.  If automated testing is not an option, develop a test strategy that has the testers available and flexible enough to support the fast movement of the team.

Summary: Agile project success depends on an incremental delivery strategy, team member availability and commitment, and iterative testing.

In my next post, we will discuss 5 other areas of focus when considering an agile project management approach and how it can be supported. 

Friday, September 24, 2010

Agile Arguments and why they fail.

Most of us have been there once or twice.  Sitting in a conference room with 15-20 resources discussing why agile project management won’t work.  Some of the comments I have heard in the past are:
“Agile is just the latest gadget, It’s not real world.”
“Agile Project Management is for cowboy teams that just don’t want to be managed.”
Or my favorite….
“Agile won’t work here because we have to maintain our CMMI certification.”
These comments are exactly why some organizations need to embrace Agile Project Management.  Here are 3 reasons to put these SCRUMphobia’s behind you and lead the charge within your organization.
3 – In today’s “Real World” development teams are utilizing technology like never before. By utilizing social tools like chats, tweets, blogs and others, the development teams can be geographically diverse and still maintain a level of collocation that supports the agile process extremely well.  By providing these tools to your team, you are empowering them to work together more aggressively and therefore, more productively.
2 – The daily stand up meetings are specifically designed to increase team synergy.  Teams that work well together become more self-managed as the project progresses.  When I am in a stand up meeting, one of my favorite statements I hear is “I can help you with that.”  This is a key sign that the team is self managing.  In fact, some organizations rate their agile teams and SCRUM masters based on how well the team manages itself.  A strong self managed team is a sign of a quality CSM.
1 – Organizations that are current working toward CMMI certification or are currently re-certifying should be extremely happy about utilizing the Agile project management process.  There are plenty of articles being published that demonstrate how well Agile supports the CMMI practices with as little or less documentation than other project management methodologies.   I personally, really like the fact that teams can demonstrate delivered business value by tracking the story points as opposed to an Earned Value type of approach.  Additionally, the product and sprint backlogs cover many of the CMMI specific practices.  Follow the Agile principles, keep the documentation current and you will be fulfilling the CMMI practices at the same time.
In summary,
Agile project management is a culture changes for some teams.  Helping them realize the benefits will help them take a step toward Agile.  That said, I must note that not all projects and/or team should use the agile methodology.  Each project and team must be analyzed to determine if agile is a good fit for the team, customer, project and organization.  A well rounded organization will have a process to determine which project management methodology should be used based on specific criteria.
Happy Scrumming....

Followers

Search This Blog