The Right Electronic Signature Leads To Real Benefits!
The real problem: Predicting the Unpredictable
Montefiore Uses Healthcare Information Technology as Its Anchor for...
The 7 Habits of Highly Effective Agile
Moving Towards a More Agile and Outcomes Based Model
Raiford Smith, Vice President, Energy Technology and Analytics, Entergy
Quality Tracking For Agile At Scale
Jonathan Alexander, CTO, QASymphony
Pursuing a Lean or Agile Approach
Brian Hicks, Director ERP PLM, USANA Health Sciences
Agile Transformation: Transforming People from the Inside Out
Margarita Louredo, VP-Business Innovation, Orange Lake Resorts
Thank you for Subscribing to CIO Applications Weekly Brief
Agile Methodologies in Large Projects
Large projects are often fraught with complexities as the collaboration between different sections of developers, analysts and testers are difficult to establish. The most common approach to facilitate better collaboration and communication is to break it down to sub-teams.
However, there is a downside to these sub-teams as they tend to create stove-piped subsystems when the communication thins down between these teams. Precisely, this approach could significantly result in a non-homogenous and inconsistent architecture.
Dividing at a Later Stage
It is suggested that instead of dividing the project in the beginning and then going about each sub-problem, begin with a core team. The core team is instrumental in building out a valid standard business case in a test-driven manner touching all of the primary business areas and framing most of the architecture. With a small team in action, a full agile methodology works like a charm. With a significant portion of the architecture completed, the first phase comes to an end with a stable code base. It is now the time to divide by growing the development team and splitting it up into smaller teams to render the project into a functional system.
Because the architecture has been built out in a test-driven manner the team has the exact amount of complexity that it can deal with a homogeneous architecture in different subprojects.
Suggested Read: Leading Agile Testers and Testing in at Scale Contexts
By Mary Thorn, Director of Quality, Ipreo
The Project Brain
After dividing the project into sub-teams, a team of analysts, developers, QAs, and managers are assigned to work on the big picture of the project “The project brain team”. After the division, each sub-team starts to be in its own world. They act like different organs in a human body. Each has its own function but they all need a brain to interact together. The overall project manager should have an overall vision of the project. He is responsible for planning the whole project and makes sure that sub-projects are going in parallel in a timely manner. Interdependent projects should have stories played according to the dependencies between these projects.
The master project manager is responsible for making sure that these stories are played in a timely manner to resolve dependencies and to be able to test integration between sub-projects as early as possible. Overall, the manager will have to manage the whole project plan according to sub-teams’ plans and their projected velocity. Managers have to make sure the project will deliver on time. If a team needs extra resources due to missed requirements or underestimation of stories, resources may be acquired from other teams that are ahead of the plan.
You may like: Embracing Agile For Faster Delivery
By Chris Johns, CIO, PNC Asset Management Group and PNC Investments, THE PNC FINANCIAL SERVICES GROUP