The Importance of an Agile Team’s Rhythm

The Importance of an Agile Team’s Rhythm

Setting up a new agile team?  Where do you start?

Rhythm! 

When setting up a new agile team it is important to immediately get that team into a rhythm.  Begin with the daily stand up meetings.  Schedule these meetings for the same time and place everyday.  This will help form the team’s basis of rhythm.  Once this rhythm basis is set, extend that rhythm to other project related meetings.  Depending on your team’s release plan, schedule the sprint planning meetings and sprint review and retrospective meetings to occur on the same day and place on a regularly scheduled basis.  If you have other required organizational meetings, verify these are also rhythmic and remember to keep the team from getting bogged down in approvals.  Also, help the Product Owner to not get tied to organizational deadlines by scheduling releases around those from the start of the project.  This simple strategy will keep the team moving and focused on the overall goal of product delivery.  As the team matures, their velocity will increase and hopefully you will need to adjust the rhythm to keep up.

Below is a sample schedule that could be useful:

Meeting Name	Frequency	Time	Room	Next Occurrence
Stand Up	Daily	9:00-9:15	Room B	Tomorrow
Sprint Planning-Part A	Every 20 days	9:15-11:30	Room A	15-Mar-2010
Sprint Planning-Part B	Every 20 days	1:00-4:00	Room A	15-Mar-2010
Release Approval	Every 20 Days	10:00-11:00	Board Room	25-Mar-2010
Sprint Review and Retrospective	Every 20 Days	10:00-12:00	Room D	26-Mar-2010

Other areas of impact:  Maintaining this chart in the conference room where the daily stand up meetings will occur will keep the team focused on the next step and all team members will know what is next and when it will happen.  This will also help the Scrum Master in scheduling the conference rooms with recurring events and help the team’s stick-to-itiveness (Sticking to the schedule).

Remember:  In the event something disrupts the team’s defined rhythm, Stop, Reassess and Start Over.

Happy Scrumming…..

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.

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.