In search of business value - moving from Waterfall to Agile

By now Software wide-spread presence across all walks of life is being felt by all specially with emergence of social media & mobile devices recently. Pace at which software need to be delivered to market to meet users’ needs was never so fast.

In this dynamic world, sticking to traditional software development methodologies is highly risky as it may fail to meet target users expectations in desired time.

Software products/ applications need to be developed in an iterative way building features by features. Edward Deming’s PDCA (plan-do-check-act) is an iterative four-step management method used in business for the control and continuous improvement of processes and products. It is the foundation for lean thinking. This is great if you are in an established market. Colonel John Boyd, a military strategist and fighter pilot, developed a similar concept known as the OODA (observe, orient, decide, and act) loop. This is very good if you are in a highly volatile marketplace.

In past, Organisation have used waterfall SDLC model in iterative way to reduce risks and to speed up deliveries however they are now adopting to Agile SDLC methodologies to deliver  business value to project sponsors.

in 2010, Gartner’s analysts (Thomas Murphy and David Norton) predict that by 2012 “agile development methods will be utilized in 80% of all software development projects”. The authors explain that although Scrum will continue gaining in popularity over the coming years, organizations will not be successful in their transition unless they move toward a team-focused culture.

Agile projects are successful three times more often than non-agile projects, according to the 2011 CHAOS Manifesto from the Standish Group.

Agile Manifesto emphasize on following four core values

 •             Individuals and interactions over processes and tools.

•             Working software over comprehensive documentation.

•             Customer collaboration over contract negotiation.

•             Responding to change over following a plan.

While Agile project management methodologies delivers value, one should perform organisations agile readiness assessment before adopting agile practices to better identify opportunities which can be best served using Agile Practices.

3 main pillars of Agile Assessment are People, Process (incl. Organisation Structures) and Technology.

- People

It assesses things like the current people capability, the perceived capacity for change, the staff demographics (PM, BA, QA) by roles and the organisational recruitment plans. It’s important to get early line of sight in these areas as it’s important to develop plans to improve skills and change the ratio of roles early.

- Process

It measures the current process capability prior to introducing any change. Value-Stream Mapping technique helps us to get a good understanding of the current process efficiency and helps to identify good places to start our improvement activities.. portfolio: the blend of projects, size, cost and other similar information. This helps us to identify good pilot projects and identify any challenges that we are likely to face integrating our new processes at a portfolio management level

- Technology

Assessments in this space are best focused around reviewing the architecture strategy and standards to identify potential pain points.

I think all organisations in the business of software applications development should perform agile readiness assessment to find out where do they stand and what all they need to address to start this change to deliver business value to its stakeholders.

How can one avoid illusions about Project Plans

People need Project Plans/ Project schedule to showcase how a particular work execution can be completed in given time and to highlight associated assumptions/ risks.

Different PMs/ Organisation uses different scheduling software tools like MS Excel, MS Visio, MS Project, Primavera, Open Work Bench, Soho Project, Attack, Bright Work, Hyper Office and many others however due to lack of trained project managers these tools often end up showing some schedule which is more of illusion of reality rather a dynamic execution model to guide the project team.

Understanding of key scheduling concepts and knowledge of applying them using some scheduling software can provide really very effective results.

Often people making project schedules, do not know enough about given project context and unable to model that project information into a project schedule which can show how entire project journey can be completed.

All schedules are based on some key assumptions and risk mitigation plans, often this information is not captured and shared with key stakeholders for their agreement and as a result this project schedule becomes irrelevant very soon.

They merely serve as PM support tool to manage some project reporting/ briefing obligation rather than a project execution guiding model.

Project schedules need to evolve as we gather more and more details about execution of work packages/ risks and should have enough clear tasks for team for next 1-2 months.

Project Schedule should be capable of predicting delays impact on project finish dates so take appropriate control action immediately.

Pl. does share if in your organisation, project execution is driven by project plan or project plan is driven by project execution as it happens.

How to identify inbuilt flaws responsible for project failures early

Many projects life cycle can be classified into just two phases -
Too Early to Tell where they are heading and Too Late to Stop failures.

We all know that most of the projects over run agreed baselined budgets, timelines and some even compromise with minimum acceptable quality levels of project deliverables.

No project fails in a day, failure is built brick by brick over many weeks and months by overlooking many poor project health symptoms. As success doesn't come all of a sudden so does failures. Many times projects have flaws from project definition stage itself - it could be around unrealistic goals, timelines or dependence on some yet to be proven cutting edge technology.

While project issues & risks are to be managed well to mitigate their impact on project, it is equally important to review basis of project sizing, key assumptions & techniques used to arrive at feasible timelines (e.g. are you using single point duration estimates for R&D type of project tasks?), WBS and tasks dependencies validation by experts/ sr. members, resources & vendors skills & competency levels and 3rd parties work products integration commitments.

Often, many of these aspects are over looked which then add up to the problems in later phases of project. They were never a surprise in the first place. A periodic project review of actions taken to manage project issues and actions done for mitigating project risks can also reveal some of these underlying problems which were present right from project foundation stage.

Some time lack of a competent project manager is also a major reasons why projects move on failure paths. Project manager soft & technical skills with reasonable domain understanding plays a critical role in uncovering issues early followed by proper action plan to manage them.

Project audit by PMO or some independent consultant is often a good way to unearth project grey areas which may turn into big issues later.