Tips for Successfully Delivering IT Projects With Constraints in Hybrid-Agile
“Manifesto for Agile Software Development ” was published in 2001. It says — we are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:
|Individuals and interactions||over processes and tools|
|Working software||over comprehensive documentation|
|Customer collaboration||over contract negotiation|
|Responding to change||over following a plan|
That is, while there is value in the items on the right, we value the items on the left more.
While textbook concepts are definitely helpful in delivering IT projects, it takes proven experience, smart planning, skills and ability to “foresee ” potential technical and non-technical issues in advance and planning for it.
Though a project can be completed by putting in extended hours, heroism by few employees, escalations and forced co-operation of the delivery teams; the skill is completing the project while working in constraints by carefully understanding the challenges of the ecosystem (people, process, technology) and executing the project within budget, timelines, scope, quality and resources.
This article is based on multiple experiences gained in “successful ” projects which received customer appreciations while working under constraints and in turn making it joyful for the customer.
Use planning stage well
Set aside a week or two only for planning. If you plan it well, execution will become easier. Accomplish following activities in the Planning stage.
- Solution Architecture. Based on overall picture, prepare the high level architecture and socialize it with customer’s architects and get their approvals.
- Define detailed Project Plan
- Define Product Backlog
- Define Sprint Backlog
- Sprints planning
- Risks identification
- Define dependencies
- Groom Sprint-1 stories
- Forecast things that will slow your Sprints and start working on future blockers at least a Sprint in advance so that by the time you’re in the Sprint you would have overcome them.
- Understand the “ecosystem ” constraints ‚Äì people, process, technology. Analyze them first and then review at all the stories and their dependencies.
- Get management buy-in for your overall “Best Case Scenario ” plan and start communicating and adjusting at the first sign of trouble. This will help in containing the damage to the minimum and also avoid blame games.
Utilize resources wisely
- Understand the individual team member’s capabilities, understand the team’s motivation reasons, levels and capabilities.
- Carefully and tactfully use the capabilities of all team members to the fullest by understanding what works for them and what not, and also their working styles.
- Do not forget critical resources. Consider risks associated with resources availability and new technologies and mitigate them.
- Use Monte Carlo simulation to plan for contingencies for risks associated with critical resources.
Less is more
Do not forget ‚Äì “Less is more “. Each product requires many features. Incorrect prioritization or delivering every feature might prolong the delivery. While keeping focus on what business wants to achieve holistically and what will make it successful, work with the team to prioritize the stories which will provide most value to the users.
Remember the Parento principle (80/20 rule):
“‚Ä¶ that a minority of causes, inputs or effort usually lead to a majority of the results, outputs or rewards. ”
If 80% of the results come from 20% of the requirements, focus on prioritizing them, deliver them quickly with quality. What is the point of making remaining 80% requirements as showstopper?
Due to this reason, it is a good idea to create a MVP (Minimum Viable Product) definition and prioritize its requirements first.
Review and analyze all the stories and the ones that are closely aligned to the central purpose should be added to MVP scope. This way business will have something that they can start using while you decide the path forward and priority of the remaining stories.
Limit User Story changes
If you’re executing a Transformation project, it means it has pre-defined end goals and fixed end dates. If you execute project in Agile, it is expected that story changes will need to be absorbed, but too many changes and additional stories mean spillovers and deadlines being missed. Following ideas can help in avoiding re-work and spillovers.
- Define the product backlog and get sign-off.
- Prepare a story backlog with good level of details as a first stage (call it Planning stage) of the project before starting any Sprints.
- Schedule Story playback sessions before the start of each Sprint. In this session, read the stories back to the business and IT teams to get them onboarded with the scope and functionality. This will help in iron cladding the stories and at the same time onboarding the team in your work. This will help immensely in the later Demos, Integration Testing and Acceptance Testing phases.
Plan Sprints smartly
- Make sure developers are productive from day 1 of each Sprint. Groom stories in the previous Sprint.
- Define a probability factor of dependency being resolved in time and plan around it.
- Any story that has more dependencies or you are certain it might slip due to external factors, always have a backup plan to be able to shuffle them with a future Sprint’s story and keep schedule on track.
- Keep foundation stories in early Sprints, followed by complex stories that cover the MVP.
- Make sure that foundation stories once developed are “treated ” as foundation by all parties, and no changes should be negotiable.
- Get commitments from other teams on which Sprints have dependency (e.g. services, test data, product data, environments availability and test user’s availability etc.).
- Plan final Sprint with very minimal scope initially. This Sprint will act as a buffer to absorb any slippages and new stories. Typically, in Agile projects, there will be new stories identified when you demo the completed Sprint’s work.
Don’t forget the customer
- Your customers depend on your delivered product, services, and expertise you bring on the table. Have mid-Sprint and end-of-Sprint demos for key end users, so that you get any surprises early while you are still building the product. This will help in iron cladding the developed product.
- Define UAT scenarios early and review and get sign-off of them while still in the Sprint execution. This will weed out any missed (new) requirements before you go into acceptance phase.
Use graphic methods in status report and wherever else possible (e.g. Design) instead of long texts. Graphic methods and tools e.g. tables, pictures, symbols are easier to understand. Keep project reports concise and to the point.
Product Owner should play an effective role as it is expected from him – proactively.
Role of Product Owner
This role is an important part of any product development approach, irrespective of the approach being taken and is a critical success factor.
As the organization is still midway through the journey towards Agile, Product Owner role should be instituted first. Product Owners are there on behalf of customer’s business. They provide clarity of vision, alignment with organizational strategy, understanding of the development process and the ability to communicate with a wide variety of stakeholders across all levels, both inside and outside the organization.
Recommended Project Management Software
If you’re interested in learning more about top rated project management software, the editors at Project-Management.com actively recommend the following: