Pdu session challenges in agile

Welcome tothe PDU session on

“Challenges on Agile projects”

Bhawani Nandan Prasad

Objectives

Differences between traditional methods and Agile Challenges on Agile projects

Caused by Agile or Exposed by Agile?Integration challenges on complex projectsDealing with technical debtBlocking issuesEducation of stakeholdersHeavy R&D and design requirementSupport distractions

Summary Q&A

Bhawani Nandan Prasa

Differences in traditional and Agile methods

Agile relies on incremental and iterative development

A deliverable is produced every few weeks (1-4 weeks) at the end of the iteration

All the engineering activities need to completed within the time-box of the iteration

Code at the end of the each iteration needs to be “near releasable”

After certain number of iterations (when substantial value is created), the release concludes

Bhawani Nandan Prasa

Caused by Agile or Exposed by Agile?

Ask the question – is this challenge “caused by Agile” or is it “exposed by Agile”?

Examples:

Unreliable estimates

Distributed teams

Immature teams

Agile does not fix all the dysfunction – but it will expose it sooner!


Multiple teams; Integration challenges

What is the challenge?

Dependencies between teams need to be coordinated

Integration between teams as they are in parallel development

Caused by:

Agile teams are small

Large products or applications will have multiple teams working in parallel


Multiple teams; Integration challenges

How to address?

Call out dependencies early and plan ahead

Plan for buffers for any hand-offs (“look ahead planning”)

Publish interface definitions and integrate using mock interfaces

Automated tests to validate integrations frequently


7

IC (Iteration Cycle) Topology Discovery 1.4 Features & Dependencies

Product = <name> IC #1 IC #2 IC #3 IC #4 IC #5 IC#6 IC >6

Key Features/

Themes in IC

1.Asset & Network Discovery (without Topology)

1.Marimba agent detection

2.Normalization/reconciliation of Windows data with CD

1.Normalization of Windows and Unix # 1

2.Marimba agent detection –queries and GUI configuration

• Normalized Unix and Windows asset discovery # 2

• GUI-based Domain import

• New database support (Oracle 10g, SQL Server 2005)

• GUI wizard optimization (grouping methods)

1.TD model convergence to CDM (Classes and atributes)

2.Unix & Windows normalization

3.Map sharing4.CMDB export

(filtering per instance via GUI)

5.Wizard parameters ordering

1.GUI features and model change finalization

2.Other discoveries and asset data normalization (tokenid generation and export to CDM)

3.Domain hostname management (allow hostname entry)

4.Wizard paramenters ordering

1.Bug-fixes2.Integration with any revised

CMDB drops3.Documentation

Delivered On:

Best Case Date =Most Likely Date =

Worst Case Date =

12/20/2006

12/16/2005

12/23/2005

1/17/2006

01/13/2006

01/17/2006

01/21/2006

1/31/2006

01/27/2006

01/31/2006

02/06/2006

02/16/200602/10/2006

02/14/2006

02/21/2006

02/21/2006

02/24/2006

02/28/2006

3/1/2006

3/6/20063/8/2006

Product dependencies (need) IC #1 IC #2 IC #3 IC #4 IC #5 IC #6

<Project>

(by worst case date)

CMDB 2.0 locked down

12/9/2005

Marimba CD drop

1.CMDB drop early access (~2 days prior)



CMDB drop early access (~2 days prior)

CMDB drop early access (~2 days prior)

<Project>


CMDB needs Asset & Network for Recon

<Project>


Technical debt


Work that needed to be done during the iteration did not get done

E.g. All tests did not run, defects pending

All the debt accumulates till the end

Caused by:

Running out of time while trying to complete features

Tendency to claim success even when it is not complete


Technical debt

How to address?

Define clear “Done criteria” and adhere to it strictly

Plan for periodic “stabilization” or “hardening” iterations to remove technical debt

But resist the temptation to rely too much on “hardening”!

Be transparent about the existence of debt

Plan for metrics and thresholds


Iteration “done” criteria (example)

Software with all features work as defined by the user story

All QA testing for completed features is done with no pending defects

Regression tests pass

All documentation is completed

Planned stories demonstrated to the Product Owner, Customer and other stakeholders

Copyright (c) Sandeep

Shouche, PMP, PgMP, PMI-

ACP, CSM

Blocking issues


If the team gets blocked by any issue (even for a few hours), the success of iteration is compromised

Caused by:

Iterations are very short – not much time to recover

How to address:

Encourage team to bubble up blockers quickly

Scrum Master/Project Manager needs to be pro-active in tracking these issues


Education of stakeholders


The team follows Agile principles, but they are not supported by other stakeholders; e.g. Unrealistic expectations, top-down management

Caused by:

Everybody having different expectations from the methodology

How to address:

Give quick primer/introductory Agile training for the stakeholders

Do NOT use Agile if customer and management are not on-board


Requirements intensive on design, R&D


Some requirements are complex and/or require a lot of R&D

It takes a while to design the basic framework for a system

Caused by:

Iterations may be too short to absorb the R&D and design activity

How to address:

Spend time on analysis and design but time-box it (write research or SPIKE requirements)

Get used to “just-enough” and evolving design


Support workload disrupts development


As the team is working on a new version, they are distracted by issues and defects from the previous version (support issues)

Caused by:

Support activity tends to be ad-hoc by nature and can disrupt iteration schedule

How to address:

Reserve time for support activities

Form a dedicated “sustaining” team to ring-fence and protect development activity


Summary

When you encounter an issue or challenge while working on an Agile project, first ask yourself the questions – “Is this caused by Agile” or “Did Agile expose this”

There is always a way to tweak the methodology to help address an issue – process tailoring is required

Use the methodology as a “starting methodology” and evolve your own based on what works for you

But make use of discussion forums and available sources of guidance before re-inventing the wheel!


Thank You; Questions?


Technology

Pdu session challenges in agile