building and managing self-adopting teams · building and managing self‐adopting teams 4 white...

1 Achieving Offshore Agility

White Paper

Author: Ali Zaidi

Research and Development

Application Services

Building & Managing Self‐Adopting Teams

Building and Managing Self‐Adopting Teams

www.ephlux.com

White Paper

2

Surety Not so sure Far Low Surety

Simple

Complicated

Complicated

Anarchy

Close to

Agreemen

t Req

uiremen

ts Far From Agreemen

t

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 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.

Team Formation To manage the complexity inherent in systems development projects agile processes utilize self‐organizing teams. A team of individuals is formed. They organize themselves into a team in 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‐organization is a breath of fresh air if 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 workers what to complete by the deadline. This violates the rule of common sense “You can tell me what to do but not how to do it.” Within 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

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.

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

team collaboration and self‐organization are restricted. Team size should be maximized almost to the breaking point to maximize the efficiency and productivity.

Complex

www.ephlux.com

3 Building and Managing Self‐Adopting Teams

White Paper

Agile == Constant feedback to individuals+ that all team members share awareness of team activity and team commitment to goals

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

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 ‐

organization with the rest of the team. Always

www.ephlux.com


White Paper

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

Project Manager

functionathe team customerfocuses that the endsystem toexcuses, n

The team do! The sewithin suctake the dScrum doessential fof modern

OffshorAgile Teamsimilar wa

must be k

SeparatNot ActMuch of onshore/othe actividesign cadone offsdone ons

Onr

Loc

lity that delivexhibits the f. Pre‐knowledhe team’s cond of the Sprino the consumeno one to poi

is bound to dense of deterch teams is odependabilityes so, assistinfor teams to fn software de

re Agile Tms in an offshay as well but

kept in perspe

te Teams btivity the conventoffshore bouity that peopan be done oshore, and acshore.

nshore Offshor

cal Project Lead

vers business functionality dge of this dencentration. It, it will exhiber and managnt at.

do what it sairmination andbvious. If youy, give me theng the self‐orgfocus on the evelopment p

Team Guidhore mode wt certain key e

ective.

by Functio

tional philosoundaries is suple do. So anonshore, conscceptance te

e

www.ep

Devel

Devel

Devel

value. Now to the emonstrationt knows that bit the gement. No

d it could d pride u want me to e power. ganization complexity projects.

delines orks in a essentials

onality

ophy on the upported on

nalysis and struction sting is

phlux.com

Bu

oper

oper

oper

L

Contmakas pomucthe rfromonshdo thactivmodof ththat desigmodownevolv

An imanalysom

the bcan dwaitdevewill rthat busiThis vital onsh

uilding and M

Local ProjecLead

trary to this, me the offshorossible. So weh analysis anrestrictions thm onshore. Whore and offshhis along funcvities. We bredules and let these modulesdo this, we dgn and freezedules: continuership allow tve as develop

mportant paryst part of theone local to

business, the develop profi overnight toelopers can geremove hurdyou have to fness knowledtakes time, bcomplementhore.

Onsh

Managing Self‐

ct

matters get imre team hande suggest to sd design as phat the neceshen we do sphore developctionality groeak the systemthe offshore ts. However undon't make a e the interfacuous integratithe module inpment goes o

rt of this is to e offshore te the develope

more the deiciently. Inste get a questioet answers rigles to progresfocus on enhdge of the offbut the local kt to the busin

hore Offshore

‐Adopting Te

White Pa

Develop

Develop

Develop

mproved whele as many acsee them do aossible, subjessities are complit an effort wpment teams,unds rather tm into broad team tackle snlike most grobig effort to es between tion and weaknterfaces to on.

enhance the am. The morers be aware

velopment teead of having on answered,ght away ‐ whss. All this meancing the fshore analystknowledge is ess knowledg

5 ams

aper

er

per

per

en we ctions as ect to ming with we than

some oups

these k code

e of

eam to , hich eans

t. a ge

www.ephlux.com


White Paper

DefineDevelopDeploy Component Team 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!

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.

Getting Questions Answered The First Time 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.

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

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 Promote a culture to stop work if there is a problem that can affect the quality of the deliverable.

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.

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.

If there was a concern with our constant incorporation or performance testing environment then we fixed that first before going further with developing stories.

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.

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.

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.

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.

Become a Learning Organization 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

• Agile = Motivation + Excitement + High Performance

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.

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

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

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‐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

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

"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!

8. Project Workshop 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)?

‐ What other teams/groups do we need to work with?

‐ are we missing any critical skills (now that we have seen the initial Work Queue)?

‐ 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.

‐ 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.

None of these optional items should unduly delay the start of the first iteration.

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 If An Agile Team Member Won’t Play Ball? 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.

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

There’s only one way to deal with someone behaving badly in an Agile Development team (in fact in any team):

• Any discussions must be 1:1 – air dirty laundry in private not in public

• Discuss why the person appears to be finding the Agile Development approach difficult or appears not to be on board

• 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?

• 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.

• 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.

Best of Luck! ☺

References

1. www.controlchaos.com 2. www.agileadvice.com 3. www.agile‐software‐development.com

building and managing self-adopting teams · building and managing self‐adopting teams 4 white...

Documents