At the Agile Bengaluru 2010 conference, Jann Thomas discusses and identifies ways in which agile enablers can facilitate the transition to Agile practices. She covered basic Agile practices as well as techniques for introducing them to the software delivery team. She also presents common software delivery problems and the Agile path to solutions.

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.

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.

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

Every week, I continue to receive several email from training departments from companies asking:

We are planning to roll-out Agile to our whole organization next week. Can you please provide me with the following information by end of today:

• Detailed course outline to train the whole organization on Agile.
• Detailed course outline to train our internal trainers on advanced Agile topics.
• Availability of a coach who can work with our internal coaches to roll out Agile to our organization.

Also please let me know how much this is going to cost exactly.

This is worst than a fixed-bid project (fixed-cost, fixed scope & fixed time). At least there you have some context based on the thick-spec they give out.

I usually respond saying:

I apologize in advance, my response might sound a little harsh.

I’m sure you can find few people in India who can provide you with the services that you are looking for. But let me give you some context so you understand the nature of the risk you are taking.

Every week, I get at least one such email from a company who wants to adopt Agile method. They want a pre-packaged courseware (in-person or elearning) that can be rolled out to all their employees. And they hope they can get a good coach in India who can guide their organization.

Personally I always advice companies not to go down this road. Very few companies pay attention to my advice. Others go ahead with this approach. They shop around for the best deal they can get. They hire an “Agile” training company. Invest Lakhs of Rs in training. Spent a lot of energy and effort in trying to make this work. Take a productivity hit on projects and so on. And after 6 – 12 months they came back saying: “This Agile thing does not work. We invested so much, but there is no improvement. In fact our organization is worse off“.

Let me explain why this is the most inefficient way to invest money, time and effort. First and foremost, one needs to understand that Agile is not a thing that one can learn in a 2-5 day class. Agile is a very broad & deep topic. Its not about doing a set of practices, nor is it just a process change, its a cultural, organizational change. It changes (or at least challenges) fundamentally how people build software.

Without studying an organization, their pain points, nature of their work, aspirations of the team members, other constraints under which they operate, etc. .i.e. without the knowledge of the organizational context, any training done on subjects like this, IMHO will do more harm than good. Any general, prescriptive advice on this subject is fundamentally wrong. Any overview session is too vague for people to relate to. Guidance on such matters has to be grounded in contextual land.

I touch on some of these points in the following presentation:

Before going ahead with this window shopping approach, my suggestion would be, get a practitioner to spend a couple of days in your organization, do a small assessment of the situation on ground, collaboratively put a small roadmap together about how you want to handle this change, based on that figure out what training (if any) is required, understand how would you position this to the management and the development teams and so on.

BTW, if your organization has excess money in their bank account and have a few years to waste, I can send you a few course outlines, some profiles of trainings & coaches and their per day rates. I have a dozen of those.

1. Agile (as practiced today) is the new Waterfall
2. Naked Agile
3. Biggest Stinkers
4. Goodbye Simplicity; I’m Object Obsessed
5. Want to Pair Program and Concerned about Productivity?
6. Estimation Considered Harmful
7. Refactoring Legacy Projects: Scaffolding Technique
8. Single Responsibility Principle Demystified
9. Primitive Obsession
10. Cannot Evaluate a Candidate just based on their Resume

Over the last year, I’ve been helping (part-time) Freeset build their ecommerce website. David Hussman introduced me to folks from Freeset.

Following is a list of random topics (most of them are Agile/XP practices) about this project:

• Project Inception: We started off with a couple of meetings with folks from Freeset to understand their needs. David quickly created an initial vision document with User Personas and their use cases (about 2 page long on Google Docs). Naomi and John from Freeset, quickly created some screen mock-ups in Photoshop to show user interaction. I don’t think we spent more than a week on all of this. This helped us get started.
• Technology Choice: When we started we had to decide what platform are we going to use to build the site. We had to choose between customer site using Rails v/s using CMS. I think David was leaning towards RoR. I talked to folks at Directi (Sandeep, Jinesh, Latesh, etc) and we thought instead of building a custom website from scratch, we should use a CMS. After a bit of research, we settled on CMS Made Simple, for the following reasons
  • We needed different templates for different pages on the site.
  • PHP: Easiest to set up a PHP site with MySQL on any Shared Host Service Provider
• Planning: We started off with an hour long, bi-weekly planning meetings (conf calls on Skype) on every Saturday morning (India time). We had a massively distributed team. John was in New Zealand. David and Deborah (from BestBuy) were in US. Kerry was in UK for a short while. Naomi, Kelsea and other were in Kolkatta and I was based out of Mumbai. Because of the time zone difference and because we’re all working on this part time, the whole bi-weekly planning meeting felt awkward and heavy weight. So after about 3 such meetings we abandoned it. We created a spreadsheet on Google Docs, added all the items that had high priority and started signing up for tasks. Whenever anyone updated an item on the sheet, everyone would be notified about the change.
• User Stories: We started off with User Persona and Stories, but soon we just fell back to simple tasks on a shared spreadsheet. We had quite a few user related tasks, but just one liner in the spread sheet was more than sufficient. We used this spreadsheet as a sudo-backlog. (by no means we had the rigor to try and build a proper backlog).
• Short Releases: We (were) only working on production environment. Every change made by a developer was immediately live. Only recently we created a development environment (replica of production), on which we do all our development. (I asked John from Freeset, if this change helped him, he had mixed feelings. Recently he did a large website restructuring (added some new section and moved some pages around), and he found the development environment useful for that. But for other things, when he wants to make some small changes, he finds it an over kill to make changes to dev and then sync it up with production. There are also things like news, which makes sense to do on the production server. Now he has to do in both places). So I’m thinking may be, we move back to just production environment and then create a prod on demand if we are plan to make big changes.
• Testing: Original we had plans of at least recording or scripting some Selenium tests to make sure the site is behaving the way we expected it to. This kind of took a back seat and never really became an issue. Recently we had a slight set back when we moved a whole bunch of pages around and their link from other parts of the site were broken. Other than that, so far, its just been fine.
• Evolutionary Design: Always believed in and continue to believe in “Do the Simplest, Dumbest, thing that could Possibly work“. Since we started, the project had taken interesting turns, we used quite a lot of different JavaScript libraries, hacked a bit of PHP code here and there. All of this is evolving and is working fine.
• Usability: We still have lots of usability and optimization issues on our site. Since we don’t have an expert with us and we can’t afford one, we are doing the best we can with what we have on hand. We are hoping we’ll find a volunteer some day soon to help us on this front.
• Versioning: We explored various options for versioning, but as of today we don’t have any repository under which we version our site (content and code). This is a drawback of using an online CMS. Having said that so far (been over a year), we did not really find the need for versioning. As of now we have 4 people working on this site and it just seems to work fine. Reminds me of YAGNI. (May be in future when we have more collaborators, we might need this).
• Continuous Integration: With out Versioning and Testing, CI is out of question.
• Automated Deployment: Until recently we only had one server (production) so there was no need for deployment. Since now we have a dev and a prod environment, Devdas and I quickly hacked a simple shell scrip (with mysqldump & rsync) that does automated deployment. It can’t get simpler than this.
• Hosting: We talked about hosting the site on its own slice v/s using an existing shared host account. We could always move the site to another location when our existing, cheap hosting option will not suit our needs. So as of today, I’m hosting the site under one of my shared host account.
• Rich Media Content: We questioned serving & hosting rich media content like videos from our site or using YouTube to host them. We went with YouTube for the following reasons
  • We wanted to redirect any possible traffic to other sites which are more tuned to catering high bandwidth content
  • We wanted to use YouTube’s existing customer base to attract traffic to our site
  • Since we knew we’ll be moving to another hosting service, we did not want to keep all those videos on the server which then will have to be moved to the new server
• Customer Feedback: So far we have received great feedback from users of this site. We’ve also seen a huge growth in traffic to our site. Currently hovering around 1500 hits per day. Other than getting feedback from users. We also look at Google Analytics to see how users are responding to changes we’ve made and so on.
• We don’t really have/need a System Metaphor and we are not paying as much attention to refactoring. We have some light conventions but we don’t really have any coding standards. Nor do we have the luxury to pair program.
• Distributed/Virtual Team: Since all of us are distributed and traveling, we don’t really have the concept of site. Forget on-site customer or product owner.
• Since all of this is voluntary work, Sustainable pace takes a very different meaning. Sometimes what we do is not sustainable, but that’s the need of the hour. However all of us really like and want to work on this project. We have a sense of ownership. (collective ownership)
• We’ve never really sat down and done a retrospective. May be once in a while we ask a couple of questions regarding how something were going.

Overall, I’ve been extremely happy with the choices we’ve made. I’m not suggesting every project should be run this way. I’m trying to highlight an example of what being agile really means.

While everyone agrees with the value of eating your dog food, some people claim that this principle cannot be applied to all software industries.

Let’s take the Medical Health Care Industry. Who should build software for Doctors and Nurses to be used in the hospital? Its very unlikely that Doctors will start building software in the side. How do apply this principle here?

What we have today is a bunch of people trying to build software for the hospitals (most of them have not clue on how a hospital operates, those who know a little become Subject Matter Experts and take charge). Similarly there are lot of other industries.

You ask their users how they like the software and you would know. Its not that the development team did not do a good job of building the features right or the business did not do a good job of articulating what they want well. Its just that this model is setup for failure.

• The Agile community realized that, they need to bring the users in and collaborate with them much more.
  • The Scrum community identifies one person or a group, call them Product Owner. They are part of the planning meeting, daily scrum and even the retrospectives & demos. Some (0.1%) of teams are able to get actual users during their demo. Are they confused about the PO being their User?
  • The XP community demands an onsite customer who can guide the team not just during planning, but also during execution. Again the same confusion exists. But the situation is slightly better.
  • Having said that, I really appreciate XP for pushing the knob on automated testing. Automated Testing (esp. Developer testing) is a great way to eat your own dog food. Remember how useful your API tests have proved to be. Tests are clients to your code and they consume your code by acting as client.
• The Design (UX) Community are lot more User focused and tend to spend more time with the actual Users, but that’s very sporadic
• The Lean community have realized that they need to have the development team sit with the business in their work area. They have realized that there are a lot of important lessons to learn from the context of the work place.

Personally I think we need to go way beyond this. If you look at some organizations (esp. Web 2.0 companies and Open Source Projects) they are their own Users. We can certainly learn something from them.

How can we do this? Here are some ideas:

• At least to start with, have the team members take a formal education in the domain they are building the software. Do some case studies and then, spend quality time with the Users (actual Users). Not just interviewing them, but actually working with them (at least shadowing them or being their apprentice).
• Educate the Users more about Software development process and have them work with the team for at least a week or two to under it.
• May be hire people who have actually worked in the field. (You want to make sure their knowledge is up-to-date and they actually know the business really well). Also very important to maintain a good ratio. 1 member for a 10 people team is scary.
• Build tools that can help the actual end users build/configure their software. As developers we build tools which we use on our own projects. Same tools (which were driven by eating their own dog food) can now be used by others to build their software. For years, creating a web presence for a company was a specialist’s job. Today with Google Apps and others, anyone can set up a website, add a bunch of forms, set up email accounts and all that Jazz. The line between a specialist’ role and a business user is blurring. Coz we have the tools to help. Esp. tools built by people for their personal use.
• Again all of this can get you one step closer. But nothing like eating your own dog food.

I came across this wonderful e-book called Did I Provide Value: The 8 Disciplines Of The Value Added Leader by folks from Business Efficacy, Inc.

Leaders who relentlessly provide value to every individual in each interaction achieve success no matter how it’s defined. A direct correlation exists between Leaders who passionately work at providing value and employee respect & appreciation.

Following are my key take-away (para-phrased):

• Accountability – Take It On
  • Everyone has a behavioral comfort zone. Moving beyond this comfort
    zone takes motivation, courage, and persistence
  • Valued leaders are not constrained by a desire for popularity. Instead, they just take it on. They realize respect is earned by helping others to achieve more than they believe possible.
• Timing, Not Time
  • Timing is more important than time in making this happen
  • No matter what is being done, never waste a learning opportunity
  • “just-in-time” coaching action is almost always superior to a planned
  • Employees value coaches being present at precisely the moment of need; effective leaders deliver this regardless of other demands
  • Do not base your actions on time or time management. Instead, drive your priority management based on commitment
• It’s All About Them
  • Personal gratification for a Leader is achieved by ensuring others reach their full potential and are enormously successful.
  • Leader make sure they know what motivates each individual they coach. They then use this knowledge to make each required behavior make sense from the individual’s perspective, and show how it ties in to her personal motivations. When done effectively, employees quickly trust their leaders are dedicated to their success.
  • Leaders eschew the notion of “one size fits all” and tailor their communication style and learning methods/activities for each individual
  • A Leader’s first objective should always be to remove barriers to listening, comprehension, dialogue, behavioral change, and skill mastery as quickly as possible
• Stay With It Until They Get It
  • It is pretty basic ? the more people there are doing the right activities, the more effective the execution is on what matters.
  • In today’s world of multi-tasking and conflicting agendas, it’s difficult to develop mastery.  Adequate (but not great) performance is often accepted.
    Repetitive practice and action is the building block of mastering any concept or task.  Unfortunately, personal tolerance for this effort wanes under the burden of our “get it done now” mentality.
  • Create opportunities to keep working on essential skills, even when dealing with a conflicting emphasis
• Clear Expectations
  • Clear expectations make it easy for employees to self-evaluate and determine if work is being done well
  • Expectation clarity requires thoughtful determination of each essential behavioral requirement
• High-Impact Few
  • Activity for activity’s sake must not be allowed. The mission is to do a few common (core) things exceptionally well
• Ask More Than Tell
  • Learning is dependent upon critical, reflective thinking.  Increasing understanding is best accomplished by determining what, how, and why something is happening.
  • Self-discovery is a staple of the learning process. Make way for it.
  • When purposeful questioning is combined with timely, useful suggestions, true guidance/assistance is achieved
• Learn From Each Win
  • Catch people when they are doing something right and make a big deal out of it
  • Its important to know how each individual prefers to receive recognition
  • Demonstrate an enthusiasm for success
  • Unfortunately, many don’t focus on finding success. They seem to dwell on communicating only what either is not being done or what is being done incorrectly
  • It’s important to address performance issues.  However, instead of criticizing, utilize everyday wins to help develop confidence, composure, and concentration
  • Individuals without the confidence to pursue success is destined for mediocrity
  • Invite people to enjoy the process, have fun, and celebrate a task well done. Understand doing so, encourages the characteristics in people which will help to achieve results.