J B Rainsberger & Naresh Jain share their experience on coaching agile teams. They present:

1. How to apply Theory of Constraint [ToC] to identify the bottlenecks or issues the teams are facing during their agile adoption?
2. Once we identify the bottleneck, how we delivered knowledge and experience to the teams, just in time to apply that knowledge to eliminate the bottleneck, using the Just-In-Time practice concept?

This 90 mins workshop was presented at the Agile Mumbai 2010 and Agile Bengaluru 2010 conference.

This morning I got hooked to a new band. I’ve heard the band before and I’ve had others praise the band. It was only this morning, when I stumbled upon a particular song by the band and started enjoying it. After that I went and explore the whole album and other albums. Its been 8 hours and I’ve been tripping on their music.

To think about it, software is kind of same. Usually its one sticky (killer) feature that gets people hooked to a new software. Once they experience that feature, without much push, they discover all kinds of interesting features and innovative ways to use them.

As someone building a new product how do you figure out what that feature would be?

I’m aware of 2 approaches that have worked in the past:

• Agile/Lean-start-up philosophy: Build sketches (quick and dirty versions) of a few features, put it in the hands of real users and see what might click.
• Open Source/Eat your own dog food philosophy: Build something that addresses your personal itch and see if others have the same itch.

What other approaches have you seen work?

What do you do when your team/company is all excited to be “agile”, while your customers want to operate in the traditional, heavy-weight, documentation-driven approach? Every now and then I run into Customers or companies dealing with Customers who insists on writing pages of requirement document, with specifications as vague as the night sky, insist on accurate estimates (oxymoron) on turnaround time at the moment of document handover and to not be involved again until they receive the software they asked for?*

IMHO this is one of the biggest issues teams face when they want to use more Agile ways to deliver software. I’ve been in similar situation and sometimes have been able to influence the customers to collaborate more. Sometimes I’ve not been able to. Following tricks have worked for me in the past:

1) First and foremost, it’s worth understanding why they are opting for this approach. In most cases it turns out that they don’t trust the software team and hence they want to push all the risk to the software development side. May be they have burnt their hands in the past. May be their hands are tied. Or may be they are just ignorant of the fact that this is an extremely sub-optimal way to build software. Seeing the world from their point of view, helps me understand where they are coming from. If one is able to see the underlying driving factor and break that bubble, things can get lot more constructive. For Ex: if Risk is the underlying factor, showing them how risky their approach is, can turn things around.

2) Sometimes during the scope discussion of the project, I’m able to highlight things that they’ve not thought through. Sometimes I’m able to hit the nail where it hurts the most. Immediately, the customer moves from a stand where they were saying “We know it all, just build this” to “This piece, we are not sure and it might need a little more work, but rest of the stuff you should be able to plan & estimate”. Slowly through these discussions (couple of hours) you highlight enough such instance, to point out the fact that, there are lots of uncertainties. Also you highlight the fact that we can make assumptions and move on, but it could lead to rather adventurous ending. At this point, I pull some of the biggest project failure case studies and show them how adventurous the ending might be.

3) Sometimes, I start off saying,

I’m sorry, I’m not good enough for this job. You need an expert, who have implemented the same project many times before and is extremely desperate for work to agree to your terms of project execution or you need someone who is an expert at acting to make you feel like they are in control.

I also add saying,

It does not appear to me that your are building a software project for the first time. So if you look back at your past experience, how has this approach of building software really worked for you? Be true to yourself. Were you happy with the results? Did you feel it could have been lot faster and costed a lot less? Also did you feel the team could have come up with lot of innovative, valuable ideas in the project?

Sometimes these questions shake them up a little. At this point, they want to hear more. Its very likely that you’ve touched upon some of their fears and pain points.

4) I also bring to their attention that, I’ve worked for a lot of companies who will go with the traditional model, but put a serious (expensive) change request process. They know that on an average sized project 20-40% requirements will change as the project continues. (There are graphs that show this very clearly.) Software companies typically use this approach as a way to teach their customers a lesson. And on subsequent projects or mid-way through the project, the customer agrees to collaborate more instead of tossing it over the wall. If the customer still does not agree, heck what, you make good money through the strict change request process.

5) At this point, hopefully they are slightly more open to listening to you. So I propose that we start-off with a week or 2 week inception phase to flush out some of the uncertainties and to bring everyone on the same page, so we all can agree upon the common goals. Depending on how important this project is, we price the project inception piece of work accordingly. Sometimes even free. During the inception phase, we do some brainstorming about what we need to build, how it’s going to affect/help endusers and businesses, we build some models, we build some working prototypes, etc. This helps the customers experience the value of collaboration. (It’s like the trailer of the movie.) In my experience so far, most customers see the value, we are able to build some trust and respect for each other and we are really set to build a project using agile methods.

6) After all this, if they still don’t see the point, I tell myself,

Life is too short to waste time on such projects. Time to find a new project/customer. In fact life is too short to build products for others. Its high-time I build my own products.

Interestingly, I’ve had some customers who understand all of this stuff and tell me that the main reason they don’t want to collaborate is, they fear they might get attached to the project. And will not be able to take objective calls. This is a valid point. When I cook something, it always tastes good. Even if it does not, I keep trying to make it taste better. Hard to draw the line. In case of software projects, we can work out strategies so customers are able to collaborate but still take objective calls when they need to.

* This question was asked by Stephen Walters on the Agile Alliance LinkedIn Group.

Wow I had not realized that people now name over 50 practices as Agile Practices. (I don’t think they are all at the same level. But its fascinating to see this list.)

• Retrospective
• Prioritized product backlog
• Embracing changing requirements
• “Just-in-time” requirements elaboration
• Planning Game
• Kanban
• Small teams (12 people or less)
• Team documentation focuses on decisions rather than planning
• Onsite customer (Daily customer/product manager involvement)
• Short iterations (30 days or less)
• “Potentially shippable” features at the end of each iteration
• Stabilization iterations
• Iteration reviews/demos
• Team velocity
• Time-boxing
• Requirements written as informal User Stories
• Synchronous communication (face-to-face, video conference, conference call, instant messaging)
• “Done” criteria
• “Whole” multidisciplinary team with one goal
• Energized Work
• Sustainable pace
• Sit-together or Co-located team
• Release planning
• Informative Workspace (Information Radiators, Big Visible Charts [Burndown Charts, Pair Stairs])
• Stand up/Scrum meeting
• Features in iteration are customer-visible/customer valued
• Task planning
• Automation
• Emergent design
• System Metaphor
• Simple Design (Do Simple Things, You Aren’t Gonna Need It, Once And Only Once, Simplify Vigorously)
• Unit-Test-driven development
• Acceptance Test-driven development
• Collective code ownership
• Continuous Integration
• Continuous Deployment
• Design inspections
• Ten minute build
• Refactoring
• Configuration management
• Single Click Deploy
• Pair programming
• Coding standard
• Code inspections
• “Complete” feature testing done during iteration
• Exploratory Testing

Quite often I find software companies trying to figure out the Essential set of practices that can be rolled out to all the teams in the company. They also try to set these practices as a baseline against which all teams will be measured. Now, this might appear to be a perfectly logical way to manage software teams, but in reality, this does not work. In most cases, I’ve seen this cause more harm than good.

IMHO, practices are very context specific, some practices are needed in some context and at certain point in time on the project. Teams need to be agile about choose practices based on their needs. Its very scary for me to see teams using the same set of practices throughout the project and throughout the company. Its a serious concern when team don’t consider

• the people on the team,
• their social interactions with others inside/outside the team,
• constraints under which they are operating,
• stage of the product development,
• business and market conditions
• etc.

It pushes the team towards mediocracy. Also looses the real potential of what the team and the product can achieve.

It boils down to “People and Interaction OVER Processes and Tools”.

In 2001, following were a great set of principles for a Software Development team.

• Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
• Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.
• Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
• Business people and developers must work together daily throughout the project.
• Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
• The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
• Working software is the primary measure of progress.
• Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
• Continuous attention to technical excellence and good design enhances agility.
• Simplicity–the art of maximizing the amount of work not done–is essential.
• The best architectures, requirements, and designs emerge from self-organizing teams.
• At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

Today I think some of them needs to be re-looked at for the following reasons:

• Nature of Business: Internet has changed the face of businesses across the world. E-Commerce is an integral part of every business model today. Most businesses are going global, driven by the global demand and open economies.
• Distributed Development: The world is more connected but at the same time more distributed than ever. Distributed Development is no longer a cost-saving scheme. Its become a necessity to take advantage of the global economy and un-even distribution of talent.
• To think about it, Software Delivery is no longer the biggest bottleneck
• Tools and Technologies have come a long way in the last decade. Esp. if you look at one aspect about Software development, .i.e. ability to quickly build and deploy software, its extremely simple and fast today. Tools like Google App Engine; Content Management System like Drupal, Django, CMS Made Simple; Light Web Frameworks like Rails, Grails, Cake, Seaside, Lift + Services like Heroku, Amazon EC2, Engine Yard Cloud. These clubbed with Social Networking Platforms, makes it trivial to get, if not thousands, at least hunders of impressions everyday.
• In the Web 2.0 and Mobile space, companies are investing a lot of effort to building platforms over building apps. Building platforms and exposing APIs for others to build Applications is a quite a different ballgame.
• There has been an explosion of the programming language and frameworks in the last decade.
• And so on

Personally I would like to change/update the following principles:

Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.

To think about it, Software is just a means, not an end in itself. Enabling and empowering the users and businesses is more important. Quite often we find development teams building a lot of wonderful software, which might even seem useful, but rarely does it truly enable the users. So I would rather have a principle which states very clearly that enabling and empowering the users & business is more important than building software. In fact, lot of times, I believe the best way to enable users and businesses is to provide them with little or no software.

Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.

The whole notion of requirements seems so 20th century-ish. Requirements have a “mandatory” connotation. Agile is about collaboration and co-evolution of users needs. Also this principle feels more geared towards services or in-house IT shops. For product companies this is given. IMHO the spirit of this principle is that we should acknowledge and work towards letting the software evolve. Better the collaboration and feedback, better will the software evolve to being more meaningful.

Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.

With the technology we have today, companies are deploying software multiple times a day. People are talking about Continuous Deployment, Perpetual Betas and so on. Yet, there are companies in the embedded software space (consider chips being embedded in your brain or software controlling your car) where deploying has a very different meaning and risk.  I like the spirit of this principle, but I see way too many companies delivering working software which does not result in any feedback. Which does not result in any inspect and adapt. I feel they are missing the point and the principle needs to explicitly state that its the feedback and inspect-n-adapt that is important, not the dumb delivering part.

Business people and developers must work together daily throughout the project.

As I understand the objetive of this principle is that business people and the developers collaborate, they understand each other’s point of view, they have more visibility into the decision making process, to help build the trust and respect, and so on. Personally I feel drawing a line and saying these are the business people and those are the developers rather creates the anti-collaboration pattern (at least sometimes). It also leads to “not-my-problem” attitude. I feel eating your own dog food, in some cases, is a very powerful technique. I guess these days I’m more and more leaning towards not differentiating between business and development. Those are 2 perpectives, that everyone on the team needs to have. Some will have more of  one and less of the other.

Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.

I completely agree with this. However, IMHO a lot of companies just pay lip-service to this. Even if they manage to hire motivated individuals, within no time they converte them into Zombies. Companies fail to understand what motivates individuals. Motivation is not a “thing” that can be achieved by claiming we are going Agile or declaring the team is self-organized. Different things motivate different individuals at different points in time. IMHO, one of the most important things for individuals is to have a sense of growth & learning. Having a sense of ownership and control. This really is about organizational cultural change. Quite a few start-up companies have the hunger and passion for success, to achieve something. You’ll find real motivation in these places.

The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.

While I believe in face-to-face communication, I would not say its the most efficient and effective method to convey information in all contexts. There have been many cases when I could have chosen f-2-f discussions, but I choose to collaborate over the wiki. Sometimes discussions can be too fast for me to catch up or too slow to be patient. Sometimes one needs the space to think and research. Sometimes language can be a barrier to communicate. Open source projects don’t do f-2-f communication, they still seem to collaborate on extremely complex projects. There are times when f-2-f is extremely important and times when its not. There is simply no “the best”.

Working software is the primary measure of progress.

I would say enabling and empowering customers is the primary measure of progress. Sometimes we can make progress without creating any software. And sometimes getting rid of software helps us going faster. For ex: Lot of teams get zapped with Agile Project Management tools. You replace it with index cards on a wall and they progress much faster.

Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.

To maintain a constant pace indefinitely is not sustainable. Let it be running, exercise or software development. Software development is a creative, problem solving, highly collaborative activity. Its not clear to me how to maintain a constant pace. As humans, esp. Software artists, we are not productive linearly. There are times when we are ultra productive and there are times when we have no idea what we are doing. I’m not questioning the need for Sustainable Pace. The interpretation of sustainable pace is very questionable. People dumb it down to a very mundane, clocking x hrs per week makes something sustainable. I think there is lot more to sustainable pace. I’ve worked on lots of projects were we have clocked more than x hrs every day and were able to sustain it for at least a few months. Looking back, I’m very happy I did. I would argue that if you enjoy doing something and truly believe in it, sustainable pace automatically falls in place.

Continuous attention to technical excellence and good design enhances agility.

As much I would love to agree with this, when I look around that the software that I happily use, they force me to disagree. Certainly technical excellence and good design is important, but there is a trade-off and its important to learn where to draw the line. Alas this is not easy. However these days building software is very cheap and one can afford to throw away working software more rapidly. In some context its cheaper to throw away software and rewrite it than to slowly, carefully, refactor it.

On a slightly different, but related note, a lot of people say Technical Debt is evil and one should stive to have Zero debt. This dogmatic statement clearly shows lack of business accumen. Short-term, low interest debts can be very effectively used to one’s advantage.

Simplicity–the art of maximizing the amount of work not done–is essential.

This is indisputable. Simplicity, simplicity, simplicity. I’m all for simplicity. If we can solve a problem without writing any software, that’s true simplicity. These days I have a habit of asking, “Do we really need any software? Can’t we do without? If we really need software, can we reuse something that’s already out there?”.

The best architectures, requirements, and designs emerge from self-organizing teams.

Software development is a co-evolutionary process, so there is no doubt that good architecture and design will evolve and exhibit an emergent behavior. Certainly a team who owns the software, cares about it and is passionate about it, will really help in the evolution.

At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

I love the spirit of this. Inspect and adapt is important. But be aware of retrospective coherence & premature convergence. Also its important to understand my regular is not your regular. For teams which are doing iterations and sprints, may be end of the time-box is a regular interval. For some its too late. And for some who don’t do time-boxes, what is regular? What we certainly don’t want is more episodic ceremony. When something important happens, why wait? Why not tackle things as and when they occur. Even if we don’t resolve the issue, it’s worth at least a quick discussion. May be we practice “5 Whys”.

Conclusion: These principles were a great starting point. Today, one needs to evaluate them in their current context and see how this maps to them based  on the points I’ve highlighted.

At the Agile India 2010 conference, there was a lot of interest for agile coaching in India.

Today, in India, I believe we have many Agile coaches (internal and external, more internal coaches). If you are helping bring Agile/Lean/Light-Weight thinking into your company, you are playing the Agile coach role (you like it or not). You could be in the leadership role doing this or you could have taken the ownership and facilitating/influencing your team. While doing so, we all need a lot of help, advice and reassurance of our strategies. To facilitate this, help people network and to push the boundaries of Agile, in 2008, Deb and I created the first Agile Coach Camp in US.

In the past I’ve considered doing something similar in India, but always felt we’ve not reached the point yet. Now (esp. after the agile india 2010 conference), I feel we might be at this point.

So if you are interested in participating in a 2 day invitation only, all open-space based conference, over a weekend in March/April, inform me by filling out the following form:

Also please vote for which city you would like to have the conference in:

And what dates work best for you?

A lot of people think, if they can write some code, they qualify as a software developer.

IMHO don’t call yourself a developer if you don’t take ownership and responsibility for solving the overall, real business/user problem.

A good developer

• understands the overall problem and its context.
• has good problem solving skills (we are in the business of creative problem solving)
• has empathy for the users and is a user and business advocate.
• takes ownership by being a part-of the team and having a sense of belonging.
• makes investment into continuous learning & improvement

[Agile and Software Craftsmanship movements has made great strives in this direction. However some Agile folks don’t get it. We can’t draw a line and say this side is business and that side is development. Its ONE team working towards a common goal. Unfortunately, I’ve seen a lot of teams who end up creating artificial boundaries between people wanting the software and people building it.]

Anyway, having the ability to just writing some code does not qualify you to be a developer.

Almost a year ago, I wrote something more insightful: Programming in the 21st Century

Beyond dogma, beyond ceremony, beyond logical & rational bull-shit, detaching self from cutting edge agile practices to embrace, scale & sustain essential agility.

From Fail Safe experimentation to lots of Safe Fail experimentation.

From Objectivity to Subjectivity to Relativity to Uncertainty.

From Structure to Chaos.

From Illusions to Idealism to Realism.

Beginner’s Mind, here I come….

Developing nations, which are trying to establish themselves as a IT Destination have to fight against the giants in the out-sourcing world. For many years companies used CMM as a way to get some attention. But CMM is

• heavy weight,
• expensive to get assessed
• does not really fit small companies’ (20-50 people’s) needs.
• Also in the last few years CMM has got a pretty bad reputation and hence its not necessarily a great marketing advantage.

Considering all this, what do companies do? What is the new shinny thing they should all run after. ..ta..da… Agile & Lean.

• More suitable for their needs,
• Some Customers are asking for it
• Is also trendy and gives the marketing advantage over the big outsourcing companies.