Agile development teams live and die by their code. Many have found in practice that ?good? agile code is extensible, low-defect code with the simplest robust design that will work for the features currently implemented. Among the agile methodologies, Extreme Programming (XP) goes into the most depth concerning how programmers can keep themselves and their code agile. Below are some new skills that agile teams need to embrace.

Simple Design

Agile teams are under pressure to deliver working, tested code at the end of each iteration and their code must be capable of turning on a dime at any moment. So agile teams place enormous value on the extensibility of their code: the extent to which they can easily maintain and extend it. The other key component of extensibility is design simplicity. Extensibility seems to be inversely proportional to design complexity.

Refactoring

Refactoring is the process of clarifying and simplifying the design of existing code, without changing its behavior. Agile teams are maintaining and extending their code a lot from iteration to iteration, and without continuous refactoring, this is hard to do. This is because un-refactored code tends to rot. Rot takes several forms: unhealthy dependencies between classes or packages, bad allocation of class responsibilities, way too many responsibilities per method or class, duplicate code and many other varieties of confusion and clutter.

Breaking Down Work

Agile methods promote taking large projects and breaking them down into a coordinated series of smaller projects developed by smaller, cross-functional teams. The various teams? work (i.e. code) is integrated at least every iteration in order to reduce risk and ensure functional and technical compatibility.

Continuous Planning

An incremental approach to planning allows for initial planning at a high level, and iterative planning at lower levels as more knowledge is gained. As teams begin to learn what they can deliver on a daily, weekly and monthly basis, they become more accurate at both their short- and long-term planning abilities than they ever were with traditional planning approaches.

Providing Input

Collaborative decision-making techniques are important because agile requirements definition involves more than just the Business Analyst and the Product Owner. Agile encourages input from all team members to create a more robust solution that meets the needs of the business and helps create a strong sense of confidence that the solution can be delivered to market.

These are just a few of the new skills agile teams need to embrace. Learn more about other Agile Programming Practices.

Large organizations transitioning towards Agile take the first step of hiring Agile coaches.  Many business leaders would be under pressure to hire one as quickly as possible to speed up the process of Agile transformation. Many a times, due to this pressure, they end up making a mistake, hiring a wrong one. 

Based on my past experience working with large organizations and different coaches, I have put together the following 7 points to help business in making good decisions.

1. Try working with 2 or 3 coaches before finalizing one.
2. If you are planning a short term consulting role from a coach, then hire some one who has already built a good credibility as a coach. You may not have enough time to experiment.
3. Ensure to have only one Agile coach on a project.  Having 2 or more could end up wasting time/resources, as two Agile coaches rarely agree, especially if they are from different companies.
4. Ensure, coaches have skin in the game.
5. Ensure that Agile coaches know how to use available tools/technologies rather than just hung up on using Post-It notes.  Let me share my own experience working with one of the best Agile coaches Craig Larman.   While working with Craig, I noticed that, he not only used  Post-it efficiently,   Craig encouraged us to use different tools like  Cling-on sheets, White boards, Flip-charts, Projectors,etc.  Many Agile coaches nowadays don?t think beyond post-it notes.
6. I have observed that newbie-coaches who are on contracting roles tend to buckle up under organizational pressure. They may not push for changes to happen. An Agile coach who fearlessly pushes for transformation is better.
7. If you have hired an Agile coach, then observe the coach during their assignment for few days to understand their areas of strength.
   
   

Agile development is an umbrella term for a number of iterative and incremental software development methodologies such as Scrum, Extreme Programming (XP), Lean and Kanban. With agile, all aspects of software development ? planning, designing, coding, integrating and testing ? are combined in short, frequent iterations.

Agile software development is not a silver bullet, but it has forced many to rethink traditional approaches to software development and apply new ideas and techniques in an effort to build better software faster. As with any significant industry shift, a tremendous amount of fear, uncertainty and doubt generally accompany the transition.

Myth 1: Agile development is undisciplined, cowboy coding.

Fact: Continuous delivery of running, tested software every few weeks could be characterized as the ultimate software industry discipline.

Myth 2: Agile development isn?t predictable.

Fact: Agile teams are constantly planning, prioritizing and delivering against the plan and have a much better sense of where the project actually is and what can be accomplished.

Myth 3: Agile development is just another fad.

Fact: Many industry leaders have embraced and promoted agile. Agile adoption has moved from small co-located teams to large divisions and software organizations of enterprise IT.

What?s Hot: Agile Development

· Teams constantly delivering benefit to the organization every quarter, month, week or even day

· Small, cross-functional teams that communicate and collaborate on an on-going basis

· Planning projects upfront at a high level with detailed planning happening throughout the project to efficiently adapt to change

· Using historical information to plan work incrementally and predict progress

· Quality software is always ready to be delivered

What?s Not: Traditional Software Development

· Teams delivering new features once or twice a year and often missing release dates

· Large teams that meet infrequently and are too big to have meaningful collaboration

· Extensive, up-front planning crammed into the beginning of a project that doesn?t account for inevitable change

· Using speculation to plan all work upfront and ?predict? progress

· Passable software is delivered late

Learn about more myths of agile development.

Do you expect your Scrum Master to understand  Java coding standards ?  Should the Scrum Master have a deep understanding of  differences between the four products the customer is building ?

There are people supporting the idea of Scrum Masters with strong knowledge in technology/programming skills. I feel that, knowing a specific subject whether it is technical or functional is never going to hurt. However, in the context of being a Scrum Master, I strongly believe that it is not a mandatory skill.

As long as the Scrum Master appreciates the value of technical practices, and importance of having a good technical debt in the project, one can always take help from a technical/functional coach or expert to implement the practices.  

Fundamentally, I see that following skills are essential to succeed as a Scrum Master

1. Ability to identify the technical or functional experts within the team (or the lack of)
2. Finding ways to get the help for the team
3. Skill to remove the impediments/blockers
4. Appreciate the value of good technical practices
5. Asking the right set of questions to get the answers
6. Empowering the teams to succeed and build self organizing teams

Let us take a look at an example. Consider a scenario where in a developer shares a blocker saying
                                               The message to TIBCO server is failing.

The Scrum Master(SM) need not know how to fix TIBCO server issue. As long as SM asks the right questions, the impediments could be removed and one could succeed in any project.

A SM could ask following questions in the context of above TIBCO server issue (not in any specific order)
1. Is this a new one or the one occurred in the past ?
2. Who are the TIBCO skilled experts in the team to be invited to investigate this issue ?
3. Do you really think it is TIBCO server issue or something else ?
4. What is the criticality of the issue and who should be informed ?
5. What is the fall back plan ?
6. What is the impact of this issue on delivery timelines ?
and few more questions?

In the end, the SM could do a retro (if it is major issue), and apply 5 Whys to identify the root cause.