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.
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.
The Value Theory: What people value drives their actions.
Value Driven planning is where you plan to do the most valuable things with your resources, and of those valuable things you try to do the most valuable things first if possible.
Target Driven planning is where you have a target or set of targets you try to reach, and you try to do what gets you to your targets.
Target Driven thinking reflects the way we tend to ask people for what we want. For example, “May I have 2 kilos of potatoes please”, “Get me twelve bricks.”, and “I need two tonnes of sand.” What we rarely do is say “This is how my values work or this is what I value, so please do something that will make me happy.”
Similarly when it comes to Agile adoption (or any process for that matter), we see two camps:
Target Driven Camp: Where people use number of practices, adherence to a specific prescriptive process and checklist based verification of the same, certification, maturity levels, and so on to guide and plan their adoption.
Value Driven Camp: Organizations highlight what they value, they use their values to guide them with their adoption process. (Please note that their values itself can evolve.) Ex: We value quick turn-around time, so our customers get what they ask for quickly, is this process change inline with our value?
What is success ratio? How many teams you know (not heard of in some cooked up report by a consulting company or a tool vendor) who are successful adopting Agile with a coach’s help? And how many teams do you know who have failed trying to adopt agile without using a coach? Let me clarify, when I say adopt Agile, its not about a bunch of practices. Its about continuously evolving the process to make it lean and more efficient and more enjoyable.
Can any coach do or do we need a special type of coach? Point I’m getting at is, your chances to succeed is based on the quality of the coach and her experience.
In my opinion your chances of failure is much more if you hire an average coach from outside who does not understand the business, organization and team context & culture.
The big problem we face today is we don’t have a good way to know if someone is a good coach or not. What are the chances you’ll end up hiring the right coach? Its not sufficient if someone is a certified professional. In some cases, its not even sufficient if someone has written a couple of books.
Also in my experience, ability to connect and influence the team members is very important. A good team member is in a much better position to achieve this than any average coach from outside.
How sustainable is the model of hiring a coach?
What happens when the coach leaves? Is the team evolving their process or still using what the coach put together?
Hiring a coach from outside might speed up things. But I’m not sure if people will be able to understand the rationale behind doing certain things. In my experience failure is a great learning tool. Taking more time to achieve something (and in the process failing a few times) is not bad, it make something more sustainable and scalable.
Can you teach/coach someone to be agile? Agile has been around at least for the last 10 years, what are the chances one or more coaches can change that? (I’m not saying its not possible, I’m trying to highlight that its not simple. It involves organizational transformation and change in individual’s mindset).
No amount of process can fill-in for lack of trust. IMHO one needs to focus on building trust and creating an environment with low viscosity, process will automatically fall in place.
Viscosity comes in two forms: viscosity of the design, and viscosity of the environment. When faced with a change, engineers usually find more than one way to make the change. Some of the ways preserve the design, others do not (i.e. they are hacks.) When the design preserving methods are harder to employ than the hacks, then the viscosity of the design is high. It is easy to do the wrong thing, but hard to do the right thing.
Viscosity of environment comes about when the development environment is slow and inefficient. For example, if compile times are very long, engineers will be tempted to make changes that don’t force large recompiles, even though those changes are not optiimal from a design point of view. If the source code control system requires hours to check in just a few files, then engineers will be tempted to make changes that require as few check-ins as possible, regardless of whether the design is preserved.
This is a great explanation of how Viscosity applies in development process. I think the same thought process can be applied to the way an organization operates.
Some organizations have really high viscosity and trying to do the right thing, which is inline with the organizational value system, becomes harder and harder (sometimes impossible). Doing the wrong thing and getting away with it, seems so much easier. Its not just easy its also always quick. It turns out that there are no real motivations for employees to do the right thing. And then the broken window syndrome sets in.
Such organizations soon become endangered species.
On the Agile Alliance LinkedIn group, Eugene Yamnitsky posted the following question:
One of the key Agile transformation success factors is Executive Commitment. Every book and article I’ve read mention this, but there are no good explanation on what it really means.
Great questions!
In my experience, Executive Commitment is very deep and crucial. It’s certainly not as easy as flipping a switch and expecting magic to happen.
What does this really means?
First and foremost they need to understand that, for any change program or transformation, its the people and the environment they operate in which makes the difference. Not the new process itself. What Agile tries to do is change people’s behavior and the environment they work in.
They need to take time to actually understand what is Agile and what it is not. Essentially so that they have the right expectations set. So that they understand the impact of what they are getting into. This should involve talking to practitioners about their experience. Reading at least few experience reports and so on.
Involving their teams to understand their issues and aspirations. The worst thing the executives can do is decide “Agile is THE way to go” in a closed room meeting and force it down people’s throat.
Once there is a general awareness about Agile in the organization, ask any one team to volunteer to be the pilot project. Work closely with that team to set realistic plans.
Once the pilot project is kicked off and folks on that team & supporting teams are sold on the concept, they need to step back & stand behind their teams (support them) and trust them to do their best.
Send a clear message across the organization that this is important and we really care about this stuff. (There is a big difference between pushing in down people’s throat and doing it collaboratively with their buy-in)
The Executives need to be open to failures and also need to communicate that clearly to teams saying its OK to fail. We are trying something new, which is a huge paradigm shift and there is certainly risk involved in it. So its OK to fail.
Also sometimes I find that since the expectation setting is not right, teams are always trying to change their way of working in a hurry, under a high pressure. Its very unlikely that I would do my best under such situations. Give your teams the space and time they need. Like anything new, there will always be a learning curve.
It usually very helpful to have someone in the organization play an evangelist role. Someone with real first hand experience with Agile. The executives need to invest in the right things.
The other very important thing that the executives can influence is the organization culture. Encouraging honest and open communication. Not by just doing lip service, but by actually leading by example.
Like with any change program, everyone (esp. the executives) are always interested to know as soon as possible if the new process is working on not. Is it helping on not? Sometimes people try to put in tracking/measuring mechanisms which are inherently broken. As we all know, you’ll get what you measure. So the metrics you use will influence to a large extend how people will behave. This one single things can screw up the whole adoption process.
I can go on, but I guess this gives you the gist and seriousness of the kind of commitment required.
To conclude, I think it all revolves around
communication,
expectation setting,
collaboration,
leading by example,
showing that they care and providing the required support (time, money, effort)
being open to take the risk of potential failures.
