Home > Articles > Programming > Windows Programming

Like this article? We recommend

Like this article? We recommend

Intelligent Control

"Hire good people and get out of the way." Most of us have heard this popular management maxim. When I first heard it years ago, it appealed to me because of its simplicity. But having tried to implement it, I now know that it is too simplistic in its outlook: Hiring good people works very well for the most part, but getting completely out of the way doesn't because it usually leaves a vacuum that affects the team's ability to deliver. As we have seen in the past several chapters, several things are the agile manager's sole responsibility. So, although command and control is not the way to manage agile teams, getting completely out of the way does not work either. So, what are some of the key things of which the agile manager needs to maintain control, while "getting out of the way" for the rest? Put another way, what is the way for agile managers to intelligently control the skilled professionals on their agile teams?

Intelligent control is the exertion of influence and direction with minimal top-down control. Intelligent control is needed to manage skilled professionals with a style that best allows them to fulfill their creative potential and to function as self-organized groups that react rapidly to change. The activities for you to practice intelligent control—decentralize control, establish a pull task management system, manage the flow, use action sprints, fit your style to the situation, support roving leadership, and learn to go with the flow—are covered next.

Activity: Decentralize Control

The most important decision about control is deciding who will control what and when. On an agile project, the control system consists of the simple process rules and other working rules that the team commits to follow. A good way to decentralize control is to break out the control system into levels and distribute decision making among the levels. An agile project's control systems can be broken out into these three levels: the governing strategy and selected rule system, the rules, and the application of the rules.1 For instance, if you have selected Scrum, then Scrum is your rule system. The reason you selected Scrum and what you want to accomplish with it is your governing strategy. The Scrum practices are your rules, and the application of Scrum practices is the rule application.

To decentralize control on your agile project, you can apply the project control system breakout shown in Figure 8-1. At level 1 where the rules are applied, there are many decisions to be made, and they need to be made frequently and quickly. These decisions have limited impact and cost. Decision making at level 1 should be delegated to individual team members, affording them a large degree of autonomy, flexibility, and speed. Level 2 is where the rules themselves are decided. These decisions take place less frequently and are fewer in number, but they have a much larger impact and cost. Decision making at level 2 should be handled by the team. Customers are considered to be part of the team.

Level 3 is where the choice of the rule system (XP, Scrum, Crystal, etc.) takes place and where corporate strategy is decided. These decisions are made occasionally and are very few, but they have the largest impact and cost. Decision making at level 3 should be handled by management. It has been my experience that agile managers participate mostly at level 2, and sometimes at level 3. Figure 8-1 also illustrates decision breakout between the levels. For example, a management strategy decision at level 3 to have a high quality of work life translates to team decisions at level 2 about appropriate work hours. In turn, related decisions about personal schedule are made by the individual team member at level 1. Similarly, a level 3 management decision to enhance knowledge transfer translates into decisions about pairing and collocation at level 2. At level 1, these decisions about the choice of a pairing partner are made by individual team members.

Figure 1

FIGURE 8-1Example of Decentralized Control with Multiple Control Levels

Activity: Establish a Pull Task Management System

A pull task management system is one in which tasks are "pulled" from a task queue or backlog by team members themselves, instead of "pushed" or assigned by a central coordinator, such as a project manager. Pull systemsallow people to operate independently and autonomously in changing situations without wasting time waiting for work to be scheduled by someone else. On an agile team, the pull system includes prioritized backlogs of user stories (eXtreme Programming) or equivalent tasks (Scrum and others), as illustrated in Figure 8-2, and information radiators used as visual controls to indicate completion of the task to the next responsible group in the value stream.

A user story flows from the customer through the development value stream and back to the customer in this sequence (as shown in Figure 8-2):

  1. The customer creates and prioritizes a user story representing a part of the system's functionality in iteration planning. Stories are placed along with associated tasks in an iteration plan/task backlog in order of priority. Acceptance criteria are also specified.
    Figure 2

    FIGURE 8-2. Pull Task Management System on an Agile Team

  2. Developers pull user stories and tasks from the iteration plan/task backlog.
  3. Developers pair with other developers, business analysts, etc., to design, code, unit test, and integrate the user story into the code base.
  4. When the code for the user story passes all unit and acceptance tests, developers release it to test.
  5. Testers pull the user story from the test backlog for testing.
  6. Testers test the user story to see whether it meets the acceptance criteria specified by the customer.
  7. Testers either pass the user story and place it in the acceptance test backlog for the customers to test, or they reject it and place it once again in the iteration plan/task backlog.
  8. The customer pulls user stories from the acceptance test backlog for final acceptance.

The iteration plan/task backlog is replenished and reprioritized at every iteration planning meeting. It is serviced continuously during the iteration. The test and acceptance test backlogs are replenished and serviced continuously within the iteration. You need to display visual representations of the backlogs so that team members can easily perform their work.

Figure 3

FIGURE 8-3. "Job Jar" Pull Task Management System

Figure 4

FIGURE 8-4."Job Jar" Detail

On the workday, the job jar served as task backlog and visual control, and small groups of parishioners self-organized to complete the tasks, all of them working without Alan's direct supervision.

You can create charts with the user stories split into three to-do, for testing, and tested categories to serve as visual controls. These visual controls can be dynamically updated by team members as they complete their work, and serve as pull signals for the next group in the value stream to begin performing their work.

Activity: Manage the Flow

Lean Thinking has been used to reduce wastes and improve quality in many organizations for several decades with remarkable results. Besides the pull system, another key concept of Lean Thinking is continuous flow. Pull task management systems need to be implemented with serious thought to the flow of business value across the team. How should business value in the form of user stories be kept flowing continuously through it? In Lean organizations, one-piece flow or continuous flow is employed to make one part of a system correctly and completely without interruptions and with low cycle times. Agile teams practice this concept when they define, develop, integrate, and deploy software development systems a user story at a time. The user story (in XP) or equivalent task (Scrum and others) represents the "one piece" of business value that needs to flow from the customer through development, testing, and deployment back to the customer as quickly as possible without interruptions. Pull task management helps ensure that team members are performing their work with flexibility and autonomy. So, what can the agile manager do to help the work of the team? Instead of supervising task completion, you should turn your attention to managing the flow of user stories from creation to completion.

Mary and Tom Poppendieck discuss these guidelines to avoid bottlenecks in software development queues: small batch size, steady rate of arrival and service, and slack.2 You can apply these guidelines to manage the flow of user stories through your team's pull task management system as follows:

  • Small batch size. Agile teams use iterative development to avoid the issues caused by large batch size—lack of early feedback, large inventory, and associated large potential waste of time and other resources. Small releases and iterative development provide two levels at which batch size can be controlled. You need to work with your customers to ensure that system functionality is being defined, created and released in small batches. At the release level, this means ensuring that feature batch size is kept small by breaking features into high-level user stories that take no longer than three weeks to implement, and that no release takes longer than three to four months, even for large projects. At the iteration level, it involves ensuring that detailed user stories that implement high-level ones represent no more than three days of work, and that iterations are kept to one, two, or three weeks in duration each.
  • Steady rate of arrival and service. Each backlog in the agile project's task management system shown in Figure 8-2 is a queue. You need to keep an eye on all these queues to see that user stories both arrive at the respective backlog, and are serviced at a steady rate. With the iteration plan/task backlog, this is straightforward: Iteration planning is a systematic way of prioritizing and scheduling the user stories; iteration planning ensures that user stories arrive in the iteration plan/task backlog, at a steady rate. You also need to ensure that user stories are being pulled at a steady rate from the iteration plan/task backlog.

    If you have an intermediate test backlog, you need to monitor it to ensure that user stories are being serviced at a steady rate by developers and arriving at the test backlog at a steady rate. Again, the user stories in the test backlog need to be serviced and passed at a steady rate by your testers to arrive at a steady rate at the acceptance test backlog. Finally, you need to monitor the acceptance test backlog to ensure that user stories are being pulled for final acceptance by your customers. Backups at any of the backlogs immediately indicate a disruption to continuous flow and, hence, a problem for you to deal with.

    Take the iteration plan/task backlog, for instance. If it starts backing up within an iteration, it could either mean that your developers are having difficulties coding user stories and are not pulling new ones from it quickly enough or that testers are rejecting an inordinate share of user stories because of defects or unmet requirements. Either of these situations merits your immediate attention.

  • Slack. Any system's performance degrades rapidly when its resources are overloaded. A software development project team is no exception. Besides, because there are humans involved, it will be even more prone to errors when utilization goes beyond 70 or 80 percent. You therefore need to ensure that you afford your team a certain amount of slack to ensure that they are consistently productive.

Use Action Sprints

Sometimes, even the best agile team will fall into a rut of creating user stories, coding them, testing them, and releasing them. People will settle into familiar roles and do what has come to be expected of them. Many members on your team may begin to get restless or bored because of the lack of variety in work and the lack of variation in method. Quality might begin to suffer and schedules might begin to slip because motivation has slipped. When this happens to me, I fall back on a technique that was introduced to me by Bob Payne, an independent XP consultant: a sprint. Bob came across the technique through his involvement with the Zope development community.3

In the Zope community, a sprint is an intense two- or three-day development session, focused on building a particular subsystem. Zope sprints differ from Scrum sprints in that they are narrowly focused and are oriented toward technical rather than business activities. My own experience with a Zope-style sprint came on a large recovery-and-stabilization project whose managers I was responsible for coaching. Bob, who was the XP process coach, introduced the idea of a sprint as a solution for massive architectural refactoring that was needed. After consultation with all managers, we decided to devote a single iteration's worth of time to a single task—to refactor the legacy code. Everybody took part in some way or the other, just not their usual way. Six teams of more than a hundred people threw themselves into this effort. There were no formal management positions—anyone who knew the most about a particular part of the system took the lead. The pace was blistering, the pressure intense, and the goal was deliberately challenging. The entire effort was completely self-organized around a single goal. The code base developed in more than a year was refactored in a single iteration. It was a stupendous effort. That experience taught me the power of focused self-organization that a sprint can provide. Since then, I have used a variation of this technique—action sprints—on several occasions, not only to get very challenging work done in a short time, but also to identify and develop leaders on my agile teams.

An action sprint is a short, intensely focused activity that you can use to attack particularly difficult business- or technology-oriented problems in an unconventional way. Follow these guidelines to make the most of your action sprints:

  • Focus on a single, narrow goal or action.
  • Make the goal absolutely clear to everyone on the team.
  • Time limit the action sprint strictly to no more than a few days.
  • Dissolve all roles and responsibilities, especially management roles and responsibilities.
  • Devote some time at the beginning of the action sprint for your team to come together and generate a plan.
  • Participate, along with everyone else, in a hands-on fashion.

Allowing your team to conduct an action sprint requires quite a bit of trust in the team's abilities on your part, as well as the part of your organization's senior management. There is always a risk of very little resulting from it, but that is why it is time limited. On the other hand, you should seriously consider the possibility that it could yield some dramatic results for you and your organization.

Activity: Fit Your Style to the Situation

There is no "best way" to manage anything or lead everyone. Even on agile teams with their self-disciplined team members, a single leadership style simply does not exist. The reason is simple—people are complex beings. Each person's behavior springs from a lifetime of accumulated experiences, insights and values. Different people require different styles of leadership. In fact, the same people may require different styles of leadership in different situations. For instance, a software craftsman with the ability to write code without any guidance or supervision may require assistance in developing user documentation. Or an expert business analyst who deeply understands the subject behind a set of data may require help in retrieving that data from a database. An agile manager needs to be able to adapt herself to the situation to fit her team members and the situations in which they work. What is a good way for the agile manager to do this?

Paul Hersey and Ken Blanchard's Situational Leadership4 framework categorizes a leader's necessary behavior based on the combination of direction and support needed by her follower. Accordingly, they prescribe four different styles depending on the capability and willingness of the person to perform the work, determined by asking two questions:

  1. Can the person do the job?
  2. Will he or she take responsibility for it?5

The answers to these questions determine the type of style that a leader should apply to the situation:

  • The directive style is called for when the answers to both these questions is no—when the person both cannot do the job and will not take responsibility for it. This is the high-direction, low-support style. A leader provides high direction on the task, providing guidance on both what tasks are to be done and how to perform them. Very little support or encouragement is provided in this case.
  • The consultative style is needed when the person cannot perform the work but is willing to take responsibility for it. This is the high-direction, high-support style. In this case, the leader still assists with the direction in both the what and how of the task, but provides a high level of support and encouragement in addition.
  • The participative style is used when the person can perform the job but will not take responsibility for it. This is the low-direction, high-support style. There is much less direction on how to perform the task but still a high level of support and encouragement.
  • The delegative style is applied when the answer to both questions is yes—the person can both do the job and will take responsibility for it. This is the low-direction, low-support style. Very little direction or support is provided.

Agile teams are designed to operate mainly with the delegative style. Agile team members are selected for their competence and self-discipline. However, any experienced manager knows that getting an entire team of highly competent and self-disciplined team members does not happen very often. Skill levels vary from person to person, as does the ability to self-discipline. Furthermore, skill levels for the same vary from situation to situation as well. Depending on the situation, you need to decide which one of the four styles to adopt. The picture is a little complicated, because in many cases, you will need to defer to your technical coach to provide task assistance. My personal preference is to gauge the leadership style needed for the situation and, if I cannot provide the direction necessary, I identify someone who can.

Activity: Support Roving Leadership

Roving leadership6 is the term coined by Max DePree for unofficial leaders who rise to the occasion and take charge because of the strength of their personalities. By this definition, anyone on the team can become a leader depending on his or her response to challenging circumstances.

For instance, on one my large projects, we had a serious configuration management issue for several different reasons—legacy code integration, third-party product integration, etc. The configuration management team on this project was struggling to come up with a viable solution in time. When the release came closer and the situation became increasingly dire, one of our developers stepped up and provided the leadership and direction necessary for the configuration management team. Although he was not formally a configuration management specialist, he had recently worked for a company that develops configuration management tools. It turned out that he had just the right combination of experience necessary to perform the work, and took on the mantle of a roving leader. On another project, when I was having a difficult time answering our customer's questions, our technical coach stepped in and took charge as a roving leader to manage our response to our customer. Roving leadership like this should be common on your agile projects. What can you do to foster it?

The APM practices directly foster roving leadership. Activities such as decentralizing control and cultivating communities of practices help nurture other leaders in the team besides you. But in the end, it is up to you to support the roving leaders as they come forth from your team to handle different situations. If you do not, roving leadership will eventually die out. What can you do to support roving leadership?

When pressure situations arise and roving leaders step forth, you need to gracefully step aside, let them handle the issue, and provide them with your full support. This is not abdicating your responsibility to lead the team. In fact, it is fulfilling your leadership responsibility in full measure and more because you are grooming the leaders of tomorrow.

Activity: Learn to Go with the Flow

There is something inherently attractive, fulfilling, and even spiritual about creative work that fulfills a vision. Creative work, including software development, seems to satisfy something very deep and primal within us. Perhaps that is why few experiences compare with working on a team that has a clear purpose and delivers clearly measurable value to its cust-omers. The experience of periods of intense concentration, close camaraderie and trust, hard work, challenge, fun, and sparks of brilliance and creativity is so fulfilling and rewarding that almost everybody wants to be a part of it. Given the right team, following the practices in this book is likely to result in this sort ofintense, time-suspending, deeply rewarding experience—sometimes called flow (psychological flow, distinct from the value flow discussed thus far). Part of intelligent control is simply relaxing and letting this experience happen, and when it does, letting it attract team members to the work you are doing on your team. Because, after you have established the right control system and team members have assumed individual responsibility for the work that needs to be done, there will be times when you will need to do little managing. During these times, you do not need to do much besides monitor the team's progress and its value flow. Your responsibility at this point is to let your team go where it needs to go and simply immerse yourself in the experience. This activity, then, is somewhat of a nonactivity: Learn to let go and go with the flow.

InformIT Promotional Mailings & Special Offers

I would like to receive exclusive offers and hear about products from InformIT and its family of brands. I can unsubscribe at any time.

Overview


Pearson Education, Inc., 221 River Street, Hoboken, New Jersey 07030, (Pearson) presents this site to provide information about products and services that can be purchased through this site.

This privacy notice provides an overview of our commitment to privacy and describes how we collect, protect, use and share personal information collected through this site. Please note that other Pearson websites and online products and services have their own separate privacy policies.

Collection and Use of Information


To conduct business and deliver products and services, Pearson collects and uses personal information in several ways in connection with this site, including:

Questions and Inquiries

For inquiries and questions, we collect the inquiry or question, together with name, contact details (email address, phone number and mailing address) and any other additional information voluntarily submitted to us through a Contact Us form or an email. We use this information to address the inquiry and respond to the question.

Online Store

For orders and purchases placed through our online store on this site, we collect order details, name, institution name and address (if applicable), email address, phone number, shipping and billing addresses, credit/debit card information, shipping options and any instructions. We use this information to complete transactions, fulfill orders, communicate with individuals placing orders or visiting the online store, and for related purposes.

Surveys

Pearson may offer opportunities to provide feedback or participate in surveys, including surveys evaluating Pearson products, services or sites. Participation is voluntary. Pearson collects information requested in the survey questions and uses the information to evaluate, support, maintain and improve products, services or sites, develop new products and services, conduct educational research and for other purposes specified in the survey.

Contests and Drawings

Occasionally, we may sponsor a contest or drawing. Participation is optional. Pearson collects name, contact information and other information specified on the entry form for the contest or drawing to conduct the contest or drawing. Pearson may collect additional personal information from the winners of a contest or drawing in order to award the prize and for tax reporting purposes, as required by law.

Newsletters

If you have elected to receive email newsletters or promotional mailings and special offers but want to unsubscribe, simply email information@informit.com.

Service Announcements

On rare occasions it is necessary to send out a strictly service related announcement. For instance, if our service is temporarily suspended for maintenance we might send users an email. Generally, users may not opt-out of these communications, though they can deactivate their account information. However, these communications are not promotional in nature.

Customer Service

We communicate with users on a regular basis to provide requested services and in regard to issues relating to their account we reply via email or phone in accordance with the users' wishes when a user submits their information through our Contact Us form.

Other Collection and Use of Information


Application and System Logs

Pearson automatically collects log data to help ensure the delivery, availability and security of this site. Log data may include technical information about how a user or visitor connected to this site, such as browser type, type of computer/device, operating system, internet service provider and IP address. We use this information for support purposes and to monitor the health of the site, identify problems, improve service, detect unauthorized access and fraudulent activity, prevent and respond to security incidents and appropriately scale computing resources.

Web Analytics

Pearson may use third party web trend analytical services, including Google Analytics, to collect visitor information, such as IP addresses, browser types, referring pages, pages visited and time spent on a particular site. While these analytical services collect and report information on an anonymous basis, they may use cookies to gather web trend information. The information gathered may enable Pearson (but not the third party web trend services) to link information with application and system log data. Pearson uses this information for system administration and to identify problems, improve service, detect unauthorized access and fraudulent activity, prevent and respond to security incidents, appropriately scale computing resources and otherwise support and deliver this site and its services.

Cookies and Related Technologies

This site uses cookies and similar technologies to personalize content, measure traffic patterns, control security, track use and access of information on this site, and provide interest-based messages and advertising. Users can manage and block the use of cookies through their browser. Disabling or blocking certain cookies may limit the functionality of this site.

Do Not Track

This site currently does not respond to Do Not Track signals.

Security


Pearson uses appropriate physical, administrative and technical security measures to protect personal information from unauthorized access, use and disclosure.

Children


This site is not directed to children under the age of 13.

Marketing


Pearson may send or direct marketing communications to users, provided that

  • Pearson will not use personal information collected or processed as a K-12 school service provider for the purpose of directed or targeted advertising.
  • Such marketing is consistent with applicable law and Pearson's legal obligations.
  • Pearson will not knowingly direct or send marketing communications to an individual who has expressed a preference not to receive marketing.
  • Where required by applicable law, express or implied consent to marketing exists and has not been withdrawn.

Pearson may provide personal information to a third party service provider on a restricted basis to provide marketing solely on behalf of Pearson or an affiliate or customer for whom Pearson is a service provider. Marketing preferences may be changed at any time.

Correcting/Updating Personal Information


If a user's personally identifiable information changes (such as your postal address or email address), we provide a way to correct or update that user's personal data provided to us. This can be done on the Account page. If a user no longer desires our service and desires to delete his or her account, please contact us at customer-service@informit.com and we will process the deletion of a user's account.

Choice/Opt-out


Users can always make an informed choice as to whether they should proceed with certain services offered by InformIT. If you choose to remove yourself from our mailing list(s) simply visit the following page and uncheck any communication you no longer want to receive: www.informit.com/u.aspx.

Sale of Personal Information


Pearson does not rent or sell personal information in exchange for any payment of money.

While Pearson does not sell personal information, as defined in Nevada law, Nevada residents may email a request for no sale of their personal information to NevadaDesignatedRequest@pearson.com.

Supplemental Privacy Statement for California Residents


California residents should read our Supplemental privacy statement for California residents in conjunction with this Privacy Notice. The Supplemental privacy statement for California residents explains Pearson's commitment to comply with California law and applies to personal information of California residents collected in connection with this site and the Services.

Sharing and Disclosure


Pearson may disclose personal information, as follows:

  • As required by law.
  • With the consent of the individual (or their parent, if the individual is a minor)
  • In response to a subpoena, court order or legal process, to the extent permitted or required by law
  • To protect the security and safety of individuals, data, assets and systems, consistent with applicable law
  • In connection the sale, joint venture or other transfer of some or all of its company or assets, subject to the provisions of this Privacy Notice
  • To investigate or address actual or suspected fraud or other illegal activities
  • To exercise its legal rights, including enforcement of the Terms of Use for this site or another contract
  • To affiliated Pearson companies and other companies and organizations who perform work for Pearson and are obligated to protect the privacy of personal information consistent with this Privacy Notice
  • To a school, organization, company or government agency, where Pearson collects or processes the personal information in a school setting or on behalf of such organization, company or government agency.

Links


This web site contains links to other sites. Please be aware that we are not responsible for the privacy practices of such other sites. We encourage our users to be aware when they leave our site and to read the privacy statements of each and every web site that collects Personal Information. This privacy statement applies solely to information collected by this web site.

Requests and Contact


Please contact us about this Privacy Notice or if you have any requests or questions relating to the privacy of your personal information.

Changes to this Privacy Notice


We may revise this Privacy Notice through an updated posting. We will identify the effective date of the revision in the posting. Often, updates are made to provide greater clarity or to comply with changes in regulatory requirements. If the updates involve material changes to the collection, protection, use or disclosure of Personal Information, Pearson will provide notice of the change through a conspicuous notice on this site or other appropriate way. Continued use of the site after the effective date of a posted revision evidences acceptance. Please contact us if you have questions or concerns about the Privacy Notice or any objection to any revisions.

Last Update: November 17, 2020