Agility Personified

Wise Fools, the sparks of successful teams and organizations

2010-10-16T15:33:00.000+05:30

Once there was an Emperor who always cared for his wardrobe, hires two weavers who promise him the finest suit of clothes from a fabric invisible to anyone who is unfit for his position or "just hopelessly stupid". When emperor finds himself unable to see the cloth, he pretends that he can, for fear of appearing unfit for his position or stupid; his ministers also do the same. When the swindlers report that the suit is finished, they dress him in mime and the Emperor then marches in procession before his subjects. But a child in the crowd yells out, "He isn't wearing anything at all!" The Emperor cringes, suspecting the assertion is true, but holds himself up proudly and continues the procession.

I have been going through the various patterns defined by James Coplien in his book “Organizational Patterns of Agile Software Development”. One of the patterns that really stuck me was the “Wise Fool”, not just because of its strange name, but also for the insight of this pattern.

Wise Fool is persona in the team, who asks the questions that may be unpopular or seen politically risky, but these questions make the team pause and reexamine the decisions.

In many teams and organizations, quite often employees hesitate to challenge the authority figures fearing that their career may get jeopardized if they do so. In few cultures challenging the decisions made by the elders or leaders is considered to be disrespectful. This often leads to bad ideas getting promoted by those authority figures because of their lack of insight on the flip side of the decisions. So there has to be some one who is a catalyst of occasional team introspection, sending warning signals, the moment the team seems to be heading towards a wrong direction.

The Wise Fools normally emerge out of the teams. A Wise Fool though known for lacking tact, is usually highly respected technically and may be a legend role.

Teams and organizations should nurture the role of the Wise Fool who can raise uncomfortable truths with impunity.

“6 Thinking Hats” technique for example gives a formal tone to the role of Wise Fool by means of the “Black Hat” which focuses on anticipated problems or the risks involved in any choice in consideration.

Characteristics of a WISE FOOL

Capable of recognizing the difference between asking legitimate questions and complaining incessantly.
Displays a mix of insight, candor and foolhardiness

Wise Fools are vital for any team’s or organization’s success. However unless organizations are willing to accept criticism within, Wise Fools only get labeled as Rebels OR Troublemakers, rather than accepting them as sparks of better future.

Legend Role: Certain individuals take on so many jobs and become so important to the project that when they leave, the project is in more that just serious trouble.

The Abbreviation menace

2010-07-17T16:16:00.006+05:30

The knowledge industry where most of us are working, is always on a hunt to find ways to increase productivity and quicken the time to market. Software engineers have to always keep learning latest stuffs to be competitive enough. It becomes important for the leaders to keep that in mind so that they keep watching for any little blocks come their way to move forward quickly.

Few years back, I was discussing a technical topic with my onshore counterpart who had just joined the project, using an instant messaging tool. During the discussion he was asking the meaning of almost every acronym I was using. By the time we concluded the discussion, I was of the opinion that he is new to even those terminologies I was using and he might take lot more time to contribute to the project. The routine continued for few days like this and one day he asked me “is using acronyms common in India?”

Since then I have been observing this pattern of badly using abbreviations in many places. People create their own and start using them internally assuming that what they know is commonly used across the industry. Some organizations create their own set of abbreviations for the frequently used terminologies. For the old employees using such abbreviations in their speech, articles, emails or any documents is very common.

Why am I thinking using acronyms as a menace?

Though I don’t have any data, below analysis I guess would be adequate to justify my claims.

Reduced productivity:
One has to spend more time in reading/understanding any documents or articles which are full of acronyms. Either they have to refer some place or check with peers to know the meaning. The time spent by the reader or the peer in exchanging the knowledge is never accounted. The effort required by the brain to automatically map the acronym with the meaning and remembering it may also could be comparatively more. However I am not sure how badly it might impact the productivity.
Lost Interest:
Most people have the tendency to stop reading, the moment there are too many new words or acronyms to understand. They loose interest when their normal pace of reading is affected. This according to me is a hindrance to progress.
Misplaced meaning:
People already have the behavioral pattern of seeing only what they want to see, not knowing the actual meaning of various words they randomly use, or attaching their own meanings to the unknown words. In such a situation, imagine the tendency to attach own meanings to abbreviations, creating more confusion. At times even at a given context the acronyms might sound like giving different meaning.
for example, perform RCA after every release. RCA = Root Cause Analysis or Release Compliance Audit (for the newly joined employee the later was common in his previous company)
Driving unwarranted behavior:
After a while in the organization, people develop a tendency to create their own acronyms, thinking that it will save their time. This creates a reinforcing loop, driving an unwarranted behavior. Worst, some people take false pride in knowing such acronyms, especially in front of new employees!
Illusion of saving time:
Though at the outset, it seems to give an impression that the effort spent by one person is reduced, the receiving end will be wasting the time in understanding the same. The impact is more if the number of new entrants to the organization/project is more.

In my experience, even though there are many commonly used abbreviations, I always felt more comfortable in reading stuffs without them. Many times I just stopped reading such articles if they are full of acronyms that I am not familiar with.

A session on TDD by Dr. Venkat

2010-05-02T17:00:00.004+05:30

A TDD session on multi threaded environment in Java was conducted by Dr. Venkat in our office premises on 21st April. Of-course, as mentioned in my previous blog, I had accompanied Dr. Venkat for the same purpose. This is an attempt to recall what I had observed and learned from this session.

There was no PPT and no wastage of time. Since already there was little delay in starting the session (It rained heavily in b'lore that day which probably did not let outside participants to come on time) he kicked off the session wasting no time.

4 conceptual points I could gather; needless to mention, each of them had different contexts while explaining.

Prove by contradiction (context - when there is a hindrance to try TDD)
Cognitive Dissonance (context - you see a value in TDD, but you never make an attempt to learn the skill)
Design by Contract (context - TDD a way to design your code)
Point of diminishing returns (context - coaching, when and how)

Some of the analogies I could pick were,

Every one knows that exercising is good for health, but very less do; Same with TDD
When you don’t know driving, you are uncomfortable and you take time to learn; Same is true while learning TDD.

Few picks from TDD in general:

Test first thinking
Small methods increase high cohesion and reduce coupling
How to test “thread safe” in Java; Usage of lock()
Unit testing should not contain code related to creating threads.
Unit tests should be as simple as possible; can’t be complex than the code itself.
Traversing from unit test to actual code and vice-versa.
TDD = Test Driven Design; You design your code
TDD is an art, learning takes time
TDD pays off by, reducing COQ (less defect, unknown failures, and reduced late surprises), increasing understandability, reduced maintenance cost.

It was good to see, he taking up an example and demonstrated the TDD approach using java.Overall it was a a very insightful session.

30 Minutes with the Agile Developer

2010-04-24T22:36:00.005+05:30

I always wondered how celebrity techies manage to do so many things. Be it reading, writing code, talking to people, writing books, writing articles/blogs, giving lectures worldwide, managing personal life and so on. I get scared, even to think of me doing all that!

It so happened one day that, I had to pick this “Agile Developer” from his hotel to my office where he was to present a talk on TDD, rather TDD in multithread environment. We were together for just 30 minutes in the cab and the onus was on me to best utilize the time.

After introducing each other we started off sharing our experiences in coaching teams. I think it was important for him to know my level of knowledge and decide at what level to speak with me, so that I understand what he speaks. For me, I just had to speak at my level best with my limited knowledge :-)

We touched upon range of topics related to getting team buy-in for engineering practices (like TDD & Pairing), educating people about the benefits of certain practices, human elements, team dynamics and so on.

Both of us shared few of our experiences and observations.

Dr. Venkat explained one of his experiences of coaching a team on agile, where the trust built between the onshore and offshore teams over a period of time had taken a beating because of a take over and new business strategies, where jobs were lost due to extended offshoring.

For TDD, he used the analogy of “Health Insurance”. You never know when u’r health is going to fail and same with the code. 2 weeks u have done the coding and tested, all seems working well. But the moment it reaches the tester, it fails.

He also talked about how he could educate a highly experienced programmer in changing the way he used to program, to the TDD way.

We exchanged few observations about how mind gets conditioned with wrong notions and we fail to see the benefits.

I shared the kind resistance I had faced while coaching an isolated team on Scrum

I also shared in brief about the coaching camp which I attended few days back in Goa conducted by ASCI.

His emphasis on few things helped me in strengthening my knowledge and beliefs.

We can not educate every one (developers to testers to managers to BDs) using similar approaches.

It is human tendency to resist change. More experienced have greater difficulty and larger is learning curve.

The moment there is insecurity people tend to resist changes. Give them time.

When there is resistance for agile one can not go with the theory. Instead show them where they are risking their work and give them different ways to come out of that situation. Be with them to resolve issues.

Pair with team members to make them understand TDD rather than preaching.

Honestly with the way information was flowing from Dr. Venkat, before I realized, we had reached office :-)

Thanks to Dr. Venkat.

Agile Coach Camp - GOA

2010-04-21T07:47:00.056+05:30

Dates: 17th and 18th April 2010
Venue: Silver Sands Resorts, Margao, Goa

http://www.agilecoachcamp.org/tiki-index.php

For the first time I attended a agile coach camp, so not really in a position to pass a judgment to say it was good or bad. However I was not satisfied with the content and quality of discussions except for a couple of topics/discussions. Some times I felt like I was giving more attention to the HOT GOA than the topics discussed in the coach camp. I think the amount of coaching experience most of us have is very limited. But in any case, I am happy that such a program was organized in India (for the 1st time I think) and thanks to the organizers.

The only discussion I facilitated was about "Coaching In Isolation"
I had once coached a team on agile which otherwise used to follow Traditional processes. For them there was a mandate from the customer to follow agile to execute their project. They already had finished one phase of the project where they had slogged long hours in office, putting lot of extra effort to complete their work. So for obvious reasons the team was concerned, thinking that they might get burdened by multiple processes in phase-2. They also had difficulties in adjusting to the paradigm shift agile brings in. The team seemed like interested only in doing lip service than making an attempt to understand what is required to be learnt!
So the discussion was focused more on the kind of challenges faced while dealing with this kind of isolated teams.We discussed on,

Burden of multiple processes; organization defined and agile process defined by the customer
Duration of such engagements
Documents driven v/s Collaboration
Dimensions of working in software services companies
Possible strategies that might work

Overall, though the discussion was good, it failed to generate any great energy. May be I was not provoking enough or candidates were not too keen :-(

On the last day I was really getting bored and same with my colleagues who had come with me for the camp. Some of the experienced members also seemed like not participating or contributing in the discussions. May be even they were getting bored with the quality of the discussions. Some of the participants found to be offtrack and were seeking silver bullet solutions to their day to day problems.

Anyways, i got to see 2 interesting applications, one for automated testing (Sahi) and the other an e-learning application from Industrial Logic. Thanks to both Narayan and Naresh.

Why Agile Coach not an SQA member

2010-03-26T17:11:00.035+05:30

Off late I have been hearing that a lot of organizations are making their SQA members as agile coaches and this is disturbing me. My belief is that, by calling an agile coach as an SQA member or making an SQA member agile coach, the objective of agile coaching gets diluted. There seems to be a misconception built around agile, by looking at it as just another SDLC process. I am just trying to analyze "why agile is not just a process", "why agile coaches shouldn't be SQA members" and "how coaching gets diluted by doing so"

If I look at the concepts and definition of Software Quality Assurance (SQA)

SQA is defined as a planned and systematic approach to the evaluation of the quality of and adherence to software product standards, processes, and procedures.
SQA includes the process of assuring that standards and procedures are established and are followed throughout the software acquisition life cycle. Compliance with agreed-upon standards and procedures is evaluated through process monitoring, product evaluation, and audits.
SQA evaluation of the product are normally done in relation to the applicable standards (set of planed, defined practices).

This I picked up from Nasa website, referred in Wikipedia; Similar explanation can be referred in another Wikipedia link on Software quality Management.

If we look at Agile,

Agile is not about predefined practices. It is all about set of values and principles.
Agile does not talk about following a predefined practice/process, instead it talks about responding to the feedback, to define one's own process for the betterment of the project.
No agile practice talks about auditing a practice/process in place, to measure the success of the project. Instead in agile, working software is the primary measure of success.

Further thinking,

Over the yrs SQA activities have been performed only by non-practitioners (normally not programmers); where as agile methodologies are developed by practitioners and software craftsmen.
SQA activities are process oriented; where as agile is people oriented. Software are built by people and process focused approaches have tendency to ignore human elements.

Coach v/s SQA:

Agile coaches are more like change agents; SQA normally follows a predefined process.
Agile coach believes in client growth through innovative approaches; SQAs focus mostly on tracking.
Agile coaches are normally practitioners, not just preachers; SQAs are normally not practitioners and do not build software.
SQAs tendency is to introduce new processes into the system, but agile coaches try to make things simple by reducing processes as much as possible. When there is a conflict I think SQAs tend to fall back to old habits of creating/defining a new process.

What are the damages companies likely to have by calling Agilists as SQA members?

The language: Language has greater influence on change initiatives. Language makes people to think. There is already a strongly established vocabulary with attached meaning and notions around SQA. Labelling agile coaches to the roles of SQA, defeats the purpose of having agile coaches.
Resistance to change: Processes are required for running organizations. They are important. But at the same time technical people resist SQA members. They don't like heavy processes which take most of their time from developing software. Since already by human tendency there is a resistance to change, the moment agile coaches are called SQA, bringing any positive change becomes more difficult.
Checklist driven: SQA groups have the tendency to develop checklists around their process for evaluating the teams. In similar lines the moment agile coaches are part of SQA groups, they will be pressurized to develop similar checklist around agile practices. Though at the outset it looks logical to master a practice, it does not let people to think. Thinking in terms of why a particular practice exists, is it the better solution to my problem or by doing what I can better it and so on.

Ok, then the question is what should I be calling a set of agile coaches in the organization?
If there is a pool of Scrum Masters or Senior members who are knowledgeable and playing the roles of internal coaches, companies can think of forming a dedicated group in bringing more value to the organization. Such groups for example may be called as,
- Center of Excellence for Agile methodologies
- Catalysts of Software Development
- Agile Mentoring Group

Absolutely there is no intention to demean the work SQA members do. They do their work with right intention. But very few will have courage to change the system when the predefined system demands them to do certain things.

Agile india 2010 conference - Post Modern Agile

2010-02-07T21:14:00.005+05:30

On 22nd and 23rd January I attended Agile India conference named “Post Modern Agile” held in Bengaluru, organized by Agile Software Community of India (ASCI). Few topics were quite interesting for me in this conference and the elite 4 speakers (Gordon Pask Award winners) made it more enlightening with their content and presentation style. Except Naresh, that was the first time I had heard the other three speaking :-)

Visit agilebengaluru2010 for more details. However in the ASCI website they seem to have displayed only the Mumbai schedules. Even slide decks made available seem to have quite a bit of modifications.

The program started with David Hussman presenting the key note on Outside the Code – Using agile ideas to drive the product success. Since slide decks are modified I am finding little difficulty to recall all that he spoke.
Following would be my key take away
- More insight on Discovery and Delivery, with 4 different practices.
- 3 Meta Roles – Builders(Dev and Testers), Trackers (Sponsors and Management) and Customers & PO [Jeff Patton seems to have termed them in Mumbai conference as Team, Coach/ScrumMaster, Customers/PO]
Overall it was a nice session to build the context for some new stuff in the agile world. He also recommended couple of books to read; one among them is “Black Swan” which I remember as it was already suggested by my colleagues; other I don’t remember :-(

Programming with Stars was another theme which I liked in this conference. In the beginning I did not know that this was a competition. Refer this link for more details.

Once the competition was over on the 2nd day, Naresh and JBR demonstrated pair programming. It was full of running commentary (read as conversation) by these two with light humor. They demonstrated how pair programming is fun at work and at the same time adds so much value to software being developed. Once they finished their presentation they wanted some experts to comment on that. No one actually was loud enough to say if it was good or bad. When Bas Vodde (Co-author of the book Scaling Lean & Agile Development: Thinking & Organizational Tools for Large-Scale Scrum) who visited the conference on the 2nd day was asked to give his comment, he teased them by saying “you guys messed it up!”

However I did not like the way this competition was organized. Participants were coming up with their own program to demonstrate which I think made it difficult for others to understand the entire context of their program though they gave brief explanation. Instead May be giving a tiny piece of requirement (common/separate) to all competitors and sharing the same with audience before starting the event could have been more beneficial. Also since the number turned out to be less for this competition, organizers could have arranged few laptops ready with necessary packages installed for volunteers. Having said this, in spite of such situation, organizers and participants were quick enough to arrange laptops and get the show running keeping the objective & time in mind.

Naresh and JBR were good enough to pull of another interesting topic Theory of Constraints and JIT. At no point of time I felt the session was boring. There were quick 5 min exercises for the participants to find what bottle necks did they see in their projects and team captains were asked to speak about that. Later team captains were rotated and asked to find a solution which might work for the team. It also triggered couple of conversations and was interesting. I think it was a decent way to sensitize people about TOC.

Jeff Patton talked about Story Mapping and it was good to know a new technique for story mapping. But I am not very sure how effectively I can apply this in real time projects. I need to go through this more in detail before experimenting. The key concern I have on this is about cost to benefit ratio. The session was good enough, considering the soft spoken Jeff Patton. However I felt too much time was spent on deciding the project and interacting with participants, considering the time slot available. In the end I felt Jeff could not cover some content he intended to cover.

Joining The Dots - Message from Captain Planet
This was about Global warming. I don’t really remember the name of the speaker, but it was told that he likes to call him as Captain Planet. The speaker seemed all charged up and looked quite emotional. But yeah, I think this topic deserves to be emotional!

Stop It Or I will Bury You Alive In A Box
JBR started this session with a "Mad TV" video clipping. It did not have any great significance with respect to the topics he wanted to discuss, apart from saying “Stop doing certain things in Software Development”. Basically the topic was about Do’s and Don’ts in agile. However the video added some humor to the session which was otherwise 1.5 days of continuous learning.

There were many other topics if you see in the website. Some I could not attend and some were not very interesting for me. I also felt some speakers were quite boring because of their monotonous tone and lack of meat in the content.

The main hall was not really convenient for all. Because of the 4 huge pillars many of them were struggling to see the screen and the speaker though the hall was in circular shape.

Still I would say, the conference was good overall, but as expected I could not relate Post Modernism (which I think has a different meaning) with any of the topics. Just that there are some new practices being evolved and it was a good platform to share them with the community.

Retrospective Using Six Thinking Hats technique (with Brain Writing and Affinity Clustering)

2009-11-21T07:49:00.007+05:30

While googling for some thing, I found this topic called parallel thinking. Just out of curiosity I opened Wikipedia to know more about this and landed up in reading 6 Thinking Hats by Edward De Bono who coined the term Parallel thinking. This triggered me to map 6 Thinking Hat (STH) steps in various practices in Scrum which involves decision making. I zeroed in on trying this with Retrospective. Retrospective is a way to inspect and adapt to design our way forward. By the time I finished reading this I had started feeling that knowing this technique as Agile Coach might be of great benefit as well.

Why another technique?
The very purpose of retrospective meeting is to seek feedback and figure out how we intend to work in future. Different techniques like Plus-Delta, Good-Bad-Ugly etc which I know have no emphasis on creative thinking or systematic thinking to design efficient ways of working. Many times team members throw some random thoughts and vanish making the retrospectives ineffective. Certain team members do not even contribute. So I guess STH with Affinity Clustering & Brain Writing should address these concerns. Or simply consider this as one more technique to do retrospective when you are bored with earlier techniques.

Warning: Though I am convinced that this works well for retrospective, I am yet to try with actual project teams. However I have used it in many occasions of my life and found to be very useful.

Logistics:

Have a set of 6 colored (white, red, black, yellow, green and blue) sticky notes. Ensure each one in the team has enough sticky notes to write. Also ensure pens to write on dark colored cards. If arranging such sticky notes/pens is difficult, just use the white board; write down the hat in consideration or any method which gives a visibility about the hat team is wearing.

Facilitation:
Identify a person whose responsibilities would be to facilitate the meeting, identify who is deviating from the Hat in consideration, ensure the discussion won’t turn into nonproductive argumentation and keep a check on time. In essence the facilitator is actually wearing Blue Hat throughout the meeting. Needless to say, even others can support the facilitator. But ensure you are time boxing every hat.

General guidelines:
Brain Writing: That is each member of the team pick up the respective colored sticky notes based on the Hat in consideration; start writing the points independently without getting influenced by others; for a fixed duration. Remember one point per sticky note.

Affinity Clustering: Team members collect all the notes, remove duplicates and categorize them in to dynamic themes that emerge. Put the sticky notes on a white board under respective headings for further analysis.

My idea is to apply STH technique in 2 stages. One is in the beginning where we start identifying problems and root causes. Second is, once we identify the actions to address the problem, to refine if those actions are workable and efficient. The reason is, many times teams don’t really think much about the action items once they are identified. It can so happen that we later find that an action item listed is not feasible, leading to unresolved problem in the next sprint.

If you find the technique heavy weight or time consuming, try out in sprints of bigger duration like 4 weeks or after your release cycle. Once you get acquainted with the technique I am sure teams can finish it quicker with better result.

Few Basics about STH:

To know basics of STH methods one can refer De Bono's book or Wikipedia or many links available in internet. I am not explaining the same here.
There are 2 ways to use the hats. Single use and Sequence Use.
In Single Use method, the hats are used as symbols to request a particular type of thinking in quick succession.

In sequence use, team uses one hat after the other in a certain sequence.

Cautions:
1. The durations for each hat I have put are only for reference. Teams can decide what suits them better.
2. 6 thinking Hats” technique discourages argumentation. In case of conflict, put both the views in parallel and assess them.
The method I am suggesting here is Sequence Use.

STEP 1: Data Analysis and Designing future

BLUE HAT (Thinking the Thinking): (5 mins)
Without objective it is not possible to think in right direction, so start with Blue hat. List out specific objectives for the retrospective (remember not generic). Start the Brain Writing exercise with blue sticky notes, listing 1 or 2 high priority objectives per member. More would be difficult to achieve!

Maximum 2 minutes for writing; 3 minutes for removing duplicates, paraphrasing (if necessary) and sticking them to the white board;

WHITE HAT (Neutral Information): (10 Mins)
List down all main events of the past sprint in brief, key objectives of earlier sprints, defects list, feedback got etc with a neutral view, as many as possible within the time period decided. Data related to defects, review comments etc can be directly pulled out from tools in use to save time. Stick the notes written on the white board.

7 mins to write; 3 mins to remove duplicates and sticking;

YELLOW HAT (Positive thinking): (10 Mins)
List out every thing you think deserves appreciation and you would love to continue such things in future sprints. Don’t worry about the ambiguities at this stage. Be more constructive and generative. You can also be speculative and opportunity seeking. If there is no unanimity in agreeing upon any claim/point, provide justification, data/reasons.
The white hat thinking also would be handy to segregate “Plus” and “Delta”.

Alternatively, you can also segregate the positive points from the White Hat section and move them to Yellow Hat where ever possible.

5 Mins: Identifying positive points.
2 Mins: Remove duplicates, categorize and stick;
3 Mins: For any reason/justification giving.

BLACK HAT (Risks, Threats, Potential problems): (30 mins)
Black hat is more about being cautious, identifying risks, identifying potential problems and obstacles. Identify what are the weaknesses that we need to overcome. Members can also look at identifying, by continuing “what” the sprint/project might be jeopardized (e.g. symptomatic solutions, organization direction etc).

Once you are done with this, together start working on getting root causes for the problems by applying techniques like 5 Why, Ishikawa etc.

7 Mins: Identifying weakness areas, potential problems.
3 Mins: Remove duplicates, categorize and stick;
20 Mins: Root cause identification (may be for 5 biggest problems faced)

GREEN HAT (Creative thinking): (15 mins)
By doing what I can improve the situation? What are the new ideas, options and alternatives to try out in the next sprint? In the beginning this is irrespective of what problems the team had faced.

Green hat thinking is applied for 2 categories to identify the solution
1) For the initial objectives/goals defined.
2) For the root causes identified.
In both the cases, the attempt is to identify a concrete solution for the problem.

12 Mins: Idea generation, identifying best feasible solution possible.
3 Mins: Remove duplicates and stick;
S T H has another option in Green Hat thinking and it is called PO (Provocative Operation) but I am not suggesting this in retrospective.

RED HAT (Emotions and Feelings): (5 Mins)
De Bono says red hat legitimizes emotions and feelings as an important Part of thinking.
All you need to do now is get all your emotions on the red sticky notes. It can be related to an event during the sprint or about an action/decision or about their feeling of current reality in the project. No one needs to give any justification/logical basis to prove their feelings. Again categorize them and put them on the white board under “Red hat” heading. This is more of intuitive.

However though there is a freedom to express one’s emotions, people should be cautious in showing displeasure to a person or their displeasure to work in the project etc. This is not a platform to handle such emotions. It should be goal/objective oriented.

STEP 2: Working with Action Items

At this stage, apply 6 thinking hat technique in a “Single Use” method on each solution/action identified to quickly get a concrete, feasible action item. There is no dire need of using Brain Writing at this stage.

Pick each action item or solution identified and recursively apply STH technique in quick succession.

Once completed, collectively figure out the best action you think is going to work effectively. Finding an efficient solution is equally important as identifying the real problem.

Directory services using Meibo

2009-03-03T14:49:00.009+05:30

Recently I worked on a project related to LDAP for few months. It was to develop a back office application to maintain our Client’s Directory (LDAP) dedicated to their customers. As suggested by Valtech, client had decided to use a software viz. MEIBO developed by a French company ILEX (http://www.ilex.fr).

Meibo is a nice tool to use if you want to quickly design and develop a smart UI based application to manage your Directory. Do not compare this with a LDAP client because the objectives are different. One can also use a Database instead of Directory!
Below is a brief introduction to Meibo as mentioned in one of their documents…

Introduction:

Meibo is developed based on XML technologies and is a smart directory content management tool. Meibo has the ability to mask the complexity of the underlying directories and provides business oriented views. The following diagram compares a physical view of a LDAP directory with Meibo business-oriented views:

Meibo enables the user to visualize directory data functionally and to interact in a customized way with the various information resources available. Indeed, Meibo allows to create business oriented interfaces in terms of content editing and navigation logic.

Fully compatible with all LDAP directories and SQL databases, Meibo is the key directory content management solution to data publishing and updating. Moreover, Meibo Workflow, working in accordance with the WfMC recommendations, modelizes business oriented procedures related to:

the lifecycle of an employee in the company,
the data import/export operations,
the validation process,
the delegation model

Uses of Meibo:

Meibo provides assistance in the quick setting of yellow pages and white pages services, self-management, workflow and identities management. It also makes possible to design:

organization charts,
reports and paper directories,
administration delegation,
eProvisioning,
rights management policies.

Meibo enhances data in directories:

using Web interfaces to make data consulting, updating and administration delegation easier for users
using Web services to centralize application access to data model,
using real-time provisioning and batching mode with Meibo Batcher.

------------- End ---------------

Since most of their information is copyrighted I would suggest readers to visit their website or support team for more details and also for documentation.

Meibo comes with few simple but very handy features which I would like to highlight (There are many other good features which can be found in their document anyway). These features I think reduce lot of developers’ effort.

Fully automated delivery process with minimum configurations.
The way the tool is designed to cater to Directory needs. For example, resource based views which automate many things.
Automated code generation for functionalities like Search which are very handy.
Finding unused functions and “find in script”
TO DOs
Few language support (for Internationalization)
In built server to facilitate quick testing of the application.
Many sample projects to facilitate learning.
Global mask for having a common background.
Ability to call Java code from Meibo.
Controls to enable/disable logging information, adding new Jars to the class path, configuration for accessing Proxy servers etc.

Like this there are number of very good features Meibo has which can be found in their documents. But there are many short comings as I observe, which are not available in their documents:

Meibo script is not Object Oriented. I think this one line speaks volume!
Meibo comes with a scripting language called Meibo script. This is based on Java scripting. But the version it supports is only JavaScript 1.0.
You can’t write unit tests like the way you write unit tests using JUnit or HttpUnit. I don’t think there is any kind of Framework available!
Meibo did not seem to be a popular tool. Don’t expect any kind of outsider support apart from the support from Ilex. Finding any article related to Meibo also could be difficult! You have my article now anyway ;-)
If the application being developed is little huge, maintaining Meibo script seemed like a difficult task for me. The main reasons could be because it is not object oriented, enforces you to use Global variables for different manipulations like switching between views, from one view to another view’s tab, for avoiding duplications etc. But certainly I appreciate the way Ilex designed this tool to make the code more maintainable and organized.
For developing simple applications it is easier. But the moment you start introducing Workflows, Provisioning line etc, it certainly needs Ilex support, though they have different reference materials.
Since you don’t find any Meibo communities the dependencies on Ilex is high! This is NOT an open source tool or Freeware.
Meibo supports only up to JDK 1.4.2. So the application breaks even if you are using a Jar which is compiled using JDK1.5. Be careful!
Few times I also felt the kind of Exceptions thrown by Meibo were not good enough and understandable.
The documentations they have no examples related to using Meibo in Unix based OS. This becomes confusing many times if you are trying to deploy in Unix/Linux for example. However on Windows it looked very good.
There are different limitations related to UI. For example, there is no List component, progress bar component, style sheets do not have support for alignments, no easy way out for using your own style sheets etc.
Batch processes created can not be called from scripts directly. However you can use them as part of Workflows.
Script Debugger: “Step Over” is not efficient enough. Once you enter the function you using this do not help. Step Over does not work for loops!
When in debug mode for any change though it prompts for save it does not save, creating a big confusion.
People who have used Eclipse/NetBeans kind of Editors may find this not good enough. For example, no short cuts to access function definitions, no easy refactoring ways, no support for short cut keys etc!
Since it is more like proprietary software it will carry most of the disadvantages of such software.
The Meibo Webservices/Plug-ins do not support all types of tags available in WSDL files. For example, it can not read wsdl file that contains complexType tags because Meibo does not support complex type.
Tab ordering did not seem to be consistent! When application is run I found at time the curser hopping around unwanted components!
Though they have different language supports as available in Meibo 3.4 it has support for English, French, Spanish, German, Italian, Portuguese, and Chinese. Sorry, no Japanese or Indian Language support yet :-)

However Meibo is still evolving like any other software and I hope Ilex will overcome many of these shortfalls very soon.

Importance of the customer participation

2008-11-02T16:36:00.006+05:30

When we talk about agile practices one of the key elements for success is Collaboration with customer, without which the project could be a pain! I had some what similar experience with one of the customers I worked with in the past.

What if the customer you are working with is not inclined towards agile and still following traditional approaches? What if there is not enough clarity in the requirements to start your work? What if the customer is not actively participating? What if the customer is not giving enough feed back? What if there is no dedicated Product Owner or a Proxy? What if the customer takes too long to use the system being developed and delivered after every iteration!?

Ah! I think if you are a novice in agile you might wonder how to handle such customers or how to confidently deliver after every iteration in an agile environment!

Can you break this kind of dependency on your customer?
To what extent you can reduce this dependency?
How do I handle such customers?

It is understandable that we can not always assume that the customers we are working with, always will entertain agile software development. Under extreme conditions, I think it is natural for people to start speculating that the project is not of high priority or some of the stake holders are never interested in the project or the people they have on board are apathetic towards work :-)

Well, instead of grieving on such things it would be nicer to tackle such dependencies. In one of the projects I worked on, to handle such problems we tried few different approaches which I think worked well. May be my inputs help some one to handle such customers! But make sure your customer is aware about what you are trying to do :-)

Since there was not enough detailed requirement, we started our iteration by writing detailed user stories out of the brief requirements we had. Though the user stories were not following any great format, we used to have acceptance criteria defined for each one of them. Once completed we used to request the customer to validate the user stories and give feedback so as to have a clear understanding of what they really want. Writing the requirements was part of the iteration!
After every iteration we made sure that we give sprint review demo to all the stake holders explaining each and every feature implemented (if customer wants or not!) and request for the feedback.
After every sprint we used to deploy the application at customer's location with all working features developed so that they can use it and give feedback.
Regular follow ups in getting feedback, weekly conference calls, publishing the work accomplished in wiki pages and sharing them with the customer helped us.
We kept on educating the customer about the importance of following agile principles and its value addition to the project when they actually participate. (This according to me one should do when ever and where ever has an opportunity. Never loose an opportunity you get!) So the stakeholders used to some how manage to attend the conference calls and sprint demos.
We tried to get answers for our questions during conference calls and demos. Normally during during conversations you get quicker response.
When ever we were not getting enough feedback we used to enforce them to answer our *questions* by following up professionally. I think asking questions is an easy way to get quicker feedback. After all both of you need to succeed in the project. It is just a matter of time and priorities each one has. For us as a vendor the project was always of high priority, but for customer this project was not a bread earner.

I think it is all about diverting the stakeholders’ attention towards the project in reducing the risk of dependency. Any positive approach should work as according to me project management is more of situation based than following a rule of thumb.

Vendors who are working with such customers should I think give attention to many aspects. I always feared that at some point of time such customers may backfire later; the kind of brand you have built in the industry with lot of effort over many years may get affected if the project fails! So at times it could be the Vendors who are the worst affected dealing with such customers.

Agile software development is ever evolving. Still many organizations are yet to adopt agile practices. Most of them are still following traditional processes. It is understandable that it would take some time to completely adopt agile methodology. But it is not good to be stubborn and not ready to have a look at stuffs that work and appreciate good values in it.

If you are a true believer of agile project management then you should be ready to enforce your customer to follow agile process. The money probably the customer has to invest on a Product Owner is negligible compared to the amount they probably may have to spend later. To enforce this, vendors need good ambassadors who can convey the values of agile principles and success behind customer’s participation at the time of getting the projects. If a customer is too adamant then I think they do not deserve your service or they might not be a right customer you should be working for. Vendors should be ready to sacrifice a bit of Current for a bright future. This I think also adds value to what you believe works well. It is important for the branding as well.

Lack of interest and less priorities of ONE could result in failure and frustration on the other side.

My transition to Agile

2008-08-09T12:02:00.011+05:30

In the software industry for about 6 years I grew up in a typical water fall environment. Throughout this period I was preached waterfall practices in every company I worked with. The CMM practices and the complex processes followed were killing me. PMP certification was one of the highly valued certifications. People with PMP certification were recognized as assets of Organizations irrespective of what they are capable of.

It was in 2005 when Valtech took over Majoris systems where I was working, I started realizing the values of Agile Project Management. Craig Larman, the chief scientist of Valtech was our mentor in one of the projects I worked in Valtech. It was not very difficult for me as an individual to move from Water fall practices to Agile practices as I was not in to complete project management though I was involved in many project management activities.

Following are few things I remember how Craig worked towards transitioning Valtech India completely in to Agile Project Management.

When he took over our project (onshore and offshore model) first thing he wanted to see was Continuous integration and testing. Within a week Cruise control was up with all the JUnits integrated.
In the background there were many things coming up, like building agile infrastructure and multiple training sessions on scrum practice. The cubicles (communication barriers) were gone and white boards were visible all around our project area. There were many cling sheets and information radiators around our project area explaining every one what we are doing.
Criag used to be there for most of our scrum meeting, guiding us how to conduct the scrum meetings and explaining us the value of scrum.
As per the plan we used to assemble in conference rooms for conducting time boxed requirement workshops and Iteration planning meetings with multiple projectors.
Design workshops, Mind mapping concepts, Estimation techniques were practiced with Craig's help.
Retrospective meetings were held to make us understand the true values behind them.
TDD and Pair programming were experimented, though we could not follow it to any great extent!
Onshore - Offshore scrum meetings were held daily.
Feature teams with feature team owners were formed.
Efforts were made to build true scrum teams (however I think we could not achieve this completely)
Wiki pages were used extensively to share information.
Product backlog and Iteration backlog were introduced.

Like this so many trainings, workshops and discussions gradually educated us to practice SCRUM. Before I realized I had become a fan of Agile Project Management.

In 2006 Valtech sponsored some of us to become "Certified Scrum Masters". Thanks a ton to Valtech for sponsoring this and thanks to Craig for training us.

Now I really wonder without proper client collaboration, Lean thinking and agility within the team, how teams can work efficiently? how much wastage they could be producing? how much stress they could be undergoing to make clients happy? how much client is paying for wastage & how much vendor is spending on wastage? how employees are getting stressed by their bosses without any good reason?
It is high time for all IT companies to move towards Agile.
I think I have transitioned for GOOD!

Retrospective Meetings

2008-07-26T15:28:00.006+05:30

Every one in the Agile community knows about Iteration Retrospective meeting. But most of the time when I observed the scrum teams missed certain key points while carrying out Retrospective meetings. I have tried to list out certain points based on my observations.

Retrospective meetings are NOT to point out individual's mistakes.
First and foremost point about retrospective meetings is to find effective solutions or approaches to solve the problems faced by the scrum team during the iteration.
Non participation by all the team members (Pigs).
It is quite important that every member of the scrum team attends the retrospective meeting. More over it is important that the members attending the meeting are not just silent spectators. Each one's active participation helps the team move forward successfully.
Scrum master giving explanations/answers
Scrum master's role is to facilitate the Retrospective meeting and not to give solutions to the problems faced by the team. It is team's responsibility to find the best approach to tackle the problems faced by them. Scrum master can certainly help to find better solutions.
Delta is not "what went wrong"
Delta term in the +, ∆ analysis is about finding what could be improved in the next iteration. It is not about listing out the mistakes of scrum team (or events).
For example, one of the delta points read some thing like this "Regression testing was not effective". Instead team should bring up new ideas to improve the regression testing.
Vague/Confusing actions
As per my observations, teams utterly fail to generate concrete actions. Unclear actions will never yield good result. For example, one of the actions read some thing like this "Regression testing should be improved" which was having no clue about how regression testing could be improved, what tool can be used, what process/approach to follow, who is responsible etc. When the next iteration starts, the problem still persists and same action item is generated in the Retrospective meeting.
Actions items getting assigned by scrum master.
Once all the actions are noted down the scrum master starts assigning them to different members of the team! Another problem i saw is, every action is getting assigned to the entire team!
Actions for Organizations
As part of the plus-delta analysis team generates certain actions for the organization. But the concern is these points are never communicated at the organization level. Either Project stake holders will have no clue about the problems faced by the team or these problems are never addressed in a professional way.
Vote rigging
When teams practice multivoting, while distributing the 100 points to each action, team members try to vote for only those points which are raised by them or which are mainly affecting them as individuals. Team members fail to address the worst problems faced by them to succeed as a team in such cases. Some times even important points which are proven in the industry as best practices are never voted by the team.
Getting offended when delta points are raised
This is one of a typical cases and more to do with certain individuals. If with the best interest of the project there is a suggestion to improve certain actions taken by individuals during the project execution there is no point in getting offended. These are to succeed as a team. Many a times scrum masters are the victims of this especially when they are from typical project management background. Certainly this needs a radical change in thinking and educating them.
Actionable items not part of the next Iteration backlog
As stated by Ken in his book, action items should be added in the next iteration and should be devised as high priority nonfunctional Product backlog. Skipping them from the IBL/PBL will reduce the clarity as well as the tendency to miss out them is very HIGH.

KEN Schwaber: Retrospectives that don't result in changes are sterile and frustrating

Scrum meetings

2008-06-15T12:44:00.010+05:30

Though in the beginning, attending daily stand up meeting (viz. Scrum ) for me used to be an interesting affair, over the period of time I was getting bored. The tones of team members used to look like monotonous and the updates given were not found to be informative enough to understand the pain areas. This lead me to discuss with some of my friends & colleagues and I found even they were having similar views. So I thought of collecting all such views and tried to find better ways.

Daily scrums, where and how they are abused:

Scrum meetings are used like status update meetings to the scrum master. Eg. Face towards the scrum master and give updates.
Road blocks are never brought to the notice of the team during scrum meeting; when they are being discussed entire team does not participate. There is huge amount of ignorance.
Scrum updates are not informative. For example just saying “Last 24 hrs I have worked on user story number x.y and I will continue to work on the same the next 24 hrs” will not help other team members much to understand what (s)he is actually working on or if there is some thing which others need to know.
Cross talking during scrum meeting. The instincts of certain members will not just allow them to shut their mouth 
Secondary meetings are never called to share important points.
Team members (so called Pigs) not respecting the scrum timings.
Lack of presence of mind while others are giving their updates.
Absence of Pigs during scrum meetings.
Interfering chickens during scrums.
Scrum meetings used for giving lengthy lectures by Scrum masters.
Scrum master questioning individuals for unaccomplished tasks during scrum meetings and seeking explanations for not completing.

How a scrum team can be helped to conduct proper scrum meeting:

Apart from the normal routines of training the scrum teams on right scrum practices there could be many more inputs especially when the team is not an ideal scrum team. Scrum master should help such team members with proper guidelines.

Scrum master or more experienced team mates should help the inexperienced team members in volunteering for tasks before coming to scrum meeting, so that they are very clear with what they are talking and what they will be doing. This will reduce cross talks to a great extent during scrum meeting, reduces the confusions and also saves time. More over this makes every one aware about their responsibilities and make them more productive gradually.
If one thinks that he has more to update and he may forget some points, he can note down them. For road blocks make use of information radiators.
Scrum masters should protect the scrum team from chickens. Chickens can be in the form of management, different project mates, SQAs who are not part of the scrum team etc. One easy way to tackle such interference is to have comic sign boards with the message what pigs wants to convey to the chickens at the entrance of scrum area.
If the scrum master thinks that certain team members are not giving enough attentions while other are giving scrum updates, may be scrum master should call for a secondary meeting and discuss the issues by giving his observations. This problem typically happens when the team is not an ideal scrum team where Testing and development activities are handled by different individuals, different team working on different modules but working on the same project etc.
To bring in the awareness of attending scrum regularly on time, teams can impose some kind of penalties. For example, late comer pays X amount towards team fund and use the team fund for buying useful books or for celebrating events like birthdays/anniversaries or rewarding the best contributor or even for charity!
To control cross talking a team was use softballs to throw at them. But this may dilute the seriousness during the scrum. The best way could be to bring the awareness during secondary meetings after the scrum or Scrum master can give a signal to stop this menace. For example, display a sign board with lips sealed!
How a team can control the scrum master? In typical scenarios normally Project Managers or Project Leads act as scrum masters. Team members are always scared of after effects for pointing out scrum master’s mistake. This normally happens when companies are transitioning from typical Project management to Scrum. One of ways could be to have a suggestion box and team members type suggestions and drop in this box. During every retrospective these suggestions should be notes as part of Delta.

Hope these information helps readers who are novice to Agile.

Why scrum failing

2008-06-15T12:25:00.004+05:30

In true scrum sense a scrum team should have lot of ideal characteristics. But I always felt practically it is very difficult to build such teams. Implementing what one preaches is very difficult. Achieving stuffs like cross functional teams, self organized teams are hard nuts to crack . One can not expect every team member to be at the highest level. Probably such kind of team will make its own way to succeed in the project or even a water fall model would do the needful. So certainly I am not considering an ideal scrum team while laying down my observations.

Many of the scrum stalwarts have already pointed out many scrum smells till date. But I made an attempt to tweak into certain issues based on various discussions I had with different friends who are working for different companies and based on my personal experience with different team mates.

Where is the real problem? Why though Scrum looks good it is failing at times.

I think this could be due to 3 main factors.

1. Lack of in depth knowledge:
Due to poor/no trainings, poor/no coaching, lack of reading etc.

2. Inability to practically apply the knowledge:
This may be because organization is not a good facilitator of agile practices, organizational limits (funds, involvement etc), Middle management is not supportive, team is not coordinating, client is not supportive etc.

3. Lack of interest :
This could be because Scrum master is not having the right spirit to drive the team (I am following this just because some one asked me to follow), team lacks motivation, team thinks that scrum is not so useful etc.

Probably every reason you find will fall into one or combination of these categories. I am not really making an attempt to give solutions for these factors as there are plenty of suggestions already from experts.