Agile Leadership

The chances for software to succeed are much higher if you have a leader (not Manager) working in it. The difference between a Leader and Manager is well explained by Warren Bennis: “Management is getting people to do what needs to be done. Leadership is getting people to want to do what needs to be done.”

What distinguishes leaders from managers?

1. Leaders are interested in direction, vision, goals, objectives, effectiveness and purpose. Managers are interested in efficiency, both day-to-day and short-run.
2. Managers administer while leaders innovate.
3. Managers focus on systems and structure; leaders focus on people.
4. Managers rely on control; leaders inspire trust.
5. Managers have their eye on the bottom line; leaders have their eye on the horizon.

The best leaders care about both the small and big pictures. They sweat the details -- but they also have the ability to make people feel valued ... to inspire and energize them, to nurture their creativity and to encourage them to take risks and learn from their mistakes. The top qualities of Leaders are:

• Character: Should be honest and must understand the gravity of words; That’s the key quality of a leader.

Sharing with you Jim Kouzes and Barry Posner, (http://www.leadershipchallenge.com/) 10 year study results where they’ve asked over 75,000 people to select top qualities of a Leader,
from a possible list of 20 values:











The results are shown in figure below
















Honesty on the top !

• Technical competence: Technology and domain expertise. Ability to help and solve project issues.
• Clear Vision: Leaders know their goals and way to reach their in time.
• Team handling and Communication: The ability to communicate, motivate, delegate and ability to identify and cultivate talent in team members.
• Decision Making: Ability to take quick and right decisions

Incredible 4 years...

Today (July 10, 2007), I have completed 4 years in Trisoft Systems. This has been my first job change, RMSI being the first employer (3.5 years). It was a tough decision for me to choose between TCS and Trisoft. I’m glad I’ve taken the right one. I've been fortunate enough to have had the opportunity to work upon quality solutions with latest technologies here in Trisoft.

Working as a Solutions Architect now, I started here as BizTalk developer. My first project was based on cXML integration that was a success. Another important milestone was Catapult, we did this project for Microsoft Redmond. The product was appreciated and accepted (in time) and is now being used in various departments in Microsoft Redmond.

This has been an incredible journey where I've witnessed a number software renovations and my perspective of software has been improved a lot…from coding to usability, job completion to profitability and documentation to agility.

We’ve moved to a much bigger office in Noida (India), more determined to grow fast in coming years. You never know where I would be next year…but so far it’s so good and I love being here.

Glossary

Following are the key-words used extensivly in Agile world; you must be aware.

SCRUM
http://en.wikipedia.org/wiki/Scrum_%28development%29
Scrum is an iterative, incremental process for developing any product or managing any work. It produces a potentially shippable set of functionality at the end of every iteration. Scrum is a set of interrelated practices and rules that optimize the development environment, reduce organizational overhead, and closely synchronize market requirements with iterative prototypes. Based in modern process control theory, Scrum causes the best possible software to be constructed given the available resources, acceptable quality, and required release dates. Useful product functionality is delivered every thirty days as requirements, architecture, and design emerge, even when using unstable technologies.

Pair programming
Pair programming requires two programmers to participate in a combined development effort at one workstation. Each member performs the action the other is not currently doing: While one types in unit tests the other thinks about the class that will satisfy the test, for example.
The person who is doing the typing is known as the driver while the person who is guiding is known as the navigator. It is often suggested for the two partners to switch roles at least every half-hour or after a unit test is made. It is also suggested to switch partners at least once a day.

Test-Driven Development (TDD)
http://en.wikipedia.org/wiki/Test_driven_development
Test-Driven Development (TDD) is a software development technique that involves repeatedly first writing a test case and then implementing only the code necessary to pass the test. Test-driven development gives rapid feedback. The technique began to receive publicity in the early 2000s as an aspect of Extreme Programming, but more recently is creating more general interest in its own right.
Practitioners emphasize that test-driven development is a method of designing software, not merely a method of testing.
Along with other techniques, the concept can also be applied to the improvement and removal of software defects from legacy code that was not developed in this way.

Feature Driven Development
http://en.wikipedia.org/wiki/Feature_Driven_Development
Feature Driven Development (FDD) is an iterative and incremental software development process. It is one of a number of Agile methods for developing software and forms part of the Agile Alliance. FDD blends a number of industry-recognized best practices into a cohesive whole. These practices are all driven from a client-valued functionality (feature) perspective. Its main purpose is to deliver tangible, working software repeatedly in a timely manner.

Aspect-oriented programming
http://en.wikipedia.org/wiki/Aspect_Oriented_Programming
In software engineering, the programming paradigms of aspect-oriented programming (AOP), and aspect-oriented software development (AOSD) attempt to aid programmers in the separation of concerns, specifically cross-cutting concerns, as an advance in modularization. AOP does so using primarily language changes, while AOSD uses a combination of language, environment, and method.
Separation of concerns entails breaking down a program into distinct parts that overlap in functionality as little as possible. All programming methodologies—including procedural programming and object-oriented programming—support some separation and encapsulation of concerns (or any area of interest or focus) into single entities. For example, procedures, packages, classes, and methods all help programmers encapsulate concerns into single entities. But some concerns defy these forms of encapsulation. Software engineers call these crosscutting concerns, because they cut across many modules in a program.

Adaptive Software Development
http://en.wikipedia.org/wiki/Adaptive_Software_Development
Adaptive Software Development is a software development process that grew out of rapid application development work by Jim Highsmith and Sam Bayer. ASD embodies the principle that continuous adaptation of the process to the work at hand is the normal state of affairs.
ASD replaces the traditional waterfall cycle with a repeating series of speculate, collaborate, and learn cycles. This dynamic cycle provides for continuous learning and adaptation to the emergent state of the project. The characteristics of an ASD life cycle are that it is mission focused, feature based, iterative, timeboxed, risk driven, and change tolerant.

001 - Requirements Clarifications

In the Agile scenario, “Active stakeholder participation” throughout the project's lifecycle is described as one of the key success factor.
Though there are now doubts in above said point, the issue comes when you have stakeholders coming from a complete not IT background and it’s difficult for them to perceive the functional software. Sounds wacky? It’s common in South Asian countries, especially in the government departments. Such stakeholders are defined as: “End users who tells you what they really want on the day you give them what they've asked for”. Oops, I can know what I really want is only after seeing it.

Another thing I’ve faced is the “tale of never ending open requirements”. The project is kicked-off, teams have been finalized and stakeholders are identified for requirements clarifications. Users keeps on explaining about the functional requirements and issues they face with the existing system. In the middle of a requirement clarification (asked from software analyst) the user realizes that they’ve missed something…and here comes the brand new feature that turns out to be one of the key requirement of the software. Poor analyst, curse himself why the hell he asked for the damn clarification. Now by end of requirement phase, you’ll actually see little projects, trying to pop out of the additional (key) requirements.

These are the most common scenarios that are bound to happen during the requirement analysis phase (in this part of the word). The waterfall method by no means can address such challenges. Agile may be helpful is some situations, or al-least minimizes the risks.

Successful (Agile) Requirements Analysis Rules (for Nerds):

The #1 rule reminds me a quote I’ve seen on internet; called - Hoggarth's Law Reworded by MHR from Chris Hoggarth's email October 2006. It says “Attempts to get answers early in a project fail as there are many more wrong questions than right ones. Activity during the early stages should be dedicated to finding the correct questions. Once the correct questions have been identified correct answers will naturally fall out of subsequent work without grief or excitement and there will be understanding of what the project is meant to achieve.”

That’s the Rule #1: Prepare yourself first, do the homework before you start collecting requirements. Be sure of what you need to know from user (and what not).

Few months back, I was looking for a Air-conditioner and saw an advertisement of a electrical retail chain in the newspaper. They were selling the 1.5 ton A.C. for Rs. 13,000. It was the best deal I would get anywhere in summers so I went to this shop to place an order (Also took the newspaper for reference). I asked the sales guy that I am willing to buy the A.C. that costs 13,000 bucks. He replied that it’s the exchange offer and also the cost depends on the condition of the old A.C. I was surprised and showed him the newspaper where the exchange condition was nowhere mentioned. Now, this guy show me a small (microscopic) * in the advertisement that says “conditions apply”. I was shocked.

Rule #2: Be transparent and set the expectation right from day one. Don’t make too much assumptions in requirements.

The extension of Rule #2 is the rule of communication (language). Even if I had seen the “condition apply” (using magnifier), It was still difficult for me to understand what exactly does it means. The description of “conditions apply” must be given somewhere in the advertisement so that customer like me are not fooled around.

Develop a method to communicate with customers. Generally end users understand the user interface they are going to work with. Developing a UI prototype during the analysis would be of great help to end users and requirement analysts.

Rule #3: If it's is not on a paper it's never been said. Document each requirement clearly and maintain it’s relationship (traceability) in each phase.