Agile is a subset of Iterative and Incremental development (IID).

i.e. A team could have incremental and iterative development without being agile.

i.e. an agile team needs to have additional tenets in addition to being iterative and incremental

1.       Self organizing teams: Empowered teams help organize and deliver better results

2.       Adaptive and emerging plan: Project plan (scope, delivery and cost) needs to be adaptive to emerging requirements

3.       Potentially shippable software: Producing software that can be truly useful  to business is critical to agile success
Picture
 
 
Since each solution will be situation specific, let me give you a scenario and how we fixed it.

1. The scenario: We had challenges in ensuring "Business people and developers must work together daily throughout the project."

The development team was in corporate head office. Business teams were geographically dispersed in three time zones. The task was to build one solution that fits all.

2. The solution.  We realized early on that we need a product owner from each business unit. But, team was getting pulled in different directions due to differing priorities for the business units. I worked with the product sponsors and got a proxy product owner on site. His job was to make sure the development team receives clear communication on what needs to be built. He was also tasked with identifying differences, creating stories and prioritizing.

3. The result.  With one proxy owner always available to the team in the same time zone, we spent lot less time discussing and more time building application. Also the process of identifying differences, helped us to find non-it solutions to meet every product owner's needs. Ultimately we got "Better software in faster"

 
 
Yes! Continuously look for better solution rather than implementing stories/ requirements

Key is to understand the agile spirit inside the agile manifesto.

 “…better ways of developing Software..”

We need to constantly find better ways to deliver the software faster, cheaper and meeting customer needs by valuing

1.       Individuals and interactions over processes and tools

2.       Working software over comprehensive documentation

3.       Customer collaboration over contract negotiation

4.       Responding to change over following a plan

Lot of scrum teams loose out because they forget to find better ways. They are in a mad rush to meet sprint commitments. Don’t discuss with product owner or business what would meet their needs. As a result we end up building software that is lacking in

1.       Innovation

2.       Quality

3.       Customer value

I have had teams write bunch of test to ensure high code coverage, but forgot to check if the original code was meeting business needs. These teams met commitments by putting extra hours to correct the UAT bugs. Is that success? No

I have had teams become hyper-productive by simplifying the stories and finishing them in half the allotted time. This team could pull extra stories or take time off to finish training, reading, environment upgrade etc.  Is that success? Yes

 
 
Introducing agile into an organization implies significant change from the previous ways of doing things.

I would like to bring the famous quote from Machiville to bring things into perspective: “..The innovator has for enemies all those who have done well under the old conditions."

There is bound to be detractors and people sitting on the fence. How well you deal with them determines long term success of the agile program.

What would a detractor want? He would want you to get derailed from your goals and fail in delivering.

Recommendation: keep away from confrontation, and ask them to identify the issues and risks they see and deal with those at a risk and issue management level.

 
 

The time tested way to explain something is by practical example. I would suggest walk them through how something could be done differently using Lean principles.

You don’t have to choose a $30 mn project to demonstrate the difference

Give him a “Lean” answer to his question and a elaborate answer.


Lean answer: Getting work done minimizing waste or time, money and resources


Now an elaborate answer could be:
“Lean is a management theory ...... develops ability in people to use a disciplined approach blah blah blah Yawn blah blah blah! To sum up I will schedule a 2 hour time next week to walk you thrugh 52 slides (???) and I will order a copy of my new book Lean thinking…….. My company will give you a proposal for transforming – Now get lost”
 
 

In a software development context:
Budget is what business is willing to spend in a time period (yearly, quarterly, monthly…) for a business benefit. The budget is determined based on a business case which identified cost and benefits, ROI etc.
Estimate is what team believes it will take to build a defined scope.
What is the relation between the two? Many-to- Many i.e.
•    The estimate can cover multiple budget periods
•    One budget can have multiple estimated components
Estimates are made multiple times during the project.
•    High level estimates provide inputs for budgeting.  These estimates are done with 20—50% accuracy and are used as inputs for business case and budget approval
•    Detailed estimates help planning and execution of the project. Detailed estimates are made at a task level. The accuracy of the detailed estimates changes with how far into the future the estimates are. i.e. estimates for work to be done in next 5 days is fairly accurate and estimates for work to be done 3 months later can be vague. Agile models try to use shorter term (1-3 weeks) for detailed estimation. Waterfall models try to estimate the entire project in advance and hence, build contingency to deal with the uncertainty in the estimates.

 
 

It infrastructure projects are in fact ideal candidates for agile. Most of the IT shops operate in a agile fashion i.e. 1 tracker at a time.
You can bring the ITIL best practices and agile best practices together to be executing infrastructure projects in an agile fashion:
1.    How do we define business value? The three critical phases of infrastructure upgrade projects can be described as three waves of change to stakeholders
a.    Wave 1- Stabilize: Define maintenance window, reduce unplanned changes, reduction in fire fighting
b.    Wave 2 – Upgrade: Define metrics for response time, MTBF, MTTR. Try to achieve the desired availability.
c.    Wave -3 - Optimize: In this phase a change must be analyzed using ROI.  
2.    Start small. For example try to stabilize one server first. Define business acceptance criteria such as: No unauthorized changes, 1 incident per month etc
3.    Each activity should be related to a user benefit and prioritized to ensure that you are building the most critical pieces first.
4.    Follow the “ICD Design Planning” best practices to verify the designs iteratively using proof of concepts
5.    Follow “ICT Deployment Management” best practices during build, test and roll out phases

 
 

Testing is context and environment specific. So it is tough for me to tell whether you will write functional tests, integration tests of performance tests for your product.
However, agile methodology and practice influences when and how to test
See Below

Picture
 
 

In Scrum we produce “potentially shippable product” at the end of each sprint. However, there is a bunch of activities required to move the product from potentially shippable to shippable.
Once the product reaches a feature completion form product owner perspective, we run a series of release sprints to make it shippable. The “Release Sprints” captures activities like:
•    Clear technical debt that must be fixed prior to release
•    Training and handover to support staff
•    Cut over and fall back planning
•    UAT (1-2 rounds)
•    Integration testing
•    Full Regression testing
•    Running pre-release tests for load and performance
•    Fixing prioritized defects
•    Create builds for each environment (staging, production, UAT etc.)
•    Populate/ migrate production data
•    Move through the various environments and release to production

How many release sprints would we need?
•    It would depend on the size and complexity of the project.
•    How often we do releases? If we release features incrementally, release sprint will be shorter.
•    If the team has followed good development practices along the way, we might need very short number release sprints.

Who will be the team members of these release sprints?
•    It would be a sub-set of the original development team plus the additional stake holders like operations support team
•    Ideally the remainder of the team would be available for consultation and working on the next release

 
 

People will hate agile if they don’t know what to do with all the information they get out of agile models.

Agile methodologies provide lot more information compared to traditional models. We know about deployment problems in first couple of sprints, we talk about knowledge gaps days into the project, we get to know communication problems within hours.

The obvious problem is how do we deal with all of this information? Should the top management jump panic every time sprint burn down is above the line? Should the team forcibly swarm on a task that is behind? Does missing a committed story to accomplish a deployment task mean sprint is a failure?

So anyone can hate agile, it can be anyone: Team members, stake holders, pigs, chickens whatever you call them.

Often this happens when we impose the methodology, rather than evolve or blend it into the culture.

Organizations apply different methods to fix this problem. The most common being training and coaching.  I would recommend doing both. Trainer will get you all functions of a car and a coach will sit next to you even drive it for a while.