The World of Agile IT and Stakeholder Management

Agile Methodology

Why on earth would this BOK be into existence when there are loads and loads of documentation available on company archives that we can refer to during crunch times. So Am I reinventing the wheel ? No way. The below bulleted matrix would help you keep afloat in case you hit the agile monster or have butterflies in your stomach about Agile based projects and its future. So is Agile Immortal ? Humm ……….let me think. Well Almost for the current era. Agile is a way for product companies to substance their lively hood by ensuring they power pack their software products by business driven factors which we know as requirements, enhancements, UI features, and bug fixes. Agile is a way to build software using the small optimized revisions that resembles the iterative and incremental approach. This resembles as a scaled down approach of the predecessors. The key element to Agile is it ensures that the risks elements are at bay. The earlier methodologies have galvanized into the Agile and Agile would be a reflection of its predecessor’s best practices.

Kracking the Agile Monster Sprint=Requirement/s
One sprint would contain analysis, design, development, testing, and deployment. This sprint would form one delivery e.g. 1.0.1. The next sprint would be delivery 1.0.2 so on and so forth. There would be multiple such sprints across the project/product timelines scale. Meaning there would be multiple such sprints spanning the entire product life cycle from Inception phase till end of the product life span. The following diagram depicts Agile at the core.

Figure 1: Agile Process Architecture

Agile Vs Traditional
The below table compares the Agile Vs Traditional approach

Agile Roles
The following diagram depicts the overall governance structure for Agile projects

Stakeholders Management
Stakeholder Management is an important discipline that successful architects can use to win support from others. It helps them ensure that their projects succeed where others fail. The technique should be used during initial in the engagement to iron out the unknowns and streamline the operations management part of the engagement.

Risk Level Classifications
Impact classification Vs Risk Level for the Unknowns listed in the following sections

Risk Level	Impact Classification
High Risk	Major Timelines Slippages, cost and effort overrun anticipated if not taken care
Medium Risk	Minor Timelines Slippages, cost and effort overrun anticipated if not taken care
Low Risk	Negligible Timelines Slippages, cost and effort over anticipated if not taken care

Stakeholders

Acronym	Description
Prog Man/EM	Program Manager/Engagement Manager
BDM/AM	Business Development Manager/ Account Manager
DM	Delivery Manager
PM	Project Manager
Team	Consultants and Co
Customer	Customer
SME	Subject Matter Expert/Domain Expert
BA	Business Analyst
3rd Party	Vendors/Partners

High Risk Elements

Unknowns	Possibilities	Stakes Holder Matrix
Unknowns	Possibilities	Minimal Effort	Keep Informed	Keep Satisfied	Key Players
Would it only involve minor/major enhancement or agile based requirements?	Agile, Xterme, Crums	Rest	Prog Man	Customer	Team
Has the Customer Program Manager familiar/worked using the Onsite offshore model/GDM methodology?	GDM Methodology Appraisal (SLA, OLA etc)	Rest	EM	Prog Man	Customer
Is the network connectivity between DC and Customer facility already established?	Work with Internal and external IMG for connectivity. Before the delivery date of first sprint.	Rest	EM	Customer/ Prog Man	IMG External/ Internal
Are there other vendors currently looking into these pieces currently ? What is the team size interms of FTEs ?	This would give us a gusstimate on the kinda of resourcing effort	Rest	Account Manager	EM	Prog Man/DM
What are the target operating systems for the product lines? Will it be only limited to the server OS ?	Win 95, 98, 2K, 2K3, SKUs, server, home	Rest		Prog Man	Customer/ Team
In terms of compatibility would the new s/w need to be compliant with different set of H/W platforms ?	Pentium, Blade, Idanium	Rest		Prog Man	Customer/ Team
Has the effort already been estimated and what has been committed to the client ?	Estimated needs to validated from via Use Case/FP/Internal Methodology,	AM	Prog Man/EM	Customer	Architect
If its multi OS kinda environment we need to accommodate these into the estimates as well and the effort will shoot up considerably.	Use Case, WBS or FP	AM	Prog Man/EM	Customer	Architect
Does the ground work need involvement and support of non-delivery personnel	SME, Domain Expert or Vendors ?	Rest	SME/3rd Party	EM/Customer	Prog Man

Medium Risk Elements

Unknowns	Possibilities	Stakes Holder Matrix
Unknowns	Possibilities	Minimal Effort	Keep Informed	Keep Satisfied	Key Players
The component may have a dependency on other components and should be ready before we start the development of the said components.	Would Impact IT/ST/UAT phase, Server/Middleware components	Rest	EM, 3rd Party	Customer	Team/Prog Man
Is the staging environment already in place for testing? If not what is the timelines that the customer is looking for the staging environment to be fully operational for UT/IT/UAT testing of all use cases ?	Impact the delivery timelines. You got to flag this to the Stakeholders in advance and should be on the back burner till resolved.	Rest	Team	EM	Prog Man/ Customer
What kinda of testing will be required to be done by Infosys teams ?	Unit/Integration/ Systems/UAT	AM	EM	Prog Man	Customer/ Team
Are there any propriety tools planned to be used for S/W development activity ? viz CM, tracking, instrumentation	Clearcase, Bugzilla, FxCop, Visual Studio, Plans for training	Rest	EM	Customer/ Team	Prog Man/DM
Are there any propriety frameworks/solutions planned to be used for S/W development activity ?	Plans for training	Rest	EM	Customer/ Team	Prog Man/DM
A specific H/W requirement if this has to be executed from Offshore ?	Blade Servers	Rest	EM	Customer	Prog Man/DM
Are the technologies finalized for implementation phase ?	C#/C++/VC++/ASP.Net/Web Services, BizTalk, Code Generators, Frameworks	Rest	Prog Man/AM		Customer/ Architect

Low Risk Elements

Unknowns	Possibilities	Stakes Holder Matrix
Unknowns	Possibilities	Minimal Effort	Keep Informed	Keep Satisfied	Key Players
Are there any specific performance requirements for this software ? In terms of timing considerations?	Page load times, User loads, DB transaction/sec	Rest	Team	Prog Man/EM	Customer/ Architect
Is there any specific requirement on the size of the deliverable?	Less than 10KB	Rest	Team	Prog Man/EM	Customer/ Architect
Are there any particular non-functional requirements for the components ?	Scalability, security, modularity, extensibility, Performance	Rest	Team	Prog Man/EM	Customer/ Architect
Is the work limited to said component/s or it will also involve working on the dependencies and server pieces?		Rest	Team	Customer	Prog Man
Is there a planned ramp up time before the start of actual work ?	KT etc, at time you may be expected to hit the ground running	Rest	Team	Customer	Prog Man
What are the set of deliverables planned for the target activities?	Specs, Code, Instrumentation Reports, UAT, Impact Analysis docs, high level design specs	Rest	Team, Prog Man/EM	Customer	Architect/ PM
What will be the customer technology team’s role during different SDLC phases of the project ?	Governance, Reviews, Direction Setting		Rest	Prog Man	Customer
Do we need to interact with the Customer Business/Marketing/Sales teams directly ?	This needs to be sorted out before the start of the engagement as this would hog lots of Bandwidth in crunch times		Rest	Prog Man	Customer
From which stage would the customer want vendor’s involvement?	RA, Design, Construction Phase ?		Rest	Prog Man	Customer
Do we have a time to market for these pieces ? Do we have a product road map for these pieces/components ?	Product Roadmap	Rest	Team	Prog Man	Customer
What’s kind of Customer oriented process/methodologies do we need to follow as guidelines ?	Coding Standards, Check in/chect out procedures branching requirements,	Rest	Team	Prog Man	Customer

Passing Thoughts
So how would this so called check list benefit me and my track. Generally for the Agile Programs everything is agile in nature. The program manager, queries, the person sitting in the adjecent cubical, the dudes serving chicken curry in the B12 canteen. But a certain thing is every time there is new project requirement/s that comes to me I have a set of generic questions that would nag me till the final deliverable is handed over to the customer. This list contains few of those questions/queries/pain points. They are all legitimate in nature the key is when you may wanna apply them in real life problems or scenarios. There are specialized version of Agile that would be applicable to custom, package, legacy, web services but the core is what I have tried explaining in my artifact.

I believe the Agile, RUP and MSF are the big-boys of the Software Methodologies and we will get to hear of them more often that not in the coming quarters. RUP and MSF are specialization of Agile to a certain extent and at time things would hover above reality and beneath illusion and in which case I generalize all the lingos to the big dady - Agile Methodology. You may wanna check this check list even if your program manager is not bulling about Agile. Think about it.

References
http://www.agilealliance.com/home
http://www.extremeprogramming.org/
http://www.agilemodeling.com/