Achieving Offshore Agility
1
White Paper
Building & Managing Self‐Adopting Teams
Author: Ali Zaidi Research and Development Application Services
Building and Managing Self‐Adopting Teams
Synopsis Management nowadays is faced with how to reach feature consensus and technology utility quickly and iteratively, to gain and maintain market advantage. This need interprets into the requirement for a development process that both continuously deliver working products and that constantly adjust to business needs and technology accessibility and consistency.
Building and Managing Overview
Team Formation
Team Management Management creates a team by selecting the available people most able to alter the requirements into an effective system. Scrum suggests teams of seven plus or minus two people. Complication of the work and self‐ organization engulfs larger teams. If the team is too small, the remuneration and productivity of
Close to Agreement Requirements Far From Agreement
Building sophisticated technology and competitive systems is complicated. As shown in the requirements/technology figure, the degree of complexity increases as the requirements are less identified and the technology is less certain.
can complete within the iteration and the team commits to the work. Nothing de‐motivates a team as much as someone else making commitments for it. Nothing motivates a team as much as accepting the responsibility for fulfilling commitments that it made itself.
To manage the complexity inherent in Anarchy systems development projects agile processes utilize self‐organizing teams. A team of individuals is formed. They Complicated organize themselves into a team in Complex response to the stress of a deadline. Nothing focuses the mind like a noose! The pressure of the deadline produces cooperation and creativity that otherwise is infrequent. Self‐ Complicated Simple organization is a breath of fresh air if Surety Not so sure Far Low Surety compared with non‐agile practices which are used for dealing with complexity. In the majority work circumstances, management imposes a time limit and tells the team collaboration and self‐organization are workers what to complete by the deadline. This restricted. Team size should be maximized violates the rule of common sense “You can tell almost to the breaking point to maximize the me what to do but not how to do it.” Within efficiency and productivity. agile processes, the degree of the iteration enforces a time limit. Scrum iterations (Sprints) are always thirty calendar days. It enables a team to selects how much work it believes it
www.ephlux.com
White Paper
2
Building and Managing Self‐Adopting Teams
Sprint! The team cooperatively selects requirements from a prioritized list, choosing only as much as it believes it can turn into an increment of working product functionality during the next Sprint. The only restrictions on the team are any on hand organizational principles, conventions and formerly constructed product functionality. The team commits to management that it will convert these requirements into working product functionality by the end of the Sprint. The team is then left alone to do so for the interval of the Sprint.
Don’t Panic! Feeling all alone ? No one to tell the team what to do? No methodology to guide the team how to transform the requirements into functionality? No one to blame if the team fails? That’s right, left alone. It is exclusively and totally the team’s responsibility to form out what to do, and how to do it. The old saying, .Be careful what you ask for, because you might get it! Describes the dilemma and opportunity of the team. In my experience, every team is at first stunned by this responsibility. However, as the team understands that it has the full power to do whatever it believes necessary, a sense of freedom and empowerment (that usually trite phrase) happens. The team starts talking, making designs on whiteboards, shaping of what work needs to be done. People start defining what work they’ll do, and what help they might need to get it done. Some people ask to do work that they’ve always wanted to learn, signing up for other additional work to offset their learning
3
curve. The team collectively simmers, devises, and works to meet its commitment. The team self‐organizes.
Self Adoption Begins Teams are cross functional and without assigned roles. Team members may have job descriptions, training and experience, but that doesn’t entitle them. Instead, the team self organizes based on its strengths and weaknesses to do the work at hand. If the testers are swamped, developers may have to help test. If the tech/content writer has extra time, he or she can help write test cases. Everyone on the team, each, creates the product, contributing whatever he or she has to what is needed. Each member of the team has variable skills to apply to the problem and technology domain. Each individual also has intellect, willpower, and focus with which they will apply their skills. At any moment, on any day, the intersection of the problem domain, technology constancy, skills available, and existence of determination, focus and intelligence is hugely changeable, but the individual has to self‐organize him or herself to shape out what to do and how to do it.
Team Coordination (Scrum and XP) Every day, everyone on the team must direct his or her own individual self ‐ Agile == Constant feedback to individuals+ that all team members share awareness of team activity and team commitment to goals
organization with the rest of the team. Always
www.ephlux.com
White Paper
Building and Managing Self‐Adopting Teams
remember regular feedback is the key to success internally and externally in an Agile Model. To make this possible, Scrum and XP have daily synchronization and status exchange conferences. Scrum’s daily meetings (Daily Scrums) are quite formal, making sure that specific synchronization occurs. XP’s daily meetings are less formal and are driven by need rather than plan. The Daily Scrums meetings are just last for about fifteen minutes or a bit more. During the meeting, each member answers three questions: 1. What is your progress since the last Daily Scrum? 2. What will you do between now and the next
Daily Scrum? 3. What’s getting in the way of you doing your work? As team members respond to these questions, the other team members are regulating and adapting their own work in response. They may think. Oh, now I don’t need to do that.., or, sounds like Steve’s successfully using that new library; I’ll check it out with him this afternoon. The team’s self‐organization occurs as the members assigned themselves to what they will do over the next 24 hours. When they report what they were able to do over the last 24 hours, they help everyone alter from previous assumptions and take into account what really took place. When a team member informs issues that got in the way, he or she is informing obstacles to self‐ organization. He or she is saying, .I was trying to do this, to sort out myself to get this done, and I couldn’t because of him or her. If yeast in bread batter could talk, it might also report impediments. Similarly, the team member is requesting for help to make things better. He or she is reporting what is required to stay productive. Since management attends every Daily Scrum, its job is to immediately remove these problems. The Daily Scrum motivates this self‐ organization, keeping it invisibly agitating. At the end of the Sprint, a team exhibits the executable product increment that it built. The team selected requirements at the start of the iteration. It struggled with the technology and requirements to build
www.ephlux.com
White Paper
4
uilding and M Managing Self‐‐Adopting Teams Bu
functionality that delivvers business value. Now the team exhibits the ffunctionality to the customer. Pre‐knowled dge of this deemonstration focuses th he team’s con ncentration. It knows that at the end d of the Sprint, it will exhib bit the system to o the consume er and managgement. No excuses, n no one to point at. The team is bound to d do what it said it could do! The seense of deterrmination and d pride within succh teams is obvious. If you u want me to take the d dependabilityy, give me thee power. Scrum does so, assistin ng the self‐orgganization essential ffor teams to ffocus on the complexity of modern n software de evelopment p projects.
Offshorre Agile T Team Guid delines Agile Team ms in an offsh hore mode works in a similar waay as well butt certain key eessentials
Conttrary to this, m matters get im mproved wheen we make the offshorre team handle as many acctions as po ossible. So wee suggest to ssee them do aas much analysis and design as possible, subjeect to hat the necesssities are com ming the rrestrictions th from m onshore. When we do sp plit an effort w with onsh hore and offsh hore develop pment teams, we do th his along funcctionality grounds rather tthan activvities. We breeak the system m into broad mod dules and let tthe offshore tteam tackle ssome of th hese moduless. However un nlike most gro oups that do this, we d don't make a big effort to desiggn and freezee the interfaces between tthese mod dules: continu uous integratiion and weakk code ownership allow tthe module in nterfaces to pment goes o on. evolvve as develop An im mportant parrt of this is to enhance the analyyst part of the offshore team. The more someone local to the developeers be aware of
Developer LLocal Projecct Lead
Developer Project Loccal Project Manager r Lead On nshore Offshore
Developer
Developer
must be kkept in perspe ective.
Separatte Teams b by Functio onality Not Acttivity Much of the conventtional philosoophy on the onshore/ooffshore bou undaries is suupported on the activiity that peop ple do. So annalysis and design caan be done onshore, o consstruction done offsshore, and accceptance testing is done onsshore.
Onsh hore Offshore
Develop per
Develop per
the b business, the more the development teeam can d develop profiiciently. Insteead of having to wait overnight to get a questio on answered,, deveelopers can geet answers rigght away ‐ wh hich will rremove hurdles to progresss. All this meeans that you have to ffocus on enhancing the business knowled dge of the offfshore analystt. but the local kknowledge is a This takes time, b vital complementt to the business knowledgge onsh hore.
www.ep phlux.com
White Paaper
5
Building and Managing Self‐Adopting Teams
DefineDevelopDeploy Component Team
Getting Questions Answered The First Time
In order to build working code in a short time box, teams must restructure to contain the three essential skills necessary to deliver software 1) product owners, who serve as consumer substitute and define the solution, 2) group of team members who can develop the code with a minimum of interruptions and an absolute minimum of multiplexing other projects, and 3) integral testing, QA tasks and deployment. This DefineDevelopDeploy component team, or the fractal software unit, if you will, is the cornerstone organizational unit of agility. While eradicating the functional problems that may have stopped teams from organizing this way in the past is not a trivial undertaking, the process does scale in that there is no limit to the number of such teams that can be formed!
One matter that troubles offshore teams is the response time required on posing questions to people who operate in totally different time zones. If a question requires more than one cycle, there can be a delay of three days before an answer reaches, which can really put the brakes on the velocity of your team. This can be moderated in part by adjusting work schedules to make sure at least a few hours of overlap at least a few days per week, during which time‐ critical issues can be worked through in real time.
Regular Reflection and Adaptation A key agile plan principle is "At regular intervals, the team reflects on how to increase effectiecy, then tunes and adjusts its behavior consequently." In agile, this key practice is truly "the gift that keeps on giving" as the empowered, agile teams naturally address and eliminate the roadblocks and impediments that prevent them from continuously improving their productivity. Since this process is not regulatory, it can give some uneasiness to project management organizations, process organizations executives and the like, who tend towards documented, prescriptive and consent processes. And yet, the reality is that these empowered teams will certainly perk up their practices so long as management supports this basic behavior and does not stand in the way.
Another thought that may help is to use message boards or a Wiki in place of email. The offshore team places questions and issues to a common place during their workday. Project team members in the U.S. or Europe address those issues during their workday. If the whole team commits to actively working to keep this "message center" alive, it considerably improves intercontinental communication between teams.
Leveling burden The major wastages in an off shored project are in conditions of extra features, more detailed than required requirements, additional layers of abstraction between the team and the customer, finding relevant information, defects not caught by tests, inefficient hand off to the customer. You have to be careful of eliminating waste by developing only for today’s stories, using story cards which were thorough only for the current iteration and had just sufficient information, coded directly from the stories and for clarification even the offshore team could always be in touch with the consumer, test first
www.ephlux.com
White Paper
6
Building and Managing Self‐Adopting Teams
both developer and customer tests. For leveling of work we always worked according to the team swiftness and made sure that there were no uneven trends in the amount of user stories completed. There is nothing more dangerous in a software project than burnt out team members. Team’s velocity plays a very vital role in deciding who does what and how much we do as a team.
Fabricate a Culture That Pauses to Fix Problems
Team Communication Develop exceptional team associates. unconstrained communication, efficient teamwork, form vs. function of teams, good pay, the best amenities, a safe working atmosphere, a work balanced life, continuous improvement, job rotation. All these when followed in the right spirit can create star teams.
If the offshore onsite team felt that they could not communicate effectively we installed an always on communications machine with always on Skype voice and video channel.
Better communication within different geographies is a core for well‐organized teams. For this we had a lot of seeding visits early the in the project anticipated to create the relationships, and regular visits to conserve the relationships. Of course the purpose of these visits was not to get work done but to get healthy relationships going between geographies.
Once the team felt that the sprint evaluation was not being effective and we were not getting what we desired, we end the valuation, brainstormed on how we can do it better, had an improved kickoff in which we reduced the time spent on the reviews and followed an schedule to guide us through.
People are often unenthusiastic from asking questions, talking about problems, warning about unfeasible time limits, or proposing alternatives to perceived instructions from superiors. Though getting teams to be more practical is an difficult job, and one that certainly takes a lot of time.
If there was a concern with our constant incorporation or performance testing environment then we fixed that first before going further with developing stories.
Become a Learning Organization
Promote a culture to stop work if there is a problem that can affect the quality of the deliverable.
If we developed enough stories but the functionality testers did not have time to test them then we closed developing more stories till the testing team was relaxed with what we had completed so far. All this not only helped us by using counter measures but we were also able to error proof future situations.
This is the most vital principle which has helped us attain where we are today; do precise iteration evaluations for reflections of good things to preserve and areas of upgrading to help us to get better iteration on iteration. Regular and immediate client and team feedback so that eventually aim of the software is comprehended in an effective and efficient way.
www.ephlux.com
White Paper
7
Building and Managing Self‐Adopting Teams
Apart from this we made it a point to get to the source of any problem that we came across by asking why 5 times.
scrum meeting by these self‐organized questions: •
What did I achieve from yesterday morning
•
What do I want to achieve till tomorrow
•
Are there any stumbling blocks for my work
Self Learning These days many organizations working Agile processes are expecting team members to be flexible and be able to work in diversity of situations. In software development we have learned that the software is becoming more and more intricate as the variables of technology and requirements change. In the conventional project management, the project manager was held responsible of the Risks, Complications, Deadlines, Release Plan, Testing, Documentation and etc. On the converse the self‐organized team is set of individuals with diverse skills that complement each other. This team is ordered and re‐organized depending on the project demands, schedules and closing date. This team wears diverse hats depending on the circumstances. This team works on a straight forward statute that "Tell me the actions; but don’t tell me how to act". The team realizes how much work can be done in a precise sprint. Nothing is as de‐motivating as •
Agile = Motivation + Excitement + High Performance
someone else consigning on your behalf. It’s very encouraging to fulfill the responsibilities that you have committed to. A team can be cross‐functional and to such a degree that a developer might do testing when there the testing resources are swamped. Each team member works towards a functional or tangible task for a day. This reflects in everyday
Self‐organizing teams are certainly different from the predictable Manager Managed teams; but it’s a certainly fantastic tool for greater productivity and a fresh breath of air for many.
Tips for Managers Starting off in a right direction is just as important as it ever was. However, with Agile Work, this takes on a appreciably different meaning than it does in other methods as the importance of what is "right" is also significantly different. This is a short technique on how to successfully launch a team using Agile Work.
0. Ground Zero Do whatever you need to do in your organization to get a project and its financial plan approved. This usually involves some sort of business case, project charter and approval process. This may sound evident but the organizational support that this provides is necessary.
1. Requirements Management must have a fundamental understanding of the method and in particular the roles: Queue Master, Process Facilitator and Team. This can be achieved in a number of ways: reading, attending a workshop, or bringing a coach in to do a brief presentation. By "management" is meant at least the person sponsoring the launch of an agile team.
www.ephlux.com
White Paper
8
Building and Managing Self‐Adopting Teams
2. Team Identification Individual people must be recognized to plug the Queue Master and Process Facilitator roles. At first, these people should be allocated to these roles full‐time and freed of their previous duties. Ideally, the people doing these roles are volunteers from a pre‐selected group of appropriate contenders. 3. The Queue Master and Process Catalyst must both get some early training. For this, the following books are recommended for both roles: Agile Estimating and Planning (Robert C. Martin Series), User Stories Applied: For Agile Software Development (Addison‐Wesley Signature Series), and Agile Project Management with Scrum (Microsoft Professional). Unfortunately, all of these books are software‐specific and if you need to apply Agile Work in a non‐software setting, there will be some sweat in interpreting the concepts and practices. You may need more precise training depending on the criticality of your pilot project.
4. Formation Form up the team. Getting this right is not easy: the team needs to stay fairly small (5 people are about right), but at the same time comprise people with all the skills essential to deliver the whole project. You need people who are good at a variety of technical skills needed, the people skills needed, the problem‐solving and analysis skills needed, and
the managerial skills. All these people need to be part of the team right from the beginning. Again, for emphasis: do not start the project before all these people and their skills are devoted to the team and they have been freed of their earlier duties. Developing the team includes logistical concerns such as where the team will sit, making sure they have the right equipment for their work, etc.
5. Debut? If you are trying agile for the first time, don't hesitate using a distributed team or off‐shore resources. Nor telecommuters!
6. Train Provide preliminary training to your team. Include the Queue Master and Process Facilitator in this training (they are considered part of the team). Also include any noteworthy stakeholders in the results of the project. Give them, at least, a one‐day introduction to agile.
7. Configuration Engineer The Configuration Engineer generates an preliminary Work Queue. The rest of the team should take part in this course. The creation of this Work Queue must be time boxed. I advise that it should only be given 1 or 2 percent of the overall project time. Decide before you start on how long will be given to this. The end result of this is a Work Queue that has some number of work items defined, comprehended by the team, valued, estimated, and prioritized. The Work Queue does not have to be
www.ephlux.com
White Paper
9
Building and Managing Self‐Adopting Teams
"finished". It is more vital to hold to the time box than to get the Work Queue "right". Remember that the Work Queue will carry on being refined as the team progresses in its work. Do not under any situation create the initial Work Queue in the absence of the team!
‐ Consider engaging a trainer or mentor for your Process Facilitator. This coach can be someone inside the organization who has extensive experience with agile methods or an external consultant who comes for a limited time to help your Process Facilitator.
8. Project Workshop
None of these optional items should unduly delay the start of the first iteration.
Run a brief project workshop. In this workshop, the team answers crucial questions about the nature of the project run with agile methods such as: ‐ What is the duration of our iterations? ‐ What are the main hours (when do all the team members commit to working together as opposed to working schedules)?
10. Your First Iteration There should be little or no holdups or waiting between the formation of the team and the start of the first iteration. At this point the Process Facilitator is accountable for the process, the Queue Master is accountable for the value delivered, and the Team is responsible for delivering outcomes.
‐ What other teams/groups do we need to work with?
What If An Agile Team Member Won’t Play Ball?
‐ are we missing any critical skills (now that we have seen the initial Work Queue)?
What do you do if somebody in your Agile Development team is just not playing ball? Particularly if their behavior is counter‐ productive to the key principles of Agile Development and is affecting the team's performance. One way is to apply the self‐organized nature of Scrum and allow the team to raise the issues with the person directly and use peer pressure to make them feel uncomfortable in the hope they might leave. Admittedly in this case the person’s behavior sounded mainly bad, but in any incident this is not a first‐class approach.
‐ What are the priorities of the project (quality, scope, time, budget, experimentation, etc.)? 9. OPTIONAL ITEMS: ‐ Consider as doing a workshop on corporate culture and agile methods to facilitate the team understand some of the challenges it will face and where it can find support ‐ Consider doing some initial team building exercises. Particularly if people on the team haven't worked together previously, this can help the team to get over some initial hurdles. ‐ Consider getting junior members of the team some additional training on the techniques, technologies or tools used in the team's work. This can be set so that it is done simultaneously with some of the team's early iterations.
The reality is that not everyone in your team will agree with the philosophies of agile development and some find it practically very difficult to adapt to the very dynamic nature of the process and the lack of clarity and certainty it can bring.
www.ephlux.com
White Paper
10
Building and Managing Self‐Adopting Teams
•
Any discussions must be 1:1 – air dirty laundry in private not in public
If not, perhaps regular 1:1 coaching sessions where you can discuss the day’s events and reflect on the situation outside of the main group.
•
Discuss why the person appears to be finding the Agile Development approach difficult or appears not to be on board
Remember he can’t control his capability but he can control his conduct. In the latter respect, insist that he does.
•
It doesn’t matter how small, and however bad everything else is, catch him doing something right and praise him/her in public (be careful not to patronize, it must be sincere!).
•
If none of this works, consider whether there’s an alternative role that might suit him better – remember agile is not for everyone and some excellent people don’t get on with it. Remember the bad behaviors are a symptom not the cause
•
When you’ve bushed all other possibilities and if the conduct issues remain, if you really are 100% dedicated to the agile approach, you may in the end have to resort to corrective action potentially leading to firing.
•
If you have to take this path, make sure you consult your HR department and follow the appropriate process for your company and location.
There’s only one way to deal with someone behaving badly in an Agile Development team (in fact in any team): •
•
•
Outline why you think that’s the case, using constructive examples of how his behavior is affecting his performance and the performance of the team
•
Tell him what looks good like; in the above examples, how could he have responded and what might the effect have been then
•
Try to understand why they’re behaving as they are; do they disagree with the principles, are they uncomfortable with the process, do they find group working difficult for some reason, or is something else bothering them? Remember bad behavior is a symptom of something else.
•
Adopt a supportive and understanding stance; don’t use personal or aggressive language; use non‐emotive words such as “I feel”, “it’s perceived”.
•
See if there is anything you or anyone else can do to help or support them better.
•
If it’s a case of sentiment uncomfortable with the principles and process, would training help?
Best of Luck! ☺
References
www.ephlux.com
1. www.controlchaos.com 2. www.agileadvice.com 3. www.agile‐software‐development.com White Paper
11