- Activities
- Intelligent Control
- Whole-Person Recognition
- Summary
- References
Like this article? We recommend
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 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):
- 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 8-2. Pull Task Management System on an Agile Team
- Developers pull user stories and tasks from the iteration plan/task backlog.
- Developers pair with other developers, business analysts, etc., to design, code, unit test, and integrate the user story into the code base.
- When the code for the user story passes all unit and acceptance tests, developers release it to test.
- Testers pull the user story from the test backlog for testing.
- Testers test the user story to see whether it meets the acceptance criteria specified by the customer.
- 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.
- 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 8-3. "Job Jar" Pull Task Management System
)
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:
- Can the person do the job?
- 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.