Tag Archives: continuous improvement process

agile tips to avoid failure Digital Rehab

How to ensure project failure using agile

Given business’ love affair with ‘continuous improvement’ and enterprise agility, I want to take a moment to pause and reflect on some of my learnings (both observations and from first hand experience) along with identifying common ways agile can fail.

Ofcourse no new program aims for failure yet having witnessed and learnt from past experience, I can tell you what conditions and factors are usually present which lead to doomed projects and change programs.  If any or a blend of the following exist, the fundamentals of the program/project(s) will likely fail: poor planning, poor or inexperienced/ill-equipped or ill-informed teams, lack of communication, false or unrealistic expectations, absence of executive buy-in and sponsorship. See elaborations below which should serve as some tips for completely failing in agile project management: 

Piss poor planning 

One of the greatest non-truths around agile is that planning and structure aren’t essential. This is rubbish!

“Agile is not an excuse for poor or loose project management,” says Alisdair Blackman, founding principal of Digital Rehab, a firm that provides project management and agile expertise.

Too often, the business vision and roadmaps are ambiguous — too high-level for engineers to execute upon — but using a framework that can be broken down into checklists ensures alignment and provides constant reminders that keep a given project on track. 

The agile release train (ART) is a basic planning tool that aligns individual teams to a common business and technology vision/set of requirements.  ART can help serve to plan sprints (a set period of time during which specific work has to be completed and made ready for review), manage and estimate resources required and some cases even frame up costings. 

“Businesses that use agile development methodology efficiently can plan projects 6-12 months in advance, with high accuracy stemming from their experience and knowledge of their own capacity and capabilities and will most often deliver successful change,” Alisdair Blackman says.

See also my earlier article around the role and importance of proper planning

Mobilising an inexperienced team

Complimentary skills across an agile team is key to the success of any project or program.

“If you have a team that have worked together and are cohesive, allow them to continue to refine and deliver playing to each other’s strengths and weaknesses”

Resource management is essential regardless of how and what methodology is used. I would always recommend spending time during the initiation phase of the project to assemble the right team that have complimentary skills and experience, availability (bandwidth) and gauge the level of engagement and positivity across your team toward the body of work. 

In a perfect world, agile teams should be self-sufficient and ideally comprised of generalists rather than specialists ensuring depth of experience while possessing both technical and business acumen.

Silence is golden

Agile teams with poor communication skills or who do not engage with others in the business are rarely successful. 

Free flow of information is a critical success ingredient in those organisations that embrace a continuous delivery mindset.

Agile demands frequent communication across all stakeholders in the business specifically the program owner, sponsor, steering committee and any other key persons.

Communication can take a variety of different forms but daily stand-ups and sprint retrospectives provide excellent check-ins for key stakeholders and offer the optimal setting for iterative correction/refinements to be agreed and in this setting the team can share learnings. 

It’s also important to get all agile teams together so that they can see how each team communicates and they can all strive for consistency eg. using the same nomenclature / terminology. With agile, there are alot of acronyms and I have observed that many executives can be confused. Consistency in language across all agile teams is a way to mitigate risks that arise from confusion. 

Poor Executive buy-in and support

The Agile way, if executed and followed properly should ensure business leaders and influencers are engaged and on-board from the very beginning. It’s important that before you start an agile project/program of work that you make sure someone at the top supports it, can remove obstacles as and when they present themselves and provides context of the project across the business.

The best way to win support is to demonstrate that both the agile method to be used as well as the mobilised team will meaningfully increase the chances of a successful project delivery. 

See previous article which calls out the importance of strong executive leadership in digital transformation

Testing…why test?

Testing is absolutely critical – be it unit, functional or integration. 

Many agile teams use test-driven development practices which would see the creation of test cases written before coding starts. There are also considerable automated testing tools that can be run over the code to continually validate.  With agile, at the end of the day, it is the project sponsor and owner that need to verify that the output created works to satisfy the initial requirement/aligns to the vision ahead of deployment/launch/release.

Ignore feedback

The Feedback or Review step is integral to agile development, delivery, deployment and to continuous delivery.

For continuous delivery environment to be created, feedback needs to be embraced and woven into daily agile management of a project/program of work. Unlike the approach taken some years ago where feedback would only be sought at key project milestones/decision gates – agile hinges on continuous feedback being received, interpreted and acted upon.

Needless to say, agile teams need feedback to inform their retrospective at the end of iteration. This feedback and the outcomes of the retrospective then stimulate further process improvements that can be implemented in the next build cycle.

Agile views feedback (be in internally or externally provided) to be pivotal in all aspects of planning and development and this itself increases the stickiness and traction of the project and will represent increased value in the output created.


Alisdair Blackman and Digital Rehab were recognised as 2017 Top 25 Most Promising Agile Solution Prodivers in Asia

APAC CIO Outlook Agil Providers Award

That's all Folks - Importance of a Project Closure document

Importance of Project Closure Document

Project closure, for me can consist of several processes depending on the scope of the project. It can serve to:

  1. Confirm that the work is done to satisfy a set of agreed requirements
  2. Complete the procurement closure
  3. Gain financial acceptance of the project/product
  4. Complete financial closure
  5. Hand off complete project/product
  6. Solicit feedback from the customer(s) about the project/product
  7. Complete the financial performance reporting
  8. Index and archive records
  9. Gather key learnings / insights

Regardless, a project closure event, requires that learnings, new knowledge gained be recorded and factored into continuous improvement process – in line with best practice.

The diagram below follows a Sigma Six process improvement process. Most importantly, it stresses the importance of Analyse, Improve & Control. A project closure document aims only to tie off a phase or discrete body of work prior to the commencement of another. 

Lessons Learned

Even the most successful projects have lessons from which we can learn from. Whether you’re upgrading an IT system, any data project or transformative body of work, there will be lessons you can learn from your project. An effective Project Manager documents and analyses the lessons learned from his/her project and applies them to future projects throughout a business.

Post Project Review

It’s good practice to review all projects at their completion. A Post Project Review should be performed in addition to a Lessons learned. Reviewing your project to see how actuals compared to planned gives you a good sense for the project’s overall performance. The post project review along with Lessons learned provides meaningful input to future projects and are quite often equally important as the delivered output.

Project Acceptance

Formal Project Acceptance requires a signature by the Project Sponsor or Customer. Before a project can be closed out the Project Manager needs formal acceptance of the project by the Project Sponsor or Customer. Formal acceptance is one step of the close-out process and doesn’t release the Project Manager or resources from the Project. It is the Project Manager’s responsibility to release resources during the closing process and ensure that all closing tasks are completed.