How to destroy a team by introducing various forms of churn?

• Have the Product Management change high-level vision and priority frequently.
• Stop the teams from collaborating with other teams, Architects and important stakeholders.
• Make sure testing and integration is done late in the cycle.
• As soon as a team member gains enough experience on the team move him/her out of the team to play other roles.
• In critical areas of the system, force the team to produce a poor implementation.
• Structure the teams architecturally to ensure there is heavy inter-dependencies between them.
• Very closely monitor team’s commitment and ensure they feel embarrassed for estimating wrongly.
• Ensure the first 15-30 mins of every meeting is spent on useless talk, before getting to the crux of the matter.
• Measure Churn and put clear process in place to minimize churn 😉

To be successful in an agile environment, IMHO team members need to learn the following skills:

• Embracing uncertainty/change and finding effective ways to deal with it.
• Tight collaboration and communication with everyone involved.
• Collective Ownership, Drive and Discipline to getting things done.
• Eliminating Wasting: Mercilessly looking for waste and trying to eradicate it.
• Fail-fast: Breaking a large problem down into small safe-fail experiments and then willing to try & learn quickly.
• Systems thinking: Understanding how things influence one another within a whole system and avoiding local optimizations.
• Critical thinking: Reasonable reflective thinking focused on deciding what to believe or do. In other words; thinking about thinking.
• Open to experimenting with radical ideas

For the last 6+ years, few of us in India, are trying to establish a sustainable Agile community. The truth is that we are still struggling to have a self-sufficient, self-driven community.

We don’t seem to be hosting regular user group meetings. Our sporadic events seem to attract mostly new people each time. Next meeting we rarely see them. Huge number of people sign up, but only a fraction show up.

Its not just the Agile community, we’ve tried many other communities like .Net User Group, TechCamp, GeekNight, BarCamps, etc. Except the Linux community (FOSS now) I don’t think any other software community has really sustained itself.

This is very contrary to what I saw when I used to facilitate the Agile Philly User Group and the Philly GeekNight. People used to drive 2 hrs to attend the meeting. We had the same set of people coming every meeting. We all had this sense of learning and growing together.

What do you think is different in India?

IMHO the biggest problem I see is that there is so much “mediocre job opportunity” available, that frankly software professionals can be in demand for many years without learn anything new. With many people I sense a “there-is-no-need-to-stretch-ourself” attitude. Necessity is the mother of innovation and action. People don’t see the necessity. Period.

There are very few people I know who care about learning and exploring and growing.

Some other problems I see:

• For most people, there is no end to mediocre opportunities and they are happy with it. “This job sucks, but its OK, I get a decent salary.” kind of attitude. The ones who want to purse big dreams mostly move to US or other places. (There are always exceptions to the rule.)
• With all the personal, social life & society obligations and working late to catch up with counterparts in other countries, there is very little time left for user groups and other initiatives. Even if one is interested, the traffic and other logistics make it next to impossible to motivate people.
• There is country culture, but the biggest culprit is the Organization culture. At certain places I’ve worked, if you are not learning new stuff, you feel like a piece of shit. But in many other companies I’ve visited, that’s not the case.
• Indian Software Industry is unfortunately very “brand conscious“. If its a big name speaking at an event, people will walk a whole day to attend the event. But if its a local speaker presenting, it doesn’t appeal.

I’m sorry if you find me ranting, but I’m disappointed with the attitude. I’ve almost lost hope, but may be you can show me the light.

I don’t think productivity is directly influenced by time alone. There are other important factors which make it or break it.

• There are days when I can get a lot done in lot less time and other days life moves slower than a snail.
• There are days when I can stay very focused and productive for up to 15-16 hrs and there are days when couple of hours of work seems like torture.
• There are certain type of tasks that I can get very productive very quickly and certain type of tasks which takes times to get into the flow.
• If I have a vested interest (financial, reputation, learning, etc.), I train myself to stay focused and productive longer (can back-fire as well.)
• There are phases of one’s life when one can clock in more hours and there are phases where one cannot; other things are higher priority. If forced (soft or hard), it usually leads to wrong behavior.
• I’ve seen many people who are very deadline driven (including myself.) I get a lot done when I’m working against hard deadlines. Yes, quality certainly takes a hit, but in many cases delivering slightly lower quality stuff is more important than not delivering at all or delivering later.

If we look at these various aspects, we get close to a start-up environment. And under these conditions, we do see teams being quite productive and delivering interesting products.

Applying this in a different context/environment usually back-fires.

What do you think?

This blog post was trigger by Tim Berry's blog post on Productivity Paradox: Maybe Less is More.

Building on top of my previous blog entry: Version Control Branching (extensively) Considered Harmful

I always discourage teams from preemptively branching a release candidate and then splitting their team to harden the release while rest of the team continues working on next release features.

My reasoning:

• Increases the work-in-progress and creates a lot of planning, management, version-control, testing, etc. overheads.
• In the grand scheme of things, we are focusing on resource utilization, but the throughput of the overall system is actually reducing.
• During development, teams get very focused on churning out features. Subconsciously they know there will be a hardening/optimization phase at the end, so they tend to cut corners for short-term speed gains. This attitude had a snowball effect. Overall encourages a “not-my-problem” attitude towards quality, performance and overall usability.
• The team (developers, testers and managers) responsible for hardening the release have to work extremely hard, under high pressure causing them to burn-out (and possibly introducing more problems into the system.) They have to suffer for the mistakes others have done. Does not seem like a fair system.
• Because the team is under high pressure to deliver the release, even though they know something really needs to be redesigned/refactored, they just patch it up. Constantly doing this, really creates a big ball of complex mud that only a few people understand.
• Creates a “Knowledge/Skill divide” between the developers and testers of the team. Generally the best (most trusted and knowledgable) members are pick up to work on the release hardening and performance optimization. They learn many interesting things while doing this. This newly acquired knowledge does not effectively get communicate back to other team members (mostly developers). Others continue doing what they used to do (potentially wrong things which the hardening team has to fix later.)
• As releases pass by, there are fewer and fewer people who understand the overall system and only they are able to effectively harden the project. This is a huge project risk.
• Over a period of time, every new release needs more hardening time due to the points highlighted above. This approach does not seem like a good strategy of getting out of the problem.

If something hurts, do it all the time to reduce the pain and get better at it.

Hence we should build release hardening as much as possible into the routine everyday work. If you still need hardening at the end, then instead of splitting the teams, we should let the whole swamp on making the release.

Also usually I notice that if only a subset of the team can effectively do the hardening, then its a good indication that the team is over-staffed and that might be one of the reasons for many problems in the first place. It might be worth considering down-sizing your team to see if some of those problems can be addressed.

Impact of Continuous Integration on Team Culture:

• Encourages an Evolutionary Design and Continuous Improvement culture
• On complex projects, forces a nicely decoupled design such that each modules can be independently tested. Also ensures that in production you can support different versions of each module.
• Team takes shared ownership of their development and build process
• The source control trunk is in an always-working-state (avoid multiple branch issues)
  • No developer is blocked because they can’t get stable code
• Developers break down work into small end-to-end, testable slices and checks-in multiple times a day
  • Developers are up-to date with other developer changes
  • Team catches issues at the source and avoids last minute integration nightmares
  • Developers get rapid feedback once they check-in their code
    • Builds are optimized and parallelized for speed
      • Builds are incremental in nature (not big bang over-night builds)
    • Builds run all the automated tests (may be staged) to give realistic feedback
      • Captures and visualizes build results and logs very effectively
    • Display various source code quality metrics trends
      • Code coverage, cyclomatic complexity, coding convention violation, version control activity, bug counts, etc.
• Influence the right behavior in the team by acting as Information Radiator in the team area
  • Provide clear visual feedback about the build status
• Developers ask for an easy way to run and debug builds locally (or remotely)
• Broken builds are rare. However broken builds are rapidly fixed by developers
  • Build results are intelligently archived
  • Easy navigation between various build versions
    • Easily visualization and comparison of the change sets
• Large monolithic builds are broken into smaller, self contained builds with a clear build promotion process
• Complete traceability exists
  • Version Control, Project & Requirements Managements tool, Bug Tracking and Build system are completely integrated.
• CI page becomes the project dashboard for everyone (devs, testers, managers, etc.).

Any other impact you think is worth highlighting?

Traditionally, in many product companies, a few senior people  at the “top” did most of the “creative” thinking/planning and the majority of the workers actually just follow their directions to build the products or deliver the services decided by the creative types.

This style of centrally managed Cathedral model management where each successive layer of management informes the next level down is rapidly falling apart. More and more companies are moving towards a flatter organization. Towards a Bazaar model. This is true since more and more people are doing the cognitive work rather than manual work. Smarter workforces needs empowerment and hence need fewer managers and fewer levels between themselves and the “boss”. They demand the cognition be distributed and people on the ground make decision close to the context.

To some extent, the open source model has paved the way for this style of org. structure in the software world. Also various collaboration and social interaction tools have emerged over the last decade which really help to scale a flat organization.

It will be interesting to watch how giant companies will structure themselves to compete with the Start-ups.

I once worked for a manager (a.k.a Scrum Master) who insisted that we should have at least 85% code coverage on our project. If we did not meet the targeted coverage numbers this sprint, then the whole team would face the consequences during the upcoming performance appraisals. In spite of trying to talk to her, she insisted. I would like to believe that the manager had good intent and was trying to encourage developers to write clean, tested code.

However the ground reality was, my colleagues were not convinced about automated developer testing, they lacked basic knowledge and skill to do effective developer testing and the manager always kept them under high pressure. (Otherwise people would slack, she said.)

Now what do you expect to happened when managers push certain (poorly understood) metric down developers’ throats?

Humans are very good at gaming systems and they do a wonderful job.

• Some developers wrote automated tests with ZERO assert statements
• Others wrote complex, fragile test code which was an absolute maintenance nightmare. Their coverage numbers looked impressive.
• Me and my pair wrote a small test which would simply crawl all the code base. We were able to achieve 99% code coverage. (1% intensionally left, so we don’t look suspicious.)
• And so on…

The manager was very happy and so was the team. This went on for some sprints. One could find our manager showing off to her colleagues about how much the team respected her words and what a command she had on us.

Alas, her happiness lasted only for a few sprints. One fine Sprint demo day, I convinced the team to showcase our dirty little secret to all the stakeholders and management.

The event did shake up the management. It also sent out a clear message.

Code Coverage measures which line of code got executed (intensionally or accidentally) when you run the program or tests against the program. Code coverage tells you nothing about the quality of your tests, hence nothing about the quality of the code. Code coverage along with Cyclomatic Complexity can be used by the team to guide them, but not by management to judge the team.

Today we are in a knowledge economy and upgrading employee’s knowledge portfolio is the most important investment companies can make. But in this obsession for learning, our industry is spending a lot of money and is very heavily relying on formal learning.

Companies fail to realize 75% of actual learning comes from informal learning. Learning happens as the learner creatively adopts and adapts to ever changing circumstances. Its important to acknowledge that informal learning is crucial to learning how to do anything.

According to a study of Time-to-Performance done by Sally Anne Moore at Digital Equipment Corporation in the early 1990s, and repeated by universities, other corporations, and even the Department of Health and Human Services, following image graphically shows the disparity between formal learning and informal learning.

In “At the Water Cooler of Learning” article by David Grebow, he explains this graph with a very nice example.

IMHO formal training might be a good start, but deliberate practice on pet projects and on real world projects is the source of real learning. Necessity is not just the mother of innovation, but learning too.

To amplify your active informal-learning, make sure you:

• spend enough time at the water-coolers in your office
• attend user group meetings
• participate in online forums
• follow interesting people on twitter
• regularly read other people’s blogs (and source code)
• leverage all the Web 2.o Social Media forums
• attend a conference (esp. open space or workshop based conferences)
• and so on…

At the Agile Mumbai 2010, Mahesh Baxi takes you through an exciting journey of key lessons learned from one of the largest agile projects executed at ThoughtWorks which will cover:

• Key agile principles
• What challenges comes along with the scale of up to 200+ people with added complexity of distributed location
• How is it different from other agile projects in terms of planning ahead, release plans, scope management, infrastructure
• Communication – The most important ingredient for large scale agile projects to be successful
• What kind of team structure would work best?
• How to stay focused? How to identify bottlenecks and work through them