Kanban tidbits

Here are some tidbits

• "Kanban", the Japanese word translates to "signboard"
• Taiichi Ohno developed Kanban
• Toyota management were looking at ways to reduce/eliminate waste. One of the ways that they discovered to eliminate waste is by reducing the inventory, and to build the product "Just in Time". They were inspired by the supermarket system because supermarkets stocks only what is needed for their customers and this is based on buying patterns.Customers can walk in with confidence that the product is available, and choose whatever they want. The items are replenished as and when the stock goes down and everything happens "Just in Time"
• JIT manufacturing was the brain child of Kiichero Toyoda, founder of the Toyota Motor Company
• Kanban is a means through which JIT is achieved
• Kanban is more of an implementation process rather than a planning process

Agile means no documentation - common misconeption

Before I begin my Agile training programs, I provide an opportunity for the participants to share their understanding about Agile. Most commonly heard definition include

"Agile = No Documentation".

This is the most commonly misused and mis-communicated definition. I don't blame the newbies however it is the value

Working software over comprehensive documentation

that has been defined at a higher level of abstraction by Agile Manifesto that creates such a misunderstanding coupled with inexperienced Agile evangelists.


For most of us, as soon as we hear the word "documentation", the first thing that comes to our mind is the "Microsoft Word" document, and the ISO-CMM level prescribed requirement/design documents that we might have written in the past, isn't it ?
So, when a newbie reads the documentation related value from Agile manifesto, they generally assume that one needs to dump documents, and rely purely on running code(working software). However, Agile manifesto is trying to say that "prefer" working software over (not abandon) comprehensive documentation. What it means is, try to create working software, because this is the only thing that adds value to the customer's business and not the extensive documentation.
Next question I generally get is "if we don't do extensive documentation, then how do we retain the knowledge ?', "what is the contingency plan for attrition as this would result in loss of precious knowledge ?"
My take on this is, "do document" in whatever way you can to protect the customer/yourself/project to retain knowledge. Agile value is trying to say that, don't do documentation for the sake of doing it, however document information from the context of adding value to the customer.

In one of my past experiences working on an Airline and defense related projects, we had applied Agile methodology, and found that extensive documentation was indeed a must to conform to various standards. We wrote necessary documents as it added value to the customer, and customer was willing to pay for that.

Documentation not necessarily mean capturing information on "Microsoft word" ! one could write something on the white board or flip chart and take pictures using a digital camera. The images stored could be considered as a project document. Similarly, recorded videos, good java docs(for example), screen captured images, etc could well be considered as project documents.

Jerry Weinberg's take on Agile

I am a big fan of Gerald Weinberg,and recently in an interview on Citerus, he has made some encouraging remarks about Agile. Thought would share the portion of the interview here

Q: You must have seen a whole bunch of ideas, about how to best do software development, grow and die over all those years. Do you see the agile movement as a pendulum swing or is it a move in a new direction?

A: How about a pendulum swing in a new direction? It's a pendulum swing because approximately every decade, there's a fresh movement to "solve the programming problem." High-level languages, structured programming, object-oriented programming, ...

But it's a new direction because it's the first movement to focus largely on social processes rather than purely intellectual ones. For that reason, I believe, it has more hope for success than the earlier movements, each of which made a little progress, then largely ran out of steam before achieving its grand promises.

Of course, agile won't achieve all its grandest promises either, given the conservative nature of human beings, but that's all right. After another dozen decades or so of incremental improvement, we'll begin to see some really fine software development. Well, I shouldn't say "we," because none of us will see them, but at least our great-great-grandchildren will be able to look back at us and laugh at our crude methods.

Gerry is also famous for using analogies to explain things and, making comments on lighter side. Here is an example...

Q: If you're the J.K Rowling of software development, who's Harry P then?

A: Well, first of all, I'm not a billionaire, so it's probably not correct to say I'm the J.K. Rowling of software development. But if I were, I suspect my Harry Potter would be a test manager, expected to do magic but discounted by software developers because "he's only a tester." As for Voldemort, I think he's any project manager who can't say "no" or hear what Harry is telling him.

Applicability of Decision Market technique in projects

Decision Market a.k.a prediction Market  is one of the techniques being used by many universities, governments, research institutes, finanacial companies to predict the future. These predictions have helped many organizations in avoiding obstacles, making better decisions, and in turn becoming  more profitable.  I am of the opinion that this concept can be used in various aspects of software development too.  For ex:  Iteration Planning, Release Planning, Product Planning, etc

This is how I am envisioning applying prediction market concept for release planning

1. Invite all the stakeholders (from the management team), key people from the project team who have good experience on the project

2. Allow them to go to a hall/room and cast vote on a preselected key concept like "the probability of having the release X on time".

3. Ensure that no one discusses their answers with each other until they come out of the room.  This would ensure that people don't get influenced by others decision.

4. Let each person also give the reason while casting the vote on why there could be a delay in the release. This would provide an opportunity for the stakeholders to correct the mistakes and avoid any unplanned obstacles/impediments.

5. Announce an incentive for the people who are making the accurate predictions. 

At the end of the release, identify all the issues faced during the release, and also the actual release status. Whoever has predicted the right things should be given the promised incentives.

More info about image can be found here

Even though the original prediction market talks about punishing the wrong predictors, I think it may not be a good idea in the software development senario. If  one is betting in an open market, one would not really care if the other person is winning or loosing. However in a closed environment like  a project team, punishing one person over the other, leads to animosities and things like that.  

In fact, Planning Poker based estimation technique could be considered as an avtar of prediction market.  During planning poker, the team is given an opportunity to provide their view on the effort needed in completing the task. View from the majority is taken and a consensus on the estimation is drawn. 

Agile 2008 conference had a session on estimation technique using decision markets. Since I didn't attend the conference, am not sure about the content covered during the conference. 

Even Google uses the decision market technique to make key organizational decisions. 

Going back to basics - Incremental, Iterative, Agile, Spiral

Words like Incremental, Iterative are quite often used in an Agile environment. In most cases Incremental and Iterative are used interchangeably. However it is not true that they are one and the same.

Incremental is anything that is built in small chunks, however Iterative is much more planned even though it is also built in chunks. Most of the Agile methods we see are incremental and Iterative.

There is also a debate that the current definition of "Iteration" which specifically talks about building something incrementally but in a time boxed environment is the definition introduced by Agilists, and not the true definition.

Brad Appleton has done a lot of research about the definitions and history around usage of Incremental and iterative words. Check this link out for more details

Agile, Scrum and CSM

Nowadays a lot of companies/software developers wants to get Certified Scrum Master(CSM) certifications. I don't understand why they are in such a hurry. Mostly CSM courses cost anywhere between 1000 - 2000 USD.

I have heard, The Scrum Alliance and the CSTs(Certified Scrum Trainers) are making a lot of money out of it. After looking at the commercial aspect emerging out of Agile methods, and on a lighter note,
I have come up with an analogy.

Agile could be compared to any open source software developed by a bunch of geeks to solve a specific set of problem(s).

Scrum could be compared to the companies who make use of open source softwares, and build a product around it, sell it and make money.

Importance of Scrum Meeting and Kaizen Line stoppages

Many a times Scrum meetings starts becoming boring and if you are one of them, who feel Scrum meetings look like micro management or merely a status update meeting, then this article might give you an insight into why you have such bad feelings about scrum meetings.

Scrum meetings are the backbone of any Scrum lifecycle. It is conducted on a daily basis, and the team members/product owners(as needed) and Scrum masters are expected to be part of this meeting.

I am not going to explain all the details about how to conduct the Scrum meeting but at a high level, 3 questions are answered,

• what I did yesterday,
• what I would be doing today and
• the roadblocks in achieving ones goal.
  

image copy right

Many a times Scrum meetings are converted to a status update meeting. However the intention of adding Scrum meeting to the Scrum Lifecycle seems to be to
1. Make the people to commit their goals in public. Psychologically, this would ensure that people would try to keep their word. This is done with the first and second question used in the Scrum meeting.
2. Impediments/roadblocks are brought to the forefront on a regular basis. This is brought out by answering the 3rd question in Scrum meeting.

The 2nd intention(impediments/roadblocks) mentioned above seems to be taken from the Lean/Toyota Production systems's Line stoppage concept. The idea is that a problem should be addressed and discussed as it occurs, rather than sweeping it under the rug to be forgotten. During these line stoppages all the employees and senior management would take part to understand the problem, brainstorm on the solution and, team effort is used to address the problem.

The problems that Kaizen line stoppages seek to eliminate are extremely costly to the company and ultimately grow worse as they move down the line to your final customers. By being proactive and seeking to eliminate the problem at the source, you're avoiding a lot of costs and headaches in the future. In addition, your employees will appreciate the process, as their input is being taken into account and their opinion is being listened to.

In Scrum, the question around "roadblocks" provides an opportunity to bring the issues to the forefront providing an opportunity to tackle it proactively.

If the values behind Scrum meetings are not understood properly, it merely reduces to a status update meeting, making it boring and people resisting to attend the meetings.

"World is Flat" and Distributed Agile development

I have been reading the book World is flat, since the last few weeks. In this book Thomas L. Friedman, argues the importance of outsourcing. I came across this wiki, in which the benefits of outsourcing is summarized as

Friedman argues that outsourcing has allowed companies to split service and manufacturing activities into components, with each component performed in most efficient, cost-effective way.

Many software and BPO companies globally have realized the above advantage of outsourcing. At the same time the global companies wants to improve the efficiency and productivity by applying efficient software development and industrial practices. One of the ways to reap the above benefits in software industry is by applying Agile methods. Currently there is a big hype in the software industry around Agile, and specifically in India, I am seeing a big wave of Agile hitting the software industries.

Even though I don't have statistics around outsourcing/distributed development, I strongly believe more than 60% of the software development happening in India is mostly in a distributed mode. Many of these developments are at different phases of implementing Agile practices.

Nowadays I have been hearing many Agile thought leaders arguing that "distributed" team is not a team and anything the distributed team calls as "Agile" is really not "Agile", like this one. Obviously if this is not called "Agile" then what are we practicing in this distributed mode ? So far the above mentioned argument is mainly coming from the developer community, thought leaders and not from business people. Business people seem to not care whether it is Agile or not, and at the end of the day, they want the application to be developed and want to make profit out of it. At the same time, developers don't care whether it is Agile or not and at the end of the day, they want to develop applications satisfying the needs of the stakeholder.

I agree that if some thing should be called as Agile, it needs to follow the values and principles mentioned in Agile Manifesto. I also agree that there is a value in following those principles. However if tomorrow, somebody comes and makes a rule saying that "Agile" word should not be used for projects in a distributed mode, then definitely one should start thinking about inventing a new methodology that can be tailored to distributed development.

I have started thinking, may be this is the right time to invent something new and that is more like "Agile" and somewhat like "lean" , that is flexible, efficient (like the "collocated Agile") and also mode free(collocated or distributed) !!! I don't know who else in the world is thinking about this, atleast I have started to do so.

Transitioning from Waterfall to Agile - Some tips

The day comes when suddenly somebody in the organization starts talking about Agile, and decides to implement Agile . This senior person who made this decision, would have heard somebody saying

Agile improves productivity !! and saves money Or the customer would have said, if you don't practice Agile I will not give the project to you(in an outsourced scenario)

Whatever the reason be, now the development team has to start practicing Agile. Note that moving from waterfall to Agile is not only needs the change in software development process but also the entire thought process surrounding the software development. Changing the thought process is not easy, as people practicing Waterfall would have reached some kind of comfort zone and immune to the pain and suffering from the consequences of practicing waterfall. So, it would take a lot more effort for them to unlearn the old way and learn the new way of doing software development.

In order to make the transition smooth here are some tips which could act as pain killers

1. First and foremost thing is to identify a good Agile coach.

2. Get all the team members to undergo training on Agile (XP, Scrum, etc)

3. Don't force all the Agile practices at once. Take one or two practices at a time and give sufficient time for the team to learn and practice.

- For ex: One can start with shorter iterations and scrum/daily stand up meetings.

4. Don't wait for the right day to start Agile. Start today. Go run to a shop and get hold of a Good Agile book(s).

Some good books for starters include,

• Agile and Iterative development a manager's guide by Craig Larman,
• Ken Schwaber's book on "Agile project management with Scrum",
• or any Extreme Programming book.

5. Start with 4-6 weeks iteration rather than 1 week iteration. Many new comers to Agile feel suffocated with 1 week iterations. Earlier the waterfall teams would have delivered softwares once in 6 months, and suddenly asking them to deliver in a short period makes them resist to Agile.

6. Take a simple and low risk project to try Agile. Also, with the help of Agile coach ensure that this project succeeds

7. Try to make use of visible tools like Flip Charts, Burn Down charts, Post-It notes, spreadsheet and encourage more interactions among developers. Make the developers to come out of their cubicles and start designing things on boards.

8. Ensure that management provides complete support to the Agile coach.

9. Even though having indepth understanding of Agile values and principles are key to succeed in an Agile environment, the team may not be able to grasp all of them at once. As and when each practice is introduced to the team, show them the relationship to the values and principles.

10. Don't bother if you would like to start with Scrum or XP. Instead, put all the Scrum and XP practices in a big basket, take the simplest one at a time and start practicing it. Over a period of time you would understand what is best for your team.

11. Scrum and XP advocates specific team structure like having Product Owner, Team, cross functional teams, no hierarchy, a team coach, scrum master, etc. This is a very sensitive issue. Suddenly informing the team that all of you are same, might heart the ego of senior people. I have heard stories where the seniors have quit teams as they were equated to the junior members by calling all of them as team and by dismantling the hierarchies . So, don't worry about dismantling the current team structure. Let the team learn slowly the importance of the values and decide what is best for them.

12. Let the project manager's slowly transition from their current responsibilities to become scrum masters.

Agile on a fixed bid project and Dr.Agile

Here is an article by Scott Ambler who explores the ethical implications of "fixed iron triangle". The article explores why many of business users insist on defining the price, scope, and schedule early in an IT project. It then overviews the overwhelming evidence for why this is an incredibly bad decision, and then describes an ethical approach to addressing this questionable desire.
Dr.Agile, a very good Agile readiness tool. I have not tested this personally, however one of my friend who tested has given very good reviews. Dr. Agile uses over 300 different indicators to determine which agile practices an organization is ready to adopt.

How to fail with Agile 20 Tips

Most of the time we talk about how to succeed in anything and give a lot of tips and best practices to others. How many of us do really remember those tips ?

What if somebody lists all the bad things one should do to fail ? Do you read it ?

Does this interests you ?

If so, then read this new article, How to fail with Agile, 20 Tips to avoid success by Client Keith and Mike Cohn

We don't have any resources available in resource pool

I am sure you would agree that we use the above statement atleast couple of times a day, especially if you are a project manager in one of the software companies. A few years ago, while I was interacting with Craig Larman, he mentioned that "human beings" are not fungible resources, they cannot be called as "resources". That was the first time I learnt that ugly side of calling programmers/software engineers as "resources".

The word resource, in the past was widely used to mean things that are "replaceable"/fungible. For ex: A broken chair can be replaced by another new chair. Another interesting feature of a resource is, you can start using it immediately. Ex: Once you buy a new chair, you can start using it from the next minute.

I don't know from where it all started. However I have been hearing the usage of the word "resources" implying mostly "people/programmers" since several years in the software industry. When we hire a new programmer, we say that the new resource is being hired in place of the old one. We are aware that two human beings cannot be same, one "developer" cannot be replaced by another cloned "developer" with exact specifications. They are two different people coming from wide range of experiences, even though they have "similar" work experiences and designation.

So, let us consciously stop calling "human beings" as "resources".

Here are some more people who think on above lines

• Mark Gregory


• Aaron


• Bill Ryan

Is it a sin to use tools in Agile software projects ?

The first value of Agile Manifesto clearly says, "Individuals and Interactions over Process and tools". Does this mean that usage of processes and tools needs to be reduced ?

Many Agile evangelists prefer using just flipcharts to write their design diagrams rather than using rational rose/any other diagramming tools. These Agile designers are proud to say that they don't use any software tools. However Kent Beck one of the Agile signatories shares in his latest white paper on "Tools for Agility", that when he and others created the manifesto they never wanted to disregard the usage of tools. However they felt that tools are ideal "If" it helps them in certain areas of work and specifically in some of the transitioning activities. Kent is not negating the usage of tools, however the tools like flipcharts, post-its and white boards have their own limitations. They cannot be shared if used in a distributed environment, it might get lost, and things like that.

In the white paper mentioned above, Kent makes some powerful statements. Some of them are as follows

• Every quantitative change of an order of magnitude creates a qualitative change


• A transparent team can more cheaply and effectively coordinate their efforts towards shared goals


• It may be hard to unlearn habits and beliefs, but in a world of wide and
  free flowing information, keeping secrets is a position of weakness


• You never know when you are going to be found out. Transparency is the new strength

I personally beleive that tools are very much needed in any software development, however tools should consciously be choosen and introduced into the project environment. Also a constant inspection and upgradation is essential to ensure that the tools are not becoming bottlenecks and hampering productivity & creativity.

Retrospective smells

Retrospective is the heart of Scrum life cycle. Many Scrum Masters who are new in facilitating Retrospectives find it hard to handle it. Keeping the sensitive nature of this exercise and keeping the emotional aspect in mind, one needs to be really creative, courageous while managing the team doing retrospective.


More info. about the image

George Dinwiddie shares the following retrospective smells.

1. Retrospectives that limit themselves to the three questions, "What worked? What didn't work so well? What are we going to change?"
2. Retrospectives that don't ensure that all the participants are represented. It takes care to get the thoughts and feelings of the introverts.
3. Retrospectives that don't establish safety, or at least acknowledge the level of safety felt by the participants.
4. Retrospectives that are designed to lead to a particular conclusion.
5. It's not a retrospective if you've got "the answer" before you start.
6. It's not a retrospective if the answers come from the leader instead of the participants.

It is very clear that retrospective as a tool can fix things or break things if not done properly. Knowledge and experience of the scrum master plays a key role in facilitating retrospective. Here is a good web resource that has been created by Agilists to share their retrospective experience and in turn help others.

Best time to do performance testing in an Agile environment

In the traditional model of software development major release/milestone dates are fixed, and performance testing is done just before such milestones, and it occurs mostly after the completion of coding, integration and system testing for a chunk of requirements. In an Agile environment too, release and milestones dates are planned, however, between the start date and the major release date, multiple iterations keeps happening and developers keep churning the code.

So, the next logical question to ask is,

In an Agile environment, is it still advisable to do
performance/scalability kind of testing before the major release date Or is there a better way to handle this ?

My personal view is, the non-functional requirements(the -ilities, scalability, availability, performance, etc) cannot be separated from the implementation of functional requirements. It is not a good idea to say that we would implement the functional requirements first and then look at non-functional requirements. According to me, one cannot write a piece of code implementing functional requirement without affecting the non-functional requirements. Even the simplest If-Else statements, for() loops we write affect the -ilities in a big way. It is always advisable to have the non-functional requirement related SLAs in mind all the time
and, after writing each piece of code, ask yourself does this line of code
meet the SLAs ?

Moral of the story is, in an Agile environment, performance, scalability, Availability testing is done all the time right from Iteration 1.

Best Practice: It is better to write unit tests to check the conformance of your code against the SLAs, and automate them. Creation of such unit tests and, automating them is the key to success in implementing non-functional requirements in an Agile environment.

Bahá'í Consultation model and decision making

We are making decisions all the time, either by ourselves or by collaborating with others. There are times where it is easier to make decisions and sometimes tough. One of the classic example is performance moderation session that all supervisors and their teams have to go through in their career, one time or the other. Have you ever attended such meetings in larger organizations ?, if not, here is a preview.
Each supervisor/manager brings the data about their team members and each of these supervisors would have come to the meeting with their own agenda i.e. to get promotions/good hikes to their team members. Most of the time, there are more candidates than the allocated budget and this is a tough situation as only a few, can be chosen for hike/promotions. In situations like this where each one is pursuing their own goal and not a common one, decision making becomes even more difficult.

Above example is an extreme one which may not happen daily, however we commonly come across group meetings where collective decision has to be taken.

How do you make decisions in such situations ?
In such situations one of the best suited techniques would be to apply the Baha'is consultation model". As you might be aware, Baha's is a religion. The goal of consultation the Bahá'í way is to discover the best course of action to take for the well-being of all.

Here are the 4 steps in Bahá'ís consultation technique:

1. Establish the full facts;
2. Decide on the principles to be applied;
3. Discuss the matter;
4. Make a decision.

In this technique, each participant would be given an opportunity to express their opinions, and everybody has to vote for all the ideas shared by the participants. This in turn results in ideas becoming "group's" property rather than individual's. People who would have come with malafide intentions cannot push their ideas as the rest of the crowd has to be in agreement. Respect for people and ideas are given highest priority in Baha'is consultation model.

Here are some good resources throwing more light on this model

http://www.planetbahai.org/cgi-bin/articles.pl?article=167

http://www.infonet.st-johns.nf.ca/bahai/consult.html

http://www.bcca.org/services/lists/noble-creation/bic-5.html

This technique could be applied during Estimation and retrospective sessions in Scrum.

Self Organizing team and its limit

There is a limit to everything and including the limit, a self organizing team can reach.

Self Organizing teams are characterized by the following features

• The team members share a common goal
• They collaborate to accomplish their goals
• Each team member shares the responsibility while managing the tasks
• They make their own decisions to achieve the necessary goal
  
• They take responsibility of both success and failure

Copyright

Self organizing teams are considered to be powerful and productive as compared to teams managed by a manager. However the question arises, can the team make decisions which could possible go against the company's goals ? if so, is it all right for self organizing teams to make such decisions ?

For example, a company might want the team to attend the CEO's biweekly presentation, however the team does not want to do so. Can such decisions be allowed ?

Even though self organizing teams can make their own decision to achieve the goal, the team cannot do whatever they want to do. There are certain limitations and framework within which they have to operate.

For example, the decisions made by self organizing teams should

• be in line with organizational goals
• Customers goals
• Goals of the project
  
• be Socially acceptable
  

If the team does not want to follow one or more of the above framework parameters, the stakeholders of the projects have all the rights to take necessary action. It is also important for the stakeholders to understand the root cause of the problem by applying Five Whys or any other techniques.

When would you not apply Agile methods ?

I have been applying Agile methods from so many years and been interacting with many Agile experts. So far I have not seen/heard stories about the projects where it had been felt that Agile cannot be applied. Agile methods should be looked more like a risk mitigation strategy on software projects rather than a "software development process". Agile promotes continuous improvement through learn and adapt cycles.


Following are the possible characteristics of a project where Agile need not be applied:

• The project carries no risks
  
• The stakeholders are not interested in continuous improvement of project quality.
• The stakeholders are confident that the project would go as per the project plan without any deviation. Even if it deviates, stakeholders/teams are fine with it.

Here is Ken Schwaber's take on "not" applying Scrum on projects:

I wouldn’t use Scrum if I were embarking on work in which there was absolutely no possibility of change or the unexpected. I would then confidently plan the project and await the predicted results on the day when it was due for the cost that was estimated. Wouldn’t this be a wonderful world ?

Stakeholders and management team keep coming across situations to make decisions around complex and debatable subjects, similar to the one we are discussing now(Agile - Not Agile). In such situations Ralph Stacey's Agreement & Certainty Matrix might come handy.

Towards an evolutionary design by Venkat Subramaniam

Recently I attended Venkat's seminar on "Towards evolutionary design". Thanks to ASCI and Binary Essentials for sponsoring this event. The event was a huge success and a lot of people attended the event inspite of heavy rains.

Image copyright

Venkat, is a proven software architect and an Agile expert. One can easily feel the passion when he speaks about the evolutionary design and architecture. Here is the summary of key points that I learnt from the seminar

1. Design can be of two types, strategic (high level design, modeling, etc) and tactical design (TDD, Refactoring, etc)

2. He recommended the audience to read the two good articles, "Who needs an architect" and "Is design dead ?" both by Martin Fowler. Another good book he recommended us to read was the Humane Interface by Jef Raskin

4. He explained Kent Beck's Triangulation concept very well. He mentioned that frameworks should be selected based on the need rather than emotions, and he wanted the development team to avoid "Resume Driven Development(RDD)" :-)

5. He encouraged the architect to apply the "Tracer bullet" concepts while architecting solutions. That is, create a prototype first and use this as the tracer to create a robust architecture.

There were many more take aways from this seminar and I would let his presentation speak about the rest.

The Agile Zone - Papers

I found this web site  The Agile Zone - Papers  with interesting papers, articles and presentations on (or related to) Agile Software Development.   The site lists the articles/white papers alphabetically. 

Technorati Tags: Agile resources,presentations,articles

Summary of Slack

I have been reading slack and also making notes of key points from the book. I always wanted to share the summary of the book on this blog, and incidentally I found that somebody has already done this. Thought would the share the summary here without reinventing the wheel.

You can also read the following summary here written by the author

* In our constant quest to make our organizations more efficient (reduction of overhead, standardization of processes, overworking management and resources), we have actually made them less effective. The solution lies in (re)introducing `slack'. Slack is the lubricant required to effect change, it is the degree of freedom that enables reinvention and true effectiveness.
* Multitasking and overtime, thought to be ways of getting the most out of the teams, are actually having a negative impact on productivity. Multitasking, specifically for knowledge workers, causes at least a 15% penalty in productivity. It is much higher for tasks (such as troubleshooting or design for instance) that require complete immersion before the resource can actually make progress. Systematic overtime is also proven to be an ineffective way of improving project cycle-time. While it may provide short term gains, the demands it puts on resources quickly reduces their productivity and effectiveness. An alternative to systematic overtime are well calculated and well timed sprints (focused and value-added, yet handled as exceptions).
* Overworked managers also have a very negative impact on organizational effectiveness. It is indeed managers, and more specifically middle managers, that can the most effectively champion and effect change in organizations. The more overworked they are, the less time they have to reinvent the ways of working. Those same middle managers will be most effective in bringing about positive changes if they can collaborate with each other, which in turns requires that organizations stop fostering destructive internal competition.
* Prescriptive processes, pushed top-down, are a form of disempowerment. They are a result of fearful management that is allergic to failure. These processes succeed in dictate every aspect of how you should do you work but fail in providing guidance in doing the `hard parts'. They are often heavy and form an armor that reduces the mobility and agility of teams, hence resulting in less competitive organizations. The solution is to put the ownership of processes between the hands of those who do the work.
* An effective change manager is a person that can remonstrate, repeat, correct, encourage, cajole, motivate, and has great powers of persuasion. He/she is less of a boss and more of a negotiator. Great change managers have a lot of markers to call in. Markers come from favors done and confidence earned in the past. They have built a reservoir of trust and tap into it to entice their people to embrace change. Change managers have to come from within the organization, a stranger has no markers to call in, just a little `honeymoon capital'.
* The best time to introduce change is in a period of growth. Decline causes anxiety and makes people more resistant to change.

Human angle in Software development

No matter what methods(Agile, traditional, Evo, FDD, RUP, etc) that is applied for software development, the only thing that decides the fate of the project is people.

There are many traditional projects that have been delivered successfully, and Agile projects that have failed miserably. The success or failure of projects doesn't depend on the process or framework that is being used.
According to me, it all depends on the people who are planning ,executing and maintaining the project. When I say people, it need not be the poor software developers, it could be PMs, customers themselves, marketing/sales people, finance team, etc.

The project's fate gets decided right from the time the marketing/sales person starts selling the skills/services to the prospective customer. I have seen many instances where the marketing/sales team over commit with the customers for the sake of winning the project. Ultimately when the actual work reaches the architects/project managers/developers, there will be little room left to make any changes. In most of the projects, the timeline is fixed, the only thing that is allowed to be flexible would be resources(a few lucky ones).

Even after so much of campaign happening around software process improvement, the project stakeholders add/remove people to the projects based on simple arithmetic. They don't look at software developers as humans but instead like chairs/tables/"things" that can be replaced and used right from the time it is purchased.

Here is an example and explanation of the above paragraph:

Let us say it takes 400 person days worth of effort to implement a feature . Naturally the stakeholders will calculate and say that if 20 people work on this feature for the next 20 days this work could be completed.

There is no flaw in the above calculation. However, the stakeholders never even think of buffers due to attrition or addition. What I am trying to say is, let us say the above team of 20 people start working on the project and they have completed 10 days (i.e. 20 P * 10 D = 300 PD complete). Let us say, the 11th day a team member quits the project. Consider the best case scenario where they found a new replacement person the same day.

My question is,

Even after finding the replacement the same day, what are the chances of completing the project as scheduled within the remaining next 10 days ?

According to me, the delay would be more than 5 days. Reason being, when a new person is introduced into any project, it not only takes some effort to psychologically adjust to new team but also takes effort in understanding the work. Unfortunately, in most of the cases I have seen the stakeholders don't consider the human angle and still push people to complete the work as planned because the new replacement was found the same day !!. This push in turn leads to reduced thinking due to time line pressure and ultimately reducing the quality of the work.

In Slack, Tom Demarco puts this process of replacement as "personnel turnover". As per research, the effort and the cost associated with personnel turnover could be as big as 25% of overall project effort. The cost may not be visible directly but it gets incurred due to delivery delay, training new personnel and defects fixing.

Until human angle is not given at most importance in any project, the project will go through turmoil no matter what method they follow !!

State of Indiana Makes Using Waterfall SDLC’s a Criminal Offense

Recently I came across this article which claims state of Indiana passing a bill against use of Waterfall SDLC.

Read the first para of the article here ....

Waterfall software development lifecycles have terrorized technology projects in this state for too long,” Governor Mitch Daniels said at a simple signing ceremony held at a meeting of the Central Indiana chapter of the Project Management Institute (PMI). “This bill will end the tyranny of big upfront planning, big upfront design, and litigation style change management.”
The bill, which goes into effect immediately, will make it a criminal offense to use software development lifecycles
that divide software projects into serially executed phases
distinguished by a particular type of work activity. Violators will be
stripped of their project management certifications and could face up to six weeks in jail for their first offense.

Read the complete article here.

The article has been written with such a perfection that people would take some time to realize that this is a joke :-)

Agile/Scrum podcasts

Check out the podcasts on

• Scaling Scrum
• Agile Estimation and Planning
• Essential Scrum
• Next step in Unit testing

Above sessions feature Agile experts like Rachel Davies, Roman Pichler and PushtoTest CEO Frank Cohen

Agile Myths

Many newbies to Agile bring tons of myths and misconceptions. They would have picked this baggage either by attending a seminar, reading a book or blog. It is not that the sources are wrong, but these enthusiasts would have misunderstood/misinterpreted the concepts.

Some of the common myths I keep hearing around Agile are :

1. Agile means two people working together on a computer.

Agile is a set of values and principles. Two people working together on a computer is one of the practices from Extreme Programming (A.K.A XP). Many people get confused between the Agile and the implementers of Agile (XP, Scrum, etc).

2. Developers working on Agile projects don't do any documentation

Agile Manfiesto never said don't do documentation. In fact, Agilists say that do documentation only as required that adds value to the customer and don't do it for the sake of satisfying some process.

Sometimes it becomes necessary to maintain extensive documentation, and if so, irrespective of whether it is Agile or not, it needs to be done.

For ex: projects involving avionics or military related projects need extensive documentation, this is keeping the sensitive of the domain in mind. In such cases, one has to maintain documentation because it adds value to the customer.

3. Agile methods cannot be applied for distributed development projects

There are many projects that have been carried out in distributed development applying Scrum and XP. The projects are pretty successful. Key thing to be successful while implementing Agile methods is being innovative with practices. Creativity and Innovation are the key ingredients to succeed in an Agile environment.

4. Agile methods expect the team members to be matured

Another big myth. There is no measurement to classify matured from immatured people. Its all perception and context dependent. Agile manifesto never talks about maturity of people, however Agile suggests hiring good people and trusting them to do the job.

Personally I worked with junior/senior members in various projects. Some team members were very good in communication while lacking in many facets of soft skills. However I found that many Agile practices(like scrum meeting, modeling days, retrospective,etc) helped the developers to improve their soft skills. This improvement is just a byproduct of practicing Agile methods.

5. Agile is not suitable for product development

Agile is being successfully practiced both in services and product development environment. In fact, I feel this is more appropriate for a product development environment. This is because, Agile concepts makes the product development more flexible and more open for changes to sustain in the competitive market.

6. Agile is not suitable for fixed bid projects
Many Agile companies specifically with my experiences in Indian context have been practicing Agile methods with fixed bid projects. If customer is willing to collaborate with the development team and, the development team is transparent with their deliverables then, all these types of contracts/negotiations would take back seat.

I have seen Agile software companies signing fixed bid contracts with the customers. Since the software services vendors are transparent in what they do, any new change request given by the customer is suitably discussed on the table and a solution emerges. The new change request is accommodated either by extending the release date/expansion of budget OR by dropping low priority features.

Here are some more resources on Agile Myths

Agile Mania

Agile Myth busters

5 Agile myths

Building an Agile team

Recently I got an opportunity to build yet another Agile team and wanted to share some of my experiences around it. Here is some initial context before I begin sharing:

• This team has around 5 people , with 2 junior members(<3>
• My company has a strong CMM background and at the same time, provides free hand to tweak the methodology or experiment with new techniques.
• The customer is not worried about whether it is CMM/Agile.
• It is a distributed team spread at many places in India.
• The client sits in US
• Project is research oriented than a development project

When I started recruiting team members and started the project work, I didn't tell the team members anything about Agile or any jargon from Agile methods. I started with the simple technique of having daily meetings (AKA stand up meeting in Agile methods). Here is what we do during daily meeting, every day at the same time we have a call in the morning and a call in the evening. Team members who are in different locations dial in during the meeting. Each person would share their plan for the day before taking the coffee break. All this information collected during the call gets updated on to the Wiki pages.

In the evenings, we discuss what we have achieved since morning and reason for not achieving something. We don't use this information to crucify somebody, but we have built this tradition to help the person in need. People are eager to share the issues and ask for help immediately.

I know that, this type of stand up meeting is a bit different from the traditional ones followed in Scrum or XP, answering 3 questions. I have realized that, many a times the Scrum meeting becomes monotonous and people answer those 3 questions for the sake of answering. In fact, in one of my friend's company, the client has been adamant about having a daily Scrum meeting by answering the 3 questions "at any cost". Many a times, the team members used to cook up answers for the Scrum meeting as they didn't have many things to answer during the call. I have realized over the last few years that the practices should not be enforced on the team members. It should be slowly sold to the team and the value should be exposed to the team members through various techniques. In my case study, the team missed couple of calls however suddenly they realized that they are losing the focus on work and things started looking chaotic. They made even a firm decision not to miss daily meetings.

Usage of white boards

Once the work starts in the day, we don't have any formal meetings but many of them are through informal discussions. If somebody has a point to share or want to discuss they will go to the white board and write it. We have a regular customer call and we read the points written noted on the white board to discuss any roadblocks with the customer. Because of this, we don't forget many things.

Usage of Spreadsheet

We use spreadsheet as the project tracking tool. On a daily basis we just update the status of each task. As and when we come across any new task, it gets inserted into the spreadsheet. It is amazing to know, how many "unplanned" tasks gets added into the project planner. This tool was created iteratively. As and when we found the information to be useful, we used to either create a new column or add a new status or anything else.

Use of Wiki

All documents are directly typed on to Wiki, no documents gets circulated via email.

Client meetings

Every team member whether junior or senior attends the regular customer call. In turn this has resulted in more efficient spread of knowledge and efficiency at work. Most of time, in many projects run in India, I have seen only the project managers/architects participating in calls with the customer. This results in team members not understanding the reality and never getting to know the first hand information. There are pros and cons to this practice(at least in the Indian context), but I feel there are more pros than cons.

Our team is still young and I am in the initial stages of buidling this Agile team. I still have a long way to go before I introduce retrospectives and other good practices ......

Self organization and Swarm Intelligence

Recently I read this article about Swarm Intelligence. This article talks about amazing efficiency of the insects like ants, wasps, bees, etc. The scientists have researched the behavior of these insects and, have proposed ideas that could be used in our day to day business. The portion of the article that caught my attention was the 3 characteristics of social insects that is making them successful.

They are

• Flexibility
• Robustness
• Self organization
  

Flexibility and robustness is influenced by self organization. The articles claims that

Through self organization, the behavior of the group emerges from collective interactions of all individuals

In the case study given in the article, the ants, bees don't have a leader directing day to day activities. The social insects seem to have two key priorities in their life time, finding food and defending against enemies. It seems to be a simple life as compared to human beings :-)
There is no need to have a backlog of tasks to monitor of the ants/bees. They get up in the morning, go in search of food, bring it back to their nests and live happily.

I was wondering why can't we be self organized like them(atleast in our work life) ? Specifically, Agile methods recommend self organizing teams. My take on this is, we as human beings can't be like ants, bees. It is very difficult (even though not impossible) for human beings to self organize themselves at work. We have many needs, desires, characters, emotions. Each of these parameters affect our thought process and decision making ability. We have our own individual identities as opposed to the ants and bees. May be these social insects have their individual identity, but looks like they give higher priority to the group rather than their individual wants/desires. I think we can achieve self organizing teams within our projects, provided we keep aside our individual priorities and work only towards the projects goal.

couple of questions that is coming to my mind..(for readers)

1. Is your project leader capable enough to create a strong goal that would make you to lower your personal priorities ?
   
2. Have you seen any projects with self organizing teams ?
   
3. What does it take to become self organized in your project ?
4. Are you willing to lose your identity for the project's goal ?
   

So bottom line is, it is easier for ants, bees and other social insects to self organize as compared to us, human beings.

Scrum Meetings Vs Scrum Events

Some of the common events that is practiced by Scrum teams include

• Daily Scrum meeting
• Scrum of Scrum meeting
  
• Requirement workshop
• Modeling days
• Review sessions
• Retrospective sessions
  

Scrum teams would be conducting one or the other meetings mentioned in the above list, every day. New teams practicing Agile methods specifically Scrum would feel that, there are more meetings in Agile as compared to the number of meetings in traditional methods.

I think one of the reasons why teams start resisting these meetings is because, they might be practicing the methods not in true spirits (not understanding the true value of these meetings) but for the sake of "doing" it.

What is the solution for such teams ?

1. Coaching the teams about the values of these meetings. This could be done with the help from an internal/external Agile mentor/coach.

2. Change the vocabulary: The word "meeting" is kind of becoming synonym for "obligation". So, whenever the team hears the word "meeting", they start resisting unconsciously. One of the ways proposed by Tobias Mayer is to change the vocabulary. For ex: rename "meeting" with "discussion","working session", "event", etc.

After reading Tobias's email, I became conscious of impact on our mind; usage of the words like "firefighting","postmortem","warroom". Beleive it or not, each of these words increases stress,blood pressure level when uttered. Next time when you utter these words feel yourself.

Right way to do Agile

If you are practicing Agile methods, I am sure at some point of time, you would have asked yourself or somebody else,

Am I  practicing Agile, the right way ?.

I would like to call this as an "eternal question on Agile".

If you visit any of the Agile related Yahoo or Google groups, people would be asking the same/similar eternal questions.   I conduct many Agile training programs and coach teams, and I keep getting similar questions.

There are many such questions. Some of them include  :

• What is the ideal length of iteration ?
• Do I need to practice Scrum meeting everyday ?
• I am working on maintenance project, do I need to practice Scrum meeting every day ?
• Can we have multiple Scrum Masters in a Scrum team

When I hear these questions, I feel that there is something missing in their understanding of meaning of Agile/Agile methods.

As we know, Agile is all about values and principles. These values and principles are manifested into practices with the help of Agile methods like XP, Scrum, DFDM, etc. But, the practices not limited to the one recommended by above methods. Beauty with Agile methods is, one can invent any practice/set of practices one wants provided the practices don't violate the values and principles.

You would say that's fine, I understood but where are the answers to above questions ?  My answer would be,

• Invent any practice you want provided you satisfy the customer and team
• Modify any practice you want provided it does not violate the Agile values and principles. It should be done after taking the team into consideration and a thorough research.

Practices should not be modified to satisfy an individual's taste. Many of the practices proposed by XP, Scrum are recommended after a thorough research and they have their own benefits. Some of them when practiced, are intended to identify risks and issues in the project. When a team practicing Scrum hits a painful point, they would tend to tweak the practice to reduce the pain. But instead I would recommend the team to retrospect and see the hidden issue behind the pain

 

Technorati Tags: Agile,XP,Scrum,Practice,Invent practice,right way to do Agile

Agile Austin and wealth of resources

Agile Austin maintains a wealth of resources on Agile methods.

If you visit their website and click on the Resources link in the left navigation pane, you will find a great list of Books, websites, listservs, blogs, podcasts and videos to get you going.

Attributes of a true Scrum Master

As per Tao Te Ching

The worst leader is who people despise, a good leader is who people worship. A great leader is he who makes people say "we overselves did it"

If you really look at the responsibilities of a true Scrum Master, he is supposed to be a great leader. One of the key responsibilities of a Scrum Master is to create a Self organizing team, where team is empowered to make decisions, lead the project towards the goal.
* A true Scrum Master(SM) won't spend time micro managing activities of the team and instead, he/she would be working towards creating a space for the team to express themselves.
* SM steps out observing the team, coaching them to move in the right direction. This process of empowerment ultimately makes the team feel possessive about the project and creates an image that "they" did everything.
* A true Scrum Master would stay as an angel not in the view of the team, but keeping a watchful eye on every movement of the team.

So, going back to the quote from Tao Te Ching, the Scrum Masters should not consider themselves as "transformed project managers" but work towards becoming great leaders, satisfying the true meaning of "Scrum Master".

Even though no body is born as a leader, I firmly beleive that some of the leadership skills could be developed by observing other leaders.

Agile world in the Top 20 Blogs

Agile Daily has rated my blog Agile blog in the top 20 list as the most recommended blogs on Agile development.


Here is what they say:
Sorted by Fastest Gain in SocialRank. These blogs had the biggest increase in attention today.

1. Geek Noise
2. ASP.Net
3. James Shore
4. Agile Advice
5. Agile Game Development
6. Jason Yip - Blog
7. George Dinwiddie - Blog
8. Agile .NET CT
9. Agile Programmer
10. Agile Israel
11. Agile Software Process Improvement
12. Me.Andering
13. Diana Larsen - Blog
14. Jeff Sutherland - Blog
15. Agile Artisans
16. Agile Blog
17. TargetProcess
18. Agile Project Planning
19. Better Ways of Developing Software
20. Agile Software Development blogs

Accountability and Productivity

I have been reading one of my favorite books Slack, and in one of the chapters on schedules, Tom brings up a good point about accountability and productivity. He mentions that

When a schedule is not met, those inclined to pass out blame are quick to
point at the lowest-level workers; they reason that performance is the domain
entirely of those who perform the work. They ask plaintively, "why can't these
guys ever meet their schedules" ? the answer that the schedule might have been
wrong in the first place only befuddles them.

He continues to say

There is such a thing as a bad schedule. A bad schedule is one that sets a date that is subsequently missed. .... If the date is missed, the schedule was wrong. ... The purpose of schedule was planning, not goal-setting. Work that is not performed according to a plan invalidates the plan.

My blog feeds are available through ASCI

Agile world blog's posts can be viewed through Agile Software Community of India(ASCI)'s website.