The Hyped of Agile


Pair programming, hyped beyond reason. As a practice to be applied occasionally, pair programming is a useful addition to the programming team's bag of tricks. But there is no credible evidence that it provides major improvements to the programming process or that it is better than classical techniques such as code reviews, and no reason to impose it as the sole mode of development.

Open-space working arrangements. There is no single formula for the layout of a working environment. What we do know is that it is essential to provide simple, obvious opportunities for informal communication. Beyond that, many office setups are possible which will not endanger a team's success. (A related point appears, however, under the "good" ideas of the next section: avoiding distributed development.)

Self-organizing teams. A few teams are competent and experienced enough to man-age themselves, like a conductor-less orchestra. Most are not. Each situation calls for its own organizational solutions and there is no reason to impose a single scheme on the entire industry.

Working at a sustainable pace. All great advice; death marches are not a good management practice. But advice can only be wishful here; these matters are determined by economic and organizational pressures more than by good intentions. They are not specific to the programming world: like a company that is responding to a Request For Proposals, a researcher who is facing a conference submission deadline will work through the night to meet it. The most software methodologists can do is to argue that such practices should remain the exception.

Producing minimal functionality. It is always a good habit to question whether pro-posed features are really needed. But usually they get introduced for a reason: some important customer wants them. It is easy to rail against bloat or heap scorn on monster software (Microsoft Word and Adobe Acrobat are common targets), but try to remove any functionality and brace for the screams of the outraged users.

Planning game, planning poker. These are interesting techniques to help estimate in advance the cost and time of development activities, but they cannot be a substitute for more scientific approaches. In particular, they are open to the danger of intimidation by the crowd; the voice of the expert risks being smothered by the chorus of novices.

Members and observers. In project meetings, the views of the people most seriously involved matter most. This trivial observation does not deserve the amount of attention that the agile canon devotes to the distinction between "pigs" and "chickens".

Collective code ownership. The policy governing who is permitted to change various parts of the code is a delicate decision for each project; it depends on the nature of the team and many other considerations. It is pointless to prescribe a universal solution.

Cross-functional teams. It is a good idea to encourage developers to gain broad competence and to avoid dividing the projects into narrow kingdoms of expertise each under the control of one person. Beyond this general advice, there is little a method can change here to the obvious observation that special areas require special skills. If one of your developers is a database expert and another is a concurrency expert, you will not ask the first, if you have a choice, to resolve a tricky deadlock issue, or the second to optimize queries. This observation is another reason why the agile scheduling policy of picking the highest-business-value task in the pipeline is simplistic and potentially harmful.

The Bad and the Ugly of Agile



iREM is an iterative approach of SaaS RE for the agile implementation. It facilitates the discovery of services by mapping business process to services for the agile implementation in small iterations:

A business process (BP) is identified as an input (e.g. marked in bold and red color in Figure 2) from a pool or repository of business processes that need to be implemented in terms of software services in the agile iteration X (depending on situational circumstances, a large business process may span multiple iterations or a small number of business processes may fit in one iteration).

The identified business process (BP) is linked or mapped to a single or set of business use cases (BUC), which are identified and stored in the business use case backlog for the iteration X.

Each identified business use case (BUC) is linked or mapped to a single or set of system use cases (SUC), which are identified and stored in the system use case backlog for the iteration X.

Each identified system use case (SUC) is linked or mapped to a single or set of test cases (TC), which are identified and stored in the test case backlog for the iteration X. At this stage, the system use case backlog integrated with the test case backlog is released for the iteration X implementation by using agile practices.

Each identified system use case (SUC) is linked or mapped to a single or set of agile practices (within their overall generic process lifecycle), which is called integrated system requirement or system use case (please see Section above for details).

Each integrated system use case is linked or mapped to a software service (integrated SaaS requirements, which are stored in the product service backlog (e.g. marked in bold and green color in Figure 2) for the iteration X.

The business analyst and quality analyst start the next iteration X + 1 for identifying the BP and attached BUC, SUC and TC. The development team starts working on the implementation of services listed in the product service backlog for the iteration X as per their priority. If the requirements are changed during the iteration X implementation then those changes (if minor) can be considered in the current iteration X or next iteration X+n (where n= 1, 2, 3…). In the end of an iteration X, the iteration X retrospective is conducted to review the agile process (e.g. which services have been implemented by using which agile practices), and identify any issues (e.g. missed requirements, less than 50% unit test coverage) and their root-causes (e.g. continuous integration was not performed for SUC of service 1, code view review and user viewing sessions were not conducted) and then finally, the iteration X is released for further integration and user acceptance testing. Here, at this stage, the system use case backlog integrated with test case backlog for the next iteration X+1 may be released to development team by the business and quality analysts for implementation. The development team starts a work on the Iteration X+1 and also provides support for fixing any defects in the previous iteration X.

Here, we may observe how iREM supports the iterative discovery of SaaS requirements and their agile implementation. It can also be observed that there can be one or more active iterations at a given point of time (business and quality analyst working on the iteration X+1 while the development team is working on iteration X).

Using Pareto’s Law

Working effectively means deciding the relative priorities of different tasks. Obvious perhaps, and of course you may say some things are clearly more important than others. But it is very easy to underestimate just how much this concept influences what you need to do, indeed just how much it influences your inherent effectiveness.

Many years ago, the Italian economist Vilfredo Pareto recognized the truism that carries his name and that is now more commonly called the 80/20 rule. It links cause and effect in a ratio and, although this is not represented absolutely accurately in real life, an approximate 80/20 ratio is consistently found in many business activities, sometimes with a precision that is considerable. This means that for instance:

- 20 percent of a company’s customers are likely to produce 80 percent of its revenue.

- 20 percent of factory errors are likely to cause 80 percent of quality rejects.

And it applies specifically in terms of issues relating directly to time:

- 20 percent of meeting time results in about 80 percent of decisions made.

- 20 percent of items to read that pass across your desk produce 80 percent of the information you need in your work.

SUCCESSFUL MANAGEMENT is dependent on A Time-Aware Team

Agile Promise


The principles behind the Agile Manifesto documents well the initial promise the agile proponents were giving.

- Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.

- Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.

- Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.

- Business people and developers must work together daily throughout the project.

- Build projects around motivated individuals.

- Give them the environment and support they need, and trust them to get the job done.

- The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.

- Working software is the primary measure of progress.

- Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.

- Continuous attention to technical excellence and good design enhances agility.

- Simplicity--the art of maximizing the amount of work not done--is essential.

- The best architectures, requirements, and designs emerge from self-organizing teams.

- At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

As can be seen in these principles the agile approach is focused in building a co-located team and in seeing the benefits though the eyes of the team. Much of the project management tasks can be reduced to minimum due the co-location, and remaining tasks can be integrated seamlessly to the development work. Agreeing the tasks, reviewing the results, setting and striving for the task goals, solving the rising issues and other such tasks become a part of the teamwork. Similarly, external parties become an integral part or contributors of the team.

It is more difficult to achieve similar benefits in larger organizations (Kettunen, 2009) where the number of people leads to the existence of many teams and the distance between people grow bigger, even global in many occasions. Inevitably the external parties will become more distanced as well. So the agile benefits for larger organizations cannot be expected to be the same or on the same level as for small organizations. Yet the expectations are that an agile organization is responsive to the customer needs, even when the customer has difficulties in deciding on his/her own needs and changes his/her opinion frequently. In large organizations this kind of changes often have the "whip effect", similar to that in a supply chain (Lee, Padmanabhan & Whang, 1997). It creates variance and bottlenecks throughout the development and the delivery process. Keeping focus in tasks that are delivering value to the customer in the customer satisfying manner and removing the rest becomes a major challenge.

The promise of better quality is to be deemed as well (Abbas, 2009). Thought the quality in a team level means improving in a team level that does not build linearly up to better quality in larger organizations. On the contrary, the local quality optimization may lead to deterioration of overall quality due to different understanding of the optimum and conflicting implementations of the quality related practices. Having a large number of people allows the development of larger software, but requires also growing attention to the non-functional characteristics, like reliability, usability, maintainability, and other "ilities". The traditional means for the quality control, like a separate quality organization or quality gates in the process can easily lead to additional effort that may not add value to the customer.

Parallel to obtaining the customer value and the quality benefits there are business stakeholders, like owners, partners, and top management of the organization to be satisfied as well (Power, 2010). In a larger organization their distance grows to customers and also to satisfying the customer needs. Each group defines and focuses on their own interests. It becomes a challenge to achieve the customer-supplier win-win in practice. The effectiveness of an organization from its stakeholder point of view compromises the pure customer value creating interests. Particularly for the product development organizations where the product manager is "a proxy customer" distance to the customer grows bigger than what is stated in the initial agile principles.

The third interest group to satisfy is the developers and the development organization in general (Cockburn & Highsmith, 2001; Melnik & Mauer, 2006). In a large organization they easily drift away from the customers but from the business stakeholders alike. It becomes challenging to foster the customer and business knowledge, the technical and development competence, and the large-scale teamwork in a partial isolation. Consequently the demand for customer co-operation, productive self-organizing teams, growth of essential competences, and the like agile promises are not fulfilled. Yet these are the essential characteristics of an agile software development organization.\

In short, the expectations have grown that the agile approach can be transformed from a team level methodology to the working and management practice of a larger organization and still retain the agile benefits. So the model of a small, co-located self-organizing team, consisting of skilled and apt people, working closely together with a customer fulfilling customer changing needs can be mapped to large organization that provides (Highsmith, 2007; Schwaber, 2007):

- Increased customer satisfaction

- Reduced time-to-market (better "time-to-benefit")

- Increased quality

- Improved project portfolio and product management (project types, features)

- Improved product development investment management (control and flexibility)

- Reduced "waste" (increased efficiency, productivity, development cost)

- Better predictability (visibility)

- Better risk management (risk reduction)

- Better workforce morale (developer satisfaction, well-being)

The two main strategies for expansion are inside-out and outside-in. The inside-out strategy means not just expanding from the team level to the management structure but also adjusting to and with the surrounding practices, that is, expanding the agile and agile compliant principles to cover more areas of the software development life cycle as well as to the managing of the software development organization. The outside-in strategy means amalgamating the agile development with the traditional software development and the organization management sustaining both as much as possible.


Building High-Performing Teams

1. Define a very clear picture of the future - a vision for the team. This is crucial, because teams search desperately for specific targets. Consider the old expression: "If you don't know where you are going, any road will get you there." Journeys without a clear destination leave groups feeling flat and lost. Keeping teams informed on where they're headed and how best to get there means leaders must be prepared to acknowledge and adapt to changes in operational conditions and even objectives. Leaders cannot sit back and watch, but instead must create and recreate the vision and team spirit that stops people losing heart and becoming lost.

2. Be genuine, even if it means lowering your guard. Leaders who create 'click' have an uncanny sense about how and when to express their inner selves. They will even reveal their own vulnerabilities at the right time to gain the respect of those around them. They are not so concerned about projecting a perfect image: they know that high-impact leaders get results by laughing at their own flaws. They don't play make-believe, knowing it's more important 'to be' than to 'seem to be'.

3. Ask good questions. They use enquiry and advocacy in such a way as to keep them abreast of what is really going on. They seem to use a simple formula of the 70-20-10 rule in conversations: 70 per cent listening, 20 per cent enquiring with just the right amount of advocacy, and 10 per cent tracking (i.e., summarizing and synthesizing information, and providing possible courses of action).

4. Talk about things - even the hard things. A leader who gets their team to click is not afraid to talk about the tough stuff. They find ways to have the difficult conversations in the knowledge that burying problems doesn't make them go away. They also know that if they, as leader, don't talk about things, no-one will and, pretty soon, a culture will develop in which too many things are left unsaid. (I can always tell when teams are dysfunctional by measuring the amount of stuff not talked about, or what I call the "let's not go there" issues.)

5. Follow through on commitments. Leaders of high-performing teams find ways to build trust and maintain it, especially by making teams hold to their commitments and keeping the team's view of its goals clear. However, they also know how to distinguish professional trust from blind loyalty.

6. Let others speak first. In high-performing teams, members see themselves as equal in terms of communication. Leaders should therefore encourage this by putting the other person's need to express their agenda ahead of their own.

7. Listen. High-performing teams comprise people who have mastered the art of listening without fear, of allowing others to speak without reacting strongly or negatively to what is being said, or what they anticipate will be said. The leader fosters and honors this attribute within the team by quickly putting a stop to bad conversational behavior that cuts other people off and implies that their ideas are not valued. The leader knows that achieving higher levels of innovation requires team members to be unafraid to express unusual ideas and advocate experimental processes. They emphasize this by publicly thanking those who take risks - and by making sure that sharp-shooters put their guns away.

8. Face up to non-performing players. This brings us to a very important characteristic of high-performing teams, which is that their leaders do not tolerate players who pull the team apart. Interestingly, experienced leaders frequently maintain unity and discipline through third parties in the form of people we call 'passionate champions'. A leader may surround his or herself with several passionate champions, who have established an understanding and close working relationship with one another, and who are totally focused on, and committed to, the team's objectives. They are capable of getting the job done - and not afraid to remove people who are failing to help them do so.

9. Have fun, but never at others' expense. High-impact leaders steer clear of sarcasm: they always take the high road. If they do make fun of someone, it's usually themselves. They have learned the lesson that reckless humor can be misinterpreted and backfire. They know that critics of the organization can turn inappropriate remarks back on a leader who makes them.

10. Be confident and dependable. Somehow, over and above the daily struggle, leaders who get teams to click project confidence. They do this by preparing their conversations and not backing away from, or skimming over, real issues and problems, even difficult or confronting ones. They always address 'What's up?' and 'What's so?' in the organization. They don't try to be spin doctors because they know that, ultimately, this doesn't work. Rather, they are known as straight shooters - people who play hard, fight fair, and never, never give up. At the end of the day, team members know that, whatever happens, their leader will be left standing. This gives them confidence that they will be standing, too. They also know that, should things get really bad, their leader will not desert them or try to shift the blame, but seek to protect them, even if it means standing in the line of fire.

Source of Information : PhilHarkins 10 Leadership Techniques for Building High Performing Teams

Using Windows Internet Name Service

WINS is a service that resolves computer names to IP addresses. Using WINS, the computer name COMPUTER84, for example, can be resolved to an IP address that enables computers on a Microsoft network to find one another and transfer information. WINS is needed to support pre–Windows 2000 systems and older applications that use NetBIOS over TCP/IP, such as the .NET command-line utilities. If you don’t have pre–Windows 2000 systems or applications on the network, you don’t need to use WINS.

WINS works best in client/server environments in which WINS clients send single-label (host) name queries to WINS servers for name resolution and WINS servers resolve the query and respond. When all your DNS servers are running Windows Server 2008 or later, deploying a Global Names zone creates static, global records with single-label names without relying on WINS. This allows users to access hosts using single-label names rather than FQDNs and removes the dependency on WINS. To transmit WINS queries and other information, computers use NetBIOS. NetBIOS provides an application programming interface (API) that allows computers on a network to communicate. NetBIOS applications rely on WINS or the local LMHOSTS file to resolve computer names to IP addresses. On pre–Windows 2000 networks, WINS is the primary name resolution service available. On Windows 2000 and later networks, DNS is the primary name resolution service and WINS has a different function. This function is to allow pre–Windows 2000 systems to browse lists of resources on the network and to allow Windows 2000 and later systems to locate NetBIOS resources.

To enable WINS name resolution on a network, you need to configure WINS clients and servers. When you configure WINS clients, you tell the clients the IP addresses for WINS servers on the network. Using the IP addresses, clients can communicate with WINS servers anywhere on the network, even if the servers are on different subnets. WINS clients can also communicate by using a broadcast method through which clients broadcast messages to other computers on the local network segment requesting their IP addresses. Because messages are broadcast, the WINS server isn’t used. Any non-WINS clients that support this type of message broadcasting can also use this method to resolve computer names to IP addresses.

When clients communicate with WINS servers, they establish sessions that have the following three key parts:

» Name registration. During name registration, the client gives the server its computer name and its IP address and asks to be added to the WINS database. If the specified computer name and IP address aren’t already in use on the network, the WINS server accepts the request and registers the client in the WINS database.

» Name renewal. Name registration isn’t permanent. Instead, the client can use the name for a specified period known as a lease. The client is also given a time period within which the lease must be renewed, which is known as the renewal interval. The client must reregister with the WINS server during the renewal interval.
» Name release. If the client can’t renew the lease, the name registration is released, allowing another system on the network to use the computer name, IP address, or both. The names are also released when you shut down a WINS client.

After a client establishes a session with a WINS server, the client can request name resolution services. The method used to resolve computer names to IP addresses depends on how the network is configured. The following four name-resolution methods are available:

» B-node (broadcast). Uses broadcast messages to resolve computer names to IP addresses. Computers that need to resolve a name broadcast a message to every host on the local network, requesting the IP address for a computer name. On a large network with hundreds or thousands of computers, these broadcast messages can use up valuable network bandwidth.

» P-node (peer-to-peer). Uses WINS servers to resolve computer names to IP addresses. As explained earlier, client sessions have three parts: name registration, name renewal, and name release. In this mode, when a client needs to resolve a computer name to an IP address, the client sends a query message to the server and the server responds with an answer.

» M-node (mixed). Combines b-node and p-node. With m-node, a WINS client first tries to use b-node for name resolution. If the attempt fails, the client then tries to use p-node. Because b-node is used first, this method has the same problems with network bandwidth usage as b-node.

» H-node (hybrid). Also combines b-node and p-node. With h-node, a WINS client first tries to use p-node for peer-to-peer name resolution. If the attempt fails, the client then tries to use broadcast messages with b-node. Because peer-to-peer is the primary method, h-node offers the best perfor¬mance on most networks. H-node is also the default method for WINS name resolution.

If WINS servers are available on the network, Windows clients use the p-node method for name resolution. If no WINS servers are available on the network, Windows clients use the b-node method for name resolution. Windows computers can also use DNS and the local files LMHOSTS and HOSTS to resolve network names.

When you use DHCP to assign IP addresses dynamically, you should set the name resolution method for DHCP clients. To do this, you need to set DHCP scope options for the 046 WINS/NBT Node Type as specified in “Setting Scope Options”. The best method to use is h-node. You’ll get the best performance and have reduced traffic on the network.

Source of Information : Windows Server 2012 Pocket Consultant 2012

Subscribe to Computing Tech

Enter your email address:

Delivered by FeedBurner

Alltop, all the top stories
All Malaysian Bloggers Project
Add to Technorati Favorites Top Blogs
Computer Blogs - BlogCatalog Blog Directory blogarama - the blog directory Top Computers blogs Software TopOfBlogs Information Technology, SEO Technology