Tuesday, May 12, 2009

Useful tools for a distributed delivery project

Continuing from my previous post where I discussed the approach we used during my first experience working on a distributed delivery project, I shall now discuss some of the tools that helped us with the same.

Tools used

Firebug plug-in for Firefox - This tool helped me immensely, especially when I was analyzing the re-design of the user interface (UI) design for the application. Since the analysis involved having new logos, contrasting color backgrounds, navigation & menu bars, tabs etc., I needed a tool which could help me do minor modifications to the application and demonstrate it to the client before we could finalize a design. Though I had created many prototypes for the same, we still needed to try various options with colors, spacing between tabs and placement of links/buttons amongst others. Considering the distributed nature of the project, I basically needed a tool which was simple enough for me to use and also do some minor modifications to the code and not having to rely always on the developers who were in Melbourne (it would have also delayed the analysis). I organized a workshop and invited all major stakeholders to discuss the new UI design for the application. Using the prototypes that I had created, we finalized the design layout and then using firebug, we could finalize more accurate details like the actual color codes to be used and the number of pixels between tabs (for spacing) etc.. This was of great help to the developers as it removed any ambiguity (which is of major concern when you are developing user interfaces). Thus the development and the actual sign-off process went ahead very smoothly. The client was very pleased with the final outcome.

Mingle – Used to capture all project related information within one single location which could then be accessed & updated by anyone involved with the project (including the clients). It was our virtual story wall which helped us to track the progress of the stories in real time. It was also used to record the environment details, team contact details, progress reporting, meeting minutes etc.
Another unique use of Mingle was using it for doing our iteration and project retrospectives. We set-up a project within Mingle just for Retrospectives and the team (both from Melbourne and Perth) used it to record their feedback within the various categories set-up within Mingle. We then discussed individual feedbacks over the phone (using a teleconference facility).

Video Conferencing – We used this facility mainly during showcases (at the end of each iteration) and important analysis sessions when we needed the involvement of the Melbourne staff (both client and TW). This is a very handy communication tool to use for distributed projects.

My first distributed delivery gig!

I just rolled off from my first distributed delivery gig with Thought works. I had a great time working with the team and it was also a great learning experience for me.
The client had its head quarters in Perth (they also had another office in Melbourne as well) and thus I was sent there to help out with some analysis work. The delivery team consisted of a total of 7 members of which a team of 5 (4 developers and one tester) were based in our TW’s Melbourne office and 2 of us (I and another Thought Worker who played the role of an Iteration Manager) based in Perth.

In this blog, I shall mainly discuss the approach that we followed to successfully deliver the first phase of the project.

Our approach

Daily stand-up meetings – We had 2 stand-ups every day. The first one (held every morning) was an internal stand-up meeting and then one in the afternoon involving the whole team (through a teleconference facility between Perth & Melbourne)

Analysis sessions – Almost every day, I used to organize at least 2 analysis sessions. The morning session was used mainly for story analysis and I had a story sign-off session in the afternoon.

Workshops - I used to conduct a workshop's only when I had to get a broad consensus from the clients. I faced such a situation when finalizing the new design for the application. For this, I could not just rely on the Subject Matter Expert assigned for that Iteration as it affected all the users. Thus, I had to get all the main stakeholders into the same room and conduct a workshop using 'hi-fi' design prototypes and demonstrations of the application(using firebug plug-in to modify the code on the go). This helped me to gain consensus amongst all users and also finalize the design.

Story kick-offs & hand-over – Before the developers picked up any story for development, we used to have a kick-off meeting where the developers would call me up to discuss the same. Apart from the implicit benefit of gaining more knowledge of the requirement, it also used to provide me with a chance to check if the developers had picked the right story according to the priority.

Triage – We used to have a weekly story prioritization session (which we called as Triage). Being an Agile project, this is a key mechanism to deliver value to the customer. Re-prioritization on a regular basis helps provide the best value for money to the clients.

Iteration kick-offs – We had a 2 week iteration and at the beginning of each iteration, we used to have a kick-off session in which we discussed the stories which were currently being developed and then the analysts would discuss details for those stories which were prioritized highest within the backlog and thus ready to be picked up for that particular iteration.

Showcases & Walk throughs – At the end of each iteration, we used to conduct a showcase where we demonstrated the latest version of the application being developed (usually the Subject Matter Expert from the client demonstrated most of the functionality which were developed within that iteration – this gave them a feeling of ownership). Each iteration, we also conducted walkthroughs which was a more hands on approach for the users to test the latest additions to the application. This involved the users actually logging into the application and trying out individual functionalities. I think that this approach is a fantastic ‘Change Management’ initiative and helps get an acceptance from the actual users even before the application has been deployed.

In my next blog, I shall discuss some of the tools that helped me dealing with the distributed nature of the project.

Friday, April 10, 2009

ThoughtWorks QTB session at Perth

Since I am currently working in Perth on a client project, I got an opportunity to attend the latest ThoughtWorks Quarterly Technology Briefing (QTB) held on Tuesday at the Hilton, Perth. The joint presentation was done by my colleague Jason Yip and Paul Heaton and was titled 'Lean Times Require Lean Thinking'. I personally felt that the presentation was pretty appropriate for the current time with the bleak economic situation and everyone looking for lean solutions.


The presentation was mainly based around the famous Toyota Production System (TPS) and how the Lean concepts (which is the mainstay of the TPS philosophy) can also be implemented within other industries and not just within manufacturing. Jason Yip discussed how the lean concepts derived from the Toyota Production System was more relevant to our current economic situation since TPS was derived in Japan when it was in the midst of a deep financial and economic crisis and when Toyota especially was in deep financial trouble with very little cash at their disposal. Thus, it was resilient enough to be implemented not just during good conditions, but also during tough economic conditions.


After a brief introduction about how TPS evolved, the presentation then moved on to discuss some popular Lean concepts such as ‘Just-in-time’, different types of waste, how to reduce waste, importance of reducing waster etc. The main objective being how Lean thinking is particularly relevant during the current economic condition, with most companies facing a cash crunch problem due to the global financial crisis.


Some of the lean concepts discussed within the presentation were as follows:

- Just in time production

- Different types of waste and how to minimize them

- Importance of engaging everyone to solve problems (Jason gave few classic examples of how senior managers at Toyota manufacturing plants do not hesitate to get their hands dirty to fix any production line issues, thus not affecting the productivity)

- Set based concurrent engineering and how it is more efficient than point based approach

- Focus on collective responsibility over authoritative responsibility – collective responsibility brings a sense of ownership amongst all workers and thus helps to eliminate any blame games (culture of passing the buck around) when an issue has been identified.

- Build what the customer actually needs and not building what you think the customer needs


It was indeed a very informative presentation and I was also quite impressed by the attendance (there were about 40+ people attending the morning session). The reviews we got were generally very positive.

Monday, March 30, 2009

Project Retrospective using Mingle

Last week, we conducted an iteration retrospective for the project that I am currently working, for a client based in Perth. Since we are a distributed team with the analysis team in Perth and the development team being based out of Melbourne, we used Mingle to do our Iteration Retrospective. I have conducted a few face-to-face retrospectives myself and it works fine. But this was my first experience being part of a distributed project team retrospective and we used Mingle to help us with the same.

Why did we use Mingle? Mingle as a tool is best suited for collaborative discussions within a distributed team. It can be easily set-up for anonymous feedback, which can then be discussed either through teleconferencing or video conferencing. The whole process took us about an hour and was a pretty successful exercise (except for some minor glitches we had with the voice, since we used Skype for the teleconference call).

The rules we followed during the retrospective session were the standard rules being:
- It’s not a blame game – provide constructive feedback to help the team move ahead
- One conversation at a time

We started the retrospective by hooking up to the Melbourne office on a teleconference line (Skype). Each of us also had logged into the Project Retrospective instance within Mingle. We then decided to use the next 10 minutes to enter our feedback within the Retro wall. The Retro wall had the below 6 categories and each of us could enter our feedback into any of the categories (without any particular order):
- Do less of
- Do more of
- Keep doing
- Start doing
- Stop doing
- Puzzles

The Retro wall was setup to accept feedback anonymously and thus no names were published against any of the feedback(s). After confirming that everyone had finished entering their feedback, we began discussing the feedback for each of the categories. Some of the feedback was quite self explanatory, while the rest required further discussion (Usually the person who wrote a particular feedback would expand on it and the rest of the team would add to the discussion as required). At the end of the discussion session, we voted on the items that each of us felt needed more discussion or needed an action item against the same (again, voting can be done anonymously using Mingle). At the end of the retrospective session, we had collected a few action items, with names assigned against each of them. I thought it was a pretty successful retrospective!

Monday, March 16, 2009

The Rhythm of Fit

I am currently working on a presentation on how Innovation is the key to building solutions that fit the purpose and thus offer a better rate of success. The inspiration for the same came from a section within the book 'The Elegant Solution'(by Matthew E May) which talks about how an innovation/solution should focus on clear and present needs and most importantly, how it should fit the purpose rhythmically.

According to the author, a great innovation should:
- fit the times
- fits within a larger system
- shapes the attitudes and behavior of people
- changes how people think and work
- allows others to see in it their own opportunity for a new life

A perfect innovation which identifies with the above criteria's and also has revolutionized the art of selling music, videos and other applications online is Apple's iTunes and iPod digital music players.



While we have had quite a good choice of digital music players, the one thing which was lacking in most of these digital music gizmo's was the experience. It is very important to provide for a seemeless experience that is easy to use and simple. That's where Apple's super slim music player 'ipod' and their new platform to legally distribute music online 'iTunes' has been a huge success.

While the iPod was a simple and great looking digital music player, people could purchase their favorite tracks online at the iTunes music store, mix their favorite tracks into playlists with iTunes and upload their entire music collection by synchronizing their super slim iPods to the iTunes application. Apple had delivered a complete solution for the new digital music age!

To add to it, with their recent launch of the iPod Touch and iPhones, there is a whole new market being created for creating and developing iPhone Apps (applications). Apple has provided an opportunity for all innovators (of all ages) to design, create and sell their applications on the iTunes App store. It thus not only nurtures innovative ideas, but also provides a reliable platform to sell their ideas to the world - A perfect example of how great innovations allow others to see in it their own opportunity for a new life!

The integration between the iPod and the iTunes music delivery platform is truly rhythmic.

Monday, March 9, 2009

Fighting Intuition!

Being an intuitive person, I have always wondered about the merits of making decisions based only on my intuition. There have indeed been times, when, having to make a decision quickly, I have relied purely on my intuition. It works many a times, but also fails me sometimes. I am sure we have all had similar experiences.

Recently I was reading a book based on the Toyota Production System ('The Elegant Solution' by Matthew E.May) and I was quite surprised to find a section there, discussing how making decisions based purely on one's intuition can be dangerous. It discusses how solutions that are regulated by mere 'gut instinct' usually never produces the perfect answer to the given problem. This problem arises mainly due to absence of solid facts and thus conventional wisdom rules the day. This means that the problem does not get the scrutiny, objectivity and critical analysis it deserves.

The book then discusses ways to counterbalance intuition and battle convention. One way can be found by using the principle of safety in numbers using patterns, as they offer a logical explanation for what we observe. This can be achieved by running the numbers (the right set of numbers for your business) to discover patterns hidden within the data. This helps to minimise risk and make balanced decisions.

It also lists four key measures that help in fighting intuition - as advocated by Toyota Production System (TPS) engineer Taiichi Ohno:

1. Always temper immediate action
2. Resist drawing conclusions on emotion
3. Question hearsay
4. Draw from experience, but don't rely on it solely.

Thursday, March 5, 2009

Value Stream Maps and Process Improvement!

I was recently involved in an exercise to map and improve the invoicing process of a company. We conducted a workshop to define and map the existing process for invoicing - using a Value Stream Map. We then used a timeline graph to measure the Value added and Non-Value added time during the process (refer below)



It was interesting to note that the actual value add time was only 2hrs 20mins compared to a total process time of 7days 3hrs 25mins (includes a weekend)!
The above exercise helped us to identify areas for improvement within the invoicing process. We were then given a target of refining the process to be completed in less than 5 working days.

Our next step was to identify the main problem areas & also the common reasons for its occurrence. Once we identified all the problem areas and the reasons behind the same, we had a brain storming session to chalk out strategies to resolve the main bottlenecks which were delaying the process. We then created a roadmap (of activities) to initiate the problem fixing process. Due to confidentiality reasons, I cannot detail the actual issues that were identified or the fixes that we put into place to resolve them. But what I can share is that we have been able to successfully achieve our goal of reducing the total process time to less than 5 working days! **Hurray**

But, I guess that's just the start as we are still in the trial stages and need to track the process to identify if the measures that we took to resolve the issues - were they short term only or can they sustain in the long run? Also, more importantly, our next steps are to identify areas for Continuous Improvement(CI). Will we succeed .... ? Only time will tell!

Wednesday, March 4, 2009

Learning to Effort Ratio!

Within my previous blog titled ‘Tradeoff Curves’, I discussed the concept of tradeoff curves and how Toyota’s passion for extensive prototyping provides for redundancy which helps to plan a risk adverse system balanced with the infusion of new ideas. Let me discuss the concept a bit further by looking at the Learning to Effort ratio which quantifies the advantages of prototyping and having redundancies in your plan. Prototyping allows system designers to push the limits of testing proven subsystems (as far as required) to ensure that it works perfectly and also can meet changing system targets. The knowledge gained is not lost, but is banked for future projects.

Now trying to put things in perspective, lets consider a simple real life example of designing a house. Consider designing 4 houses. If you design using multiple choice alternatives for each component of the house, you'll end up with many more combination of designs than if you design using only a few concepts for each component. Thus using four interchangeable sets of each component, you could have 1024 unique house designs (theoretically at least!).



It also results in significant build up of knowledge which can be used for future design purposes. This is in comparison to just 4 unique houses you can design using only a few unique concepts. Another major advantage is that it also significantly improves the innovation to risk ratio i.e using the concept of interchangeable components, significantly improves the project success ratio.

Monday, March 2, 2009

Less is More!



This weekend, I had been to the Hunter Valley for a relaxing day of wine tasting and great food with my friends. Not just being satisfied with tasting different variety of wines, we decided to attend a behind-the-scenes wine tour at one of the vineyards for a chance to understand the wine-making process. It was a very informative tour as we got to see and learn various details that go into making that perfect glass of wine. Our tour guide was a very experienced wine producer and he told us a lot of interesting facts and stories. But, what interested me the most was his punch line that he used through-out the tour “Less is more”. I had heard that phrase being used in many other situations, but what surprised me was how it was related to the process of producing wine [Though the origin of this 19th century proverbial phrase is unknown, its often associated with the architect Ludwig Mies van der Rohe, who adopted the motto "Less is more" to describe his aesthetic tactic of arranging the numerous necessary components of a building to create an impression of extreme simplicity, by enlisting every element and detail to serve multiple visual and functional purposes].

According to him, the amount of vines planted within a hectare of land was inversely proportional to the quality of the wine that could be produced. Apparently, each particular piece of land can produce only a certain amount of good wine, irrespective of the total area planted. E.g: An hectare of land has only enough nutrition to either produce 10 kgs of quality grapes to produce a liter of high quality wine or can produce 20 kgs of low quality grapes which can still produce only 1 liter of high quality wine - Less is more!

He also used the phrase to explain how it is most efficient to grow only a few bunch of grapes per vine. This allows for channeling all the nutrients to a few bunch of grapes and thus get high quality and flavor rich grapes. Thus they regularly trim the vines to allow only a few flowers (which gets fertilized into a fruit)to grow per vine - Less is more!

I have used the phrase "Less is more" during discussions about improving process efficiency, lean production/manufacturing, product design and development etc., but it was a refreshing change to hear the same being used to grow grapes!

Saturday, February 28, 2009

Tradeoff curves

Inspired by the ‘Toyota way’, I have decided to dedicate my first few blog(s) to discuss my views on a few concepts that I have found the most informative.
It is no secret that Toyota relies on extensive prototyping during its product development stage. Initially I found it hard to understand toyota’s way as I always wondered.. How can Toyota spend a considerable time and effort on prototyping, but still manage to successfully develop and release new models of cars in record breaking speeds?. That’s when I was introduced to Toyota’s emphasis on tradeoff curves.

So what are these tradeoff curves and why are they referred to as the cornerstone of knowledge?

The best definition that I have found for the above is that they provide the subsystem knowledge to create the system design and more importantly provide the ongoing knowledge for future projects. The data for the tradeoff curve is obtained by comparatively mapping various subsystem design data to both system performance and other important subsystem characteristics. To achieve greater efficiency, Toyota relies on capturing real test data and thus is their reliance on developing so many prototypes. The main advantage is that, this database of real test data provides ongoing knowledge for future projects and also provides for any redundancy. Thus their emphasis on research and development using prototyping provides for optimum utilization of time and resources.



Some of the advantages are as follows:

- Allows a risk adverse system balanced with the continual infusion of new ideas
- Provides for changing system design requirements
- All knowledge gained is not lost, but is banked for future projects
- Allows for more innovation with less risk – thus provides for a higher project success rate
- Providing for redundancy plays an important role to have a risk adverse system balanced with the continual infusion of new ideas

I shall discuss the concept of ‘Learning to effort ratio’ in my next blog. That should provide a better perspective to the advantages of using the tradeoff curves.