Tag Archive: self-organizing teams


US National Archives - Creative Commons image

Workers assembling radios. Photographer Lewis Hine. US National Archives – Creative Commons image

Typically in plan driven model, scope is fixed and the cost and schedule are variables.  Many large scale software projects were and continued to be implemented this way.  In many instances, when a particular scope is desired within a giving time-frame (fixing the schedule), plan driven projects add resources.  But as we know simply adding resources to a project doesn’t always bring about the desired goals.  As a matter of fact, if resources are added late on a software project, it actually has an adverse effect.  This was indeed observed by Fred Brooks in his book The Mythical Man Month, also known as Brooks’ Law: “adding manpower to a late software project makes it later”. 

With Agile software development, the triangle gets  inverted – where cost and schedules are fixed and the scope is variable.

Waterfall-Agile Triangle

Even for Agile projects, there could be instances when a fixed scope is desired within a given time period.  For example, when an external entity drives a compliance or mandated project.  In those instances, the only lever stakeholders may have is adding resources for a delivery with fix scope and schedule.  But, are there better ways to add resources or capacity to an Agile project without falling in the same traps of experienced with plan driven methods?

Before we answer that, lets briefly consider teams on Agile projects.  Agilists  have generally made 2 recommendations for effective teams:

  • Keep team intact or stable for a long periods of time
  • Keep team size between 5-9

A recent paper called The Impact of Agile Quantified seems to support these two recommendations out through empirical data.

Stable teams, defined as having less than 10% membership change in a 3 months period vs Unstable teams defined as 40% variance in their membership tend to:

  • Have more throughput (volume or work)
  • Have less variance in their  throughput (they are more predictable)
  • Have less defect density (higher quality)
  • Have less time in process (better time to market)

From the same research findings, teams of 5-9 team members have the most balanced performance when it comes to predictability, productivity, quality and responsiveness.   Generally, smaller teams (of 1-3 people) are 40% less predictable and have 17% lower quality; however, they do have 17% more productivity.

Instability in Agile teams can happen sometimes which may not be in direct control of the resource managers.  Like, for example, a team member gets promoted or changes positions or leaves the company altogether.  In some instances, a resource manager may also have to move team members due to skills match, team dynamics or performance considerations.

So given these findings, what would be the best options in adding resources to an Agile project or a release?  Creating a whole new cross-functional team of 5-9 team members during early to mid part of the project along with a Product Owner and a ScrumMaster (presuming you are following Scrum) would be the best option.  This will allow added capacity without running foul of the Brooks’ Law.

But if the budget add doesn’t allow addition of an entire new Agile team, then other viable options becomes little less ideal.  One option would be to add team members to an existing team to make them more cross-functional or remove a crucial skills constraint, so the team becomes more self-sufficient.  The other option is to shore up smaller teams that have less than 5 team members.

Alternatively, you can level-off a larger team and form 2 teams.  Take for example, there is additional funding for 4 team members and Original Team A makeup: 9 team members + PO + SM.  Form Team B: 5 team members – 3 new team members + 2 team members from Team A (presumably a team member can initially serve as SM initially) and  a PO.  Now New Team A would be: 7 team members + PO + SM.  Since, both teams would be within the ideal size range, and assuming you are able to maintain the cross-functional nature of both teams, you can still reap the benefits of higher throughput, better quality, more predictability and better time to market.  Again, these aren’t the best options because affecting existing well performing teams will inevitably create an initial setback as new teams re-form and then re-norm.

Ideally, if short term results are desired, say within a quarter, scope reduction is probably still the best option instead of disrupting Agile teams.

(image from geograph.org.uk)

In one of my previous post titled You Might Not Be Agile If , I outlined some agile anti-patterns.  Recently, I come across couple of anti-patterns that make good fodder for discussion.  Both these patterns are something a Scrum Master should be able to avoid, corrrect.

Anti-Pattern: Only using partial team to size the backlog

 
The first one is where a team used only developers in sizing stories.  Well, is it any wonder then, that the team discovered itself in bind? Testing tasks turned out to be too large.  Surprised? The sprint committments got  jeopardized?  And is it suprising that team members ended up putting in extra hours to try and salvage the sprint?  In this particular instance, the reason was:  some team member felt the sprint planning sessions were getting too long.  So a select few team members pre-sized the backlog and tasked out the stories ahead of the planning meeting.
 
Now, there is a reason why we strive to construct cross-functional teams.  And we prefer using a consensus based estimation process such as planning poker.  We want to avoid, what some quant-driven companies have started calling –  HiPPOs hijacking and monopolizing the decision making process.  HiPPO stands for highly paid person’s opinion or alternatively, a highly positional person’s opinion. 
 
If a team lead, a Scrum Master, a Product Owner, a single team member, or a functional group “Hippos” the team, then that stunts the team from self-organizing.  You are back to command-and-control decision making structure and you miss out on the wisdom of the team – not very agile!  The planning poker or similar agile estimation process involves all team members, and it expects that all views and perspectives are allowed to be expressed, shared and discussed.  Two good things come out of the process, one is that you get a team members’ committment, not just compliance.  The other is that you get a much better and realistic view of your work, and you have intrinsically motivated agile team that owns the estimate and will do everything in its power to deliver on it.
 
But aren’t agile teams suppose to move fast?  Time-boxes are of course very important, but so is discipline.  If you don’t involved all team members, or if you short-change the consensus building process, you get uneven results.  What’s more involving the team allows it to gain tacit knowledge through meetings and conversations, which makes them better at getting things done.   
 
At the same time, agile teams are not deliberating, debating bodies.  They exist to produce great working software.  Reason given here was that the team wanted to have a shorter planning meeting.  So let’s talk about that.
 
The general rule of thumb that has worked for many teams is to allocate 1-2 hours per sprint week for the planning meeting.  Say you have a 3-week sprint, then normally your team should allocate anywhere from 4-6 hours of planning.  To make sprint planning go faster, there are few practices you can follow:
  • PO has already communicated her priority stories for the upcoming sprint during grooming sessions, which are taking place during off-planning weeks.  All prioritized stories are well understood and sized by all team members.
  • Most agile planning software allow you to copy a story.  So a good time saving practice is to create a “template” story which contained often encountered tasks.  The Scrum Master as part of his sprint planning session preparation can then copy this story, overlay the actual story card and the acceptance criteria.  This approach has another benefit too.  You can embed tasks associated with your story done criteria, which then serves as a good checklist for the team.  For example, if  your team forgets peer code review task on every story, then having an explicit task  as part of the template serves as a good reminder for the team to include for every story.
By the way, the team size matters too when it comes to having an efficient sprint planning meeting.  Having a goldilock-sized team of 7 (plus or minus 2), allows consensus building to occur without a huge time sink and makes for faster sprint planning.  I recall, a team that chose to go with 15 team members, their planning meetings used to drag out to almost two full days (14-16 hours) for a two week sprint!  How productive is that?!
 
Anit-Pattern # 2: Committing on more work than what can be delivered.
But is there maybe another deeper anti-pattern as a cause for this team that chose expediency over allocating “right” amount of time for sprint planning.  Could be that, they are trying to shove a whole lot more work than they can realistically take on during a sprint?.  (No time to waste, can’t you see, I have more code to shovel over to production, every day, so I will take any and all shortcuts possible, especially if I can avoid having uncomfortable conversation with my stakeholders!)
 
If that is really the issue, than there are good practices you can follow.  I have found that when doing capacity planning, it is better to start the team’s capacity at 80%.  So, if you have 14 working days (counting 1 sprint day towards demo, retrospective and planning meetings for a 3-week sprint), each team member will have , roughly, 90 working hours (14x8x0.8).  Using 80% capacity means that you do not have to account for tracking all the overhead minutiae such as company or team meetings, emails, water cooler chats, birthday celebrations, or just team members taking time to be helpful, or honing their own skills.  (An aside: this is also another reason, why I think it is a bad idea to use agile lifecycle management software for project time tracking.  It distracts from delivering good software and makes accountants out of team members).
 
Then, you subtract any “planned” PTO time.  Next comes any production support work that your team generally has to respond to.  The percentage varies from team to team.  Using a rolling 3 sprint average to even out the spikes as your starting point and adjusting according to your circumstances, works.  It is also a good practice to task out 1 or 2 more stories, over and above your team velocity.  So in case, you end up using less than your allocated production support capacity, you have a ready story to work on.
 
And finally, subtract any earmarks from your capacity.  For instance, many teams negotiate with their Product Owner and stakeholder, part of their capacity towards fixing defects, or doing test automation, or for code refactoring. 
 
If your team doesn’t account for all these things up front, you are probably operating on an illusion that you are going faster.  In reality, you are probably spending more and more time in remediating code and responding to production emergencies.  If you want to read more on this anti-pattern, check out Mark Lawler’s recent post called Sprint Planning Like It’s 1999
 
You say,  if I do all these things, there is no way, we are going to converge towards our project goals?  Maybe.  But, equipped with data, you may have a difficult, but an honest conversation with your stakeholders.  Should quality and delighting customers be sacrificed to meet the deadline, or should other creative solutions be explored?  Should we invest some time in building good software, or should we pay a whole lot more later?

Department Store - Mall (© Aashish Vaidya)

Last month, like millions of other shoppers, we headed to a department store.  We noticed that the associates were little more cheerful than in the past.  Maybe this was new a crop of temp workers who took to their jobs with gusto or just existing employees, who were spurred on by new spirit of customer service.  Within minutes, an associate greeted us warmly and moments later another one engaged us directly.  Not content with just a friendly hello, he went on to mentioned items that were on sale, especially the wool jackets, which we noticed we were passing by.  When I mentioned that I already had a short wool jacket and a long overcoat, he looked at my wife and said “well, he can always add a third in his wardrobe, right?”  Unlike typical mall-store employee, it seemed like this guy actually knew to appeal to the real decision maker.  Well, the power of suggestion was already at work and we figured that it might actually make an appropriate gift for someone on list.

As I was trying out a jacket, a third associate came by.  “Wow, ” she said, “this really looks good on you.”   When I told her that we were looking for a jacket for someone else, someone older.  She immediately went on to recommend a more conservatively styled, but a considerably less costly jacket.  This was refreshing, she was really trying to help us come up with a gift that suitable, instead of trying to power selling.

We did like the jacket she suggested, but, the store did not have it in the size we wanted.  No problem, the associate assured us, she’ll just look one up in the system and have it shipped.  She was able to locate a jacket, and we proceeded to make payment, partially with their store issued gift certificate and the rest with a credit card.  And this where things got little more interesting with a seemingly ordinary transaction.  Her system would not accept the gift certificate as a partial payment.  No problem, the associate consulted with her teammate and figure out, she can exchange the gift certificate for a gift card.  And then she processed the payment.  Nice, it was admirable to see the associate and her teammate being resourceful and making the extra effort to complete a sale.

But, the very next day, we got an email simply stating that the order was canceled and no money was charged to the credit card and the value of the gift card was reverted back to the card.  Hmmm, hello, that’s a problem!  As the gift card was fully used, so as we generally do in this situation, we had already handed the gift card back to the store associate to recycle it.

Groan – that meant having to deal with the Customer Service department.  After the usual dreadful shuffle of getting through the labyrinthine IVR system, about 30-40mins later, we got a live rep.  This rep, though, had none of the warmth and the level of engagement that the store employees exhibited.  Instead of expressing any type of regret, he told us  that a new gift card to replace our old one should make its way to us in 7-10 days.  And if we were still interested in buying a jacket, we can pick it up at a store that was about 20-25miles away, but it was no longer on sale.  And if we wanted it shipped, there would be additional shipping charges.  None of the compelling reasons of value or convenience existed for us, so we declined his offer of having the nearby store hold the item for us.

About 10 days elapsed, when the gift card didn’t show up, another call to the customer service had to be placed.  Good 45 minutes later, a “friendly” CSR,  said she couldn’t find any record that we had talked to someone about 2 weeks back in the system.  But she would revert the value on the original gift card.  Umm, deja vu, didn’t we just go through this before!  After patiently explaining to her that we no longer have the said gift card, she asked us if we can contact the store to see if they had the card.  Uhh, does she really think the store clerks would really have that particular gift card on their hands after 2 weeks?  We leaned on her, and had her finally agree to send a replacement gift card.

I recount this experience in some what details,  as this  raises a few interesting IT related systems and management questions:

  • Why would the POS (point of sale, not the other type!) system not work with the store issued gift certificate, but work with a gift card?  Did someone put in a weird business rule that no one can fathom and the frontline sales associates are left to fend for themselves?
  • Why did the system allowed overselling an item when it showed there were plenty of units available at the time of purchase?  Was the inventory not real time?  And if so, was this a usability issue where the system should have alerted the sales associate not to make the sale and have a problem until the actual inventory count is confirmed?
  • Why wasn’t the system handling a gift card related cancellation differently?  Did it always presumed that the customers will keep their spent gift card, on which the value could be restored?  Or did a product owner did not hand a properly written acceptance criteria or acceptance tests to the software IT team?  Or that the software implementation team never bothered asking?
  • Was customer service department cluelessness, a vendor management issue (if it was an outsourced vendor)?  And why wouldn’t the company properly empower their CSRs  to actually make a sale when they are in a live, high touch customer interaction?  Many other retailers have already figured this out, their store clerks or their CSRs can ship products from their warehouses or from any stores either to a convenient store location or directly to the customer.  So this was a lost opportunity.

The net effect of this was a dissatisfied customer, who lost a lot of their time and use of gift card for days.  And it was a huge waste of effort for the frontline sales staff, which worked diligently and creatively to problem-solve and make the sale.  And for the retailer, this is still a revenue sapping transaction, as it still might generate more customer service calls (the replacement gift card is yet to arrive at the end of the promised delivery window).

As IT and software professionals, many times we are so removed from actual users of our systems that we don’t provide the type of support the frontline associates need, or we don’t ask the right questions from our business or product owners.  In this particular instance, the value chain wasn’t aligned from front to back.  The system wasn’t aligned with a single focus – make a sale with least waste and satisfy the customer.

But, lest you think this is just another rant (which it is!) on usual poor customer service of a big department store, I will close with a very interesting observation we made at the store.  While we were waiting for the transaction to complete, we saw a few store associates in an impromptu “huddle”, where one of the teammates reminded others to keep restacking clothes and tidying up all the floor space.  There was even a mention to balance the engagement with customers, while at the same time flowing around so other customers feel just as welcomed.  Nice, a wonderful example of inspect and adapt.  Now only if the frontline staff can extend this spirit to their CSR and IT departments.  And if the CSR and IT departments really learn to have their spirited frontline’s back, they will be on to something!

Recently, at work, we have gone through some major organizational changes.  We have moved away from an IT organization that was a collection of functional silos – Architecture, Design and Analysis, Application Delivery, Release and QA, and so on –  to more integrated groups aligned with our business units.  As we move towards more cross-functional, self-organizing agile teams, colleagues have noticed that many of us feel a bit disoriented.  Many don’t know what to do, many have a negative reaction to the changes and then there are some who have already accepted the changes, and are impatient that there team mates are too slow to change.

Reactions to Change

As we experience change, Elizabeth Kubler-Ross defined and categorized our psychological reactions to it:

We find  that people react to change differently and they might be anywhere along this change spectrum, including in the “pit of despair”.  And each need different type of support.  For those in shock and denial need information and communication.  Those who have self-doubt and inching towards acceptance, need emotional support.  And those who are exploring and understanding, need direction and guidance.

The Rider and The Elephant

The Elephant and the Rider (credit aashish vaidya)

Another framework to understand and initiate change is developed by Chip Heath and Dan Heath in their book Switch.  They note that our brains have two independent systems at work:

First, there’s what we called the emotional side.  It’s the part of you that is instinctive, that feels pain and pleasure.  Second, there’s the rational side, also known as the reflective or conscious system.  It’s the part of you that deliberates and analyzes and looks into the future.

The Heath brothers adopt the terminology of the Elephant (the emotional side) and the Rider (the rational side) introduced by University of Virginia psychologist Jonathan Haidt in his book The Happiness Hypothesis.  This isn’t necessarily a new concept, as you find variations articulated by Plato, Freud and many others.

When we are in midst of change, like moving our software development from waterfall to agile methods, or getting better at adopting and refining agile methodology; or for that matter any other type of change effort, we need to understand both these aspects of our brains – The Rider and The Elephant.  This is how the Heath brothers define it:

The Rider provides the planning and direction, and the Elephant provides the energy.  So if you reach the Riders of your team but not the Elephants, team members will have understanding without motivation.  If you reach their Elephants but not their Riders, they’ll have passion without direction.  In both cases, the flaws can be paralyzing.  A reluctant Elephant and a wheel-spinning Rider can both ensure that nothing changes.  But when Elephants and Riders move together, change can come easily.

It is possible to get our rational side to exert control over our emotional side, but that can prove exhausting for the Rider.  To illustrate this point, Dan Heath in this FastCompany video and article, and also in the book, recount a study about radishes and cookies.

Will to Change is Finite

College students (the usual guinea pigs in these types of studies) were asked to fast for 3 hours and report to a study about food taste perception.  They were then led to a lab that smelled amazing from freshly baked chocolate chip cookies.  In the middle of the room were 2 bowls – one filled with cookies and another with radishes.  Half the participants were asked to sample the cookies but not radishes and another half to eat radishes only.  Then the researchers left the room.  The cookie eaters probably had no issues resisting the urge to eat the radishes!  However, despite the temptation, the radish-eaters showed amazing willpower and did not eat any of the cookies.  Here is where another set of wily researchers came in and declared that the taste perception study was over.  But, they were doing another study about problem solving.  At that point, they asked the participants to solve a puzzle.  Unbeknownst to the participants, the puzzle had no real solution.

What the researchers were trying to find out was whether there was difference in a way the cookie-eaters and the radish – eaters approached the puzzle?  Well, it turns out there was.  The cookie-eaters made 34 attempts at the puzzle and persisted for 19 minutes.  The radish-eaters made only 19 attempts and gave up in half the time.  Why is this?  Well, study shows that the radish-eaters who were tempted to eat cookies but did not, simply ran out of self-control.  So when another challenging task – solving an impossible puzzle was giving to them – they were simply exhausted.  Of course, your takeaway from study shouldn’t be , eat more cookies and not radishes.  But, it should be that the will to change is indeed finite.  The Heath brothers say, “what looks like laziness is often exhaustion.”

IT organizations, when they decide to change from traditional waterfall software development, or initiate any other major changes, find many team members, managers and business partners show reluctance to these change efforts.  In many instances, it is because their Elephants are genuinely spooked at the spectre of losing the clout they have built in an organization or potentially losing their jobs, or myriad of other real and imagined fears.  Change induces a fight or flight response.

Many times, we share information about changes, appealing to the rational brain, but we don’t really address “what is in it for me” part of the equation.  That is, we don’t engage the emotional side.  And so the changes simply don’t stick.  Our rational side tries hard, but in the end, the willpower dissipates. This is due to skittishness of  our emotional side, which is “often looking for the quick payoff”, at the expense of long-term gains.  Change management saps our willpower, if we don’t find a way to motivate our emotional sides.

In my next post, I will continue to explore more on the change management theme.

This slideshow requires JavaScript.

As I read reports on the Occupy Wall Street and related protests, as a person interested in agility, I am intrigued to find commonality amongst them.  The protests are a collection of individuals with variety of grievances, coming together with a common theme.  These protest essentially are ongoing experiments in self-organization, using consensus as their primary decision-making, and adapting to various changes.  All this, without a command-and-control hierarchy.  These are the same concepts that the software development community, and organizations, are adopting to find better and different ways to work.  Self-organization, consensus driven decision-making and adaptability are all agility concepts.  And this is what makes these protests interesting at many levels, irrespective of what opinion you might hold about them.

Self-Organization

An article on a local tv website, here in Portland, reported that the protests are not as chaotic as many would expect:

On the outside, the protest might seem a bit odd — there’s music, performers and a bunch of different smells.  But a closer look reveals that it’s not the chaos one might expect. Just stop by the information desk, which is one of about 20 committees helping to run the place, to find out more. There’s even a finance committee.

Reporting on the Occupy Wall Street protests, USA Today states the group has received nearly half a million dollars in donation.  And they continue to receive $8k everyday from lock boxes:

The cash has forced changes in the “finance working group” that arose spontaneously among the self-governed protesters. Buckets were once used to collect park donations, and until recently, a 21-year-old art student played a key role in the working group.

It further states:

The amorphous group has no clear plans yet for spending much of the money. For now, the fund doles out $100 a day to each of the dozen “working groups” that keep the month-long protest going — from sanitation and medical to finance and media.

Look at the language these reports use – self-governed, working groups, various level of specialization (finance, medical, media, etc.).  We use similar lingo to describe our own agile teams.  As both of these reports show, Wall Street, Portland and many other groups are self-organizing and provide operational structure and cohesiveness.

Consensus Building and Adaptation

Having organized themselves, these groups are also adapting and managing new impediments as they show up.  For example, the organizers, now are having to contend with those who are there for the cause and those who come there for partying.  The Oregonian says, these groups are using consensus driven decision-making to deal with new issues, like dealing with weapons and substance use:

In an effort to control the Occupy Portland campsite, the movement’s consensus government imposed rules of conduct Monday night for participants, including no weapons and no derogatory language. More volunteers are wearing white strings around their arms indicating they are camp “peacekeepers” with authority to calm disputes.

The groups are coalescing and arriving at organizing principles without any hierarchical decision-making bodies:

Occupy Portland vigorously resists the concept of “leaders” and instead calls organizers “facilitators.” Ethan Edwards, a facilitator who has been at the campsite since Oct. 6, said demonstrators walk a blurred line between protesting the nation’s economic disparities and caring for the chronically homeless and mentally ill who have moved in with a less political purpose in mind — such as partaking of the free meals served daily.

“Ship It”

As the Occupy Wall Street (OWS) protest gets beyond the one month marker, many have already started writing obits citing various reasons.  Here are some of the reasons Brend Arends at Marketwatch gives: they are in the wrong place (instead of protesting in lower Manhattan, they should be in up in Greenwich against the hedge fund honchos), the weather is turning, big money will eventually drown them out, and that the public at-large will forget about them.

And of course the bigger reason  –  they don’t have an agenda.  All of these reasons are plausible and may prove out to be true and protests may eventually die out.  For Occupy protests  to sustain themselves and to continue to hold people’s attention and support, they will have to develop a larger agenda and a coherent strategy.  In this sense, they have a myriad items or stories in their backlog that needs to be groomed, ordered and prioritized; themes that needs developing, releases to be planned; and they to articulate a sustaining product vision.

It is quite possible, these protests will never get beyond the expression of anger against the inequities that many feel.  They may buckle under impediments big and small, and fissure.  They may never find the cohesiveness and unifying vision to propel themselves forward.  But, for now what started in lower Manhattan has given voice to many who are affected by many incongruities and ill-effects of the lingering Great Recession.  In this sense, they have already “shipped” their first product (angst) by inspiring many such protests across the globe.   Self-organizing teams using consensus based decision-making, operating within constraints, is interesting to watch and witness.

Personal Reflections

I wanted to keep the post as apolitical as possible, but gotta ask, what’s up with Oakland police?  The protests have resonated the world over, even in the egalitarian Netherlands.  Over at Financialagile, Jamie Dobson has a beautiful writeup on reasons why he attended Occupy Amsterdam.

At the most fundamental level, all protests are a form of political theatre.  So about 2 weeks ago, I took my boys (8yrs and 10yrs), to the Occupy Portland protest, which has camped itself into two downtown parks (the pictures are from that visit). I figured this is a good way to show them how citizens exercise their right of free speech and assembly. In a larger context, I wanted my sons to begin understanding that when the protestors use peaceful means to raise awareness of their grievances, they have good company.  That is when they are part of long thread that weaves through civil disobedience of the transcendentalists, to their own heritage of satyagraha, to the civil rights movement of the 60s and the more recent examples of the Arab Spring.

%d bloggers like this: